IPA report : Next Generation Authentication Infrastructure : for Mash-Up "Trusted" Services ?
IPAのレポート「次世代認証基盤ソフトウェア」はSAMLを使って ”Mash-up Trusted Service”をめざす？
[Summary] IPA ( Information Technology Promotion Agency, Japan ) disclosed the report of experimental proof which used three kinds of SAML. They were OpenSAML, NEC's library and Sun's Access Manager. As well as details of installation and architecture, another possible experimental proof in future ----- interoperability of SAML ( Liberty ID-FF ) and WS-Federation was mentioned. The report is great. If you can read Japanese , please find the Japanese report.
(Translate to English)
経済産業省補助事業である「平成１７年度情報基盤対策区技術開発等推進事業（次世代型電子認証基盤の整備）」の報告書の一つとして、「次世代認証基盤ソフトウェア（開発成果報告書）」がIPA (日本情報処理開発協会）から出ています。
ここでの目的は、
認証連携やサービス連携を実現するための認証連携機能に関わる、他からも利用できるコア技術の開発を目的とした。又開発ソフトウェアの妥当性、問題点及び改善点を整理することを目的に評価実験を実施した。( P-1 )
だそうです。
そして、ここで述べている認証連携技術とは、
本次世代認証基盤の開発では、認証連携技術に二つの標準的な仕様（SAML, WS-Federation）を採用することにした。ただしWS-Federation は、調査の結果において採用予定の実装が困難であることが判明したことから、来年度の課題とすることにした。 ( P-7 )
なのですが、サービス連携ではSAMLやLiberty ID-WSFによる属性交換等を採用するのではなく、あくまでもポータルサーバーを中心として、属性に対するアクセスコントロールによってサービス提供の可否をおこなっている（ようです）。ざーと目を通しただけですので、詳細の理解が間違っているかもしれませんが。（後日訂正をいれるかもしれません）
さて、これらを実現するためのアーキテクチャとして、以下の図の通りの環境をつくって実証を行ったようです。( P-102 )
ここでは、OpenSAML, Sun Java System Access Manager, NECのSAMLライブラリの３種類のコンポーネントが使われています。
もし、よりLiberty ID-FF的な考え方でやるとすれば、上図においてポータル・サイトを接点とした、Common Domain を使えばいいのでは、、、なんて思ったりします。
また具体的なサービス連携ですが、以下のシナリオを想定しているとのこと。
産業イベント企画が同一トラストドメイン内の宇宙旅行社と提携して、イベント参加希望者に対して交通手段や宿泊等の予約サービスを同時に提供することとした。利用者は、事前に連携サービスを登録し実行することにより、まず産業イベント企画サイトより任意のイベントへの参加を予約する。この際、SSO で認証済みであることから、サービス間で利用者の対応付けがなされ、前サービスで入力した情報を再度入力する必要がなくなることを想定した。その後、宇宙旅行社サイトへ移動すると、前サービスと関連する情報が利用者へ提示される（産業イベント企画でのサービス利用結果を宇宙旅行社が共有する）。全ての予約が完了すると、各サイトへのアクセス及びイベント
のログが表示されることとした。( P-108 )
のログが表示されることとした。( P-108 )
ここでの 訴求ポイントは、
● SSO で認証済みであることから、予約時の情報の再入力が不必要となる（利便性）。
● SP 間で利用者のサービス利用結果を共有することで利用者に即したサービスの提供が可能となる（サービス付加価値の向上）。
● SP 間で利用者のサービス利用結果を共有することで利用者に即したサービスの提供が可能となる（サービス付加価値の向上）。
で、具体的な画面遷移は以下の図の通り。
うーん、せっかくだから、Liberty ID-WSFを使えばいいと思ったのですが、国の予算を使った研究ですから、（上記の訴求ポイントである）利便性とサービス価値の向上とを兼ね備えたID-WSF以上の仕様ができれば、それはそれですばらしいことだと思います。
ところで、ここで目標は、あくまでもサービスの連携です。しかも、個人情報を確実に守る安全で信頼のおけるサービス連携です。Web2.0 の時代において、サービス連携を指すMash-up という流行言葉だけでは、不特定多数へのサービスでしか、現在の技術ではセキュリティを確保できないと思います。
通信におけるセキュリティというと、SSLを思い浮かべる人も多いですが、SSLはチャネルを対象としたポイント・ツー・ポイントのセキュリティ確保であって、エンド・ツー・エンドのセキュリティではありません。SOAP v.s. REST の戦いは、現在、RESTがWeb2.0の勢いとともに、その勢いを増しています。しかし、SOAPがなぜ、できたか、また、それに関連したWebサービス関連の仕様が、どうしてここまで複雑になってしまったかということは、知る必要があります。もちろん、政治的な要因もありますが・・・・・・
安全なサービスを、ディベロッパーが楽に実装する、というのは本来、相反するものだったのですが、いろいろなところで、様々なことが考案されはじめています。例えば、個人情報を扱わないような、非特定多数のサービスを、まずRESTで提供し、個人が特定される付加価値の高いサービスの段階になった時点でSOAPに切り替えるとか・・・・・・これからさまざまなことが起こると思いますが、目指すは、Mash-up "Trsuted" Services です。（Liberty ではFederated Serviceといいます）
＃それにしても、今年度、WS-Federation を使った実証を本当にやるとすれば、スゴイことです！
Tags: Liberty Alliance, SAML,Web2.0
