SAML と OpenID と CardSpace
2008-07-18
（書きかけで寝ちゃったけど、続きを書いた）
あいにくの雨だったけど、第3回 Liberty Alliance 技術セミナーを聴講してきた。 今回の大きなテーマは相互運用性。
「パネル：アイデンティティ管理標準の相互運用の可能性を探る （SAML/Liberty, OpenID, CardSpace）」
SAML と OpenID と CardSpace という、アイデンティティ管理の主要な3つのスペックが一同に集まるという、なんとも貴重な機会だった。 モデレータの高橋さん曰く、「アイデンティティ三国志時代…ではなく、和を尊ぶ聖徳太子にしたい」とのこと。 個人的には SAML が魏、 OpenID が呉、 CardSpace が蜀かなぁ。
以下、自分がメモしたポイントを箇条書きで。
SAML V2.0の可能性
伊藤さんによる講演。
-
SAML を構成するスペック (MetaData, Binding, Profile) の概要を説明
-
Binding は HTTP (Artifact, POST), SAML がある。
- 近いうちに RESTful Binding が発表されるかも？
-
拡張仕様 … 「認証コンテキスト」という概念。
- ピザ屋のオンライン注文にて、回線IDを使って個人ではなく世帯を認証する → お酒を購入する場合は個人レベルの認証へ切り替える
-
XML署名を使わないメッセージ検証
- XML署名だと署名が2回 (Assertion, Response) 必要
- Bash64エンコードしたデータに署名することで、署名を1回に削減できる
OpenIDとは？その動向と展望
=nat さんによる講演。
- カカクコムのソーシャルブックマークサイトでは半数近くが OpenID でユーザ登録している
- 技術者向けのサイトなので特別な事例
最近のトピックが興味深かった。
-
Discovery on RP (OPにて実施)
- OP が RP を Discover し、 RP の正当性を確認する
- 戻り先URLにリダイレクタを指定されることで認証情報が他のサイトへ漏れてしまうことなどを防ぎたい
- yahoo.com が対応。 yahoo.co.jp はおそらく非対応。
-
OpenID レスポンスメッセージの検証 (RPにて実施)
- 署名だけを検証してもダメ
- OpenIDリクエストで送信した ClaimedID と OP から戻ってきた (Verified) ClaimedID が一致するかどうかを確認すべき
- 一致しない場合（リクエスト時に yahoo.com などのOPのURLを使った場合を含む）は、もう一度 Discovey を実行して ClaimedID を確認する
-
PAKE はあと1ヶ月くらいでスペックが Fix しそう
- FISCやNISTが定める認証強度の基準を使う
-
TX (Trasted Date Exchange)
- PAKE が Fix したら取り組みたい
- 安全な「属性情報交換」のための仕組み。現在のステータスは提案中。
- AX (Attribute Extention) は軽い仕組み。TX はよりヘビーな e コマース向け。
- AX だと属性情報はセッション鍵で保護される → 通信時のみの保護なので、その後に否認可能。
- たとえばOPがRPにそんなデータを送った覚えがないと言える。
- 公開鍵暗号方式を使って署名することで、否認防止を実現（非否認性ってやつ）
- 航空会社と旅行代理店の間でクレジットカード番号や住所氏名を交換するなど。
- Liberty Alliance の Identity Governance Framework に似ている
-
OpenIDのIDリサイクル問題
- URL の所有者は永久に同じではない → 同じIDが別の人に使われてしまう
- 例えばドメインの期限切れ、更新忘れによるドメイン乗っ取り
- OPのサービスを退会して、他の人が同じIDを取得したら？
- 対策: ClaimedIDの末尾にフラグメント (#001, #002) をつけて識別する
- URLではなくXRIを使えばこの問題は起きない。i-nameとi-numberに分かれているので
-
Reputation Service
- 「ホワイトリスト」を使うと何のための OpenID なのかが分からなくなる
- 公開鍵を用いて信頼の基盤を確立する
- OASIS の Open Reputation Management Systems (ORMS) で策定中
=natさん講演への所感
-
TX が属性交換に使えるものなら、エンタープライズ分野での OpenID の採用が進むかも
- Liberty Alliance の ID-WSF のライバルになる？
- メアドの交換程度の軽いネットサービスであれば、あんまり関係なさそう
-
OpenIDのIDリサイクル問題には注意が必要
- 個人ドメインをClaimedIDに使う場合は、ドメインの期限切れに注意
- それよりも信頼できる大手のOPに任せた方がいいかも
パネル：アイデンティティ管理標準の相互運用の可能性を探る （SAML/Liberty, OpenID, CardSpace）
3つの仕様が集まる貴重な機会。 こういうイベントは海外では珍しいとのこと。
-
高橋さんによるNewOrgの紹介
- 相互運用性を検討するためにNewOrg（仮称）を本日未明に発表した
- アイデンティティの三国志時代から、聖徳太子による協調の時代へ
-
田辺さんによるCardSpaceの説明
- Information Card が仕様名。CardSpaceはInformation CardのMicrosoftによる実装。
- ネット上に存在する複数のIDを選択させるインタフェースに特化。
- 個人用カードとマネージドカードの2つがある。
- （個人用カードはWebブラウザがIDとパスワードを記憶する機能の拡張版みたいなもの？よく分からなかった）
- IdP上のアカウントはマネージドカードで管理する。
-
工藤さんによる相互運用の話
- Google Apps は SAML2.0, SalesForceは SAML1.1, Basecamp は OpenID
- 企業の認証基盤構築において、複数仕様への対応が求められる
- フレームワークが仕様を隠蔽して、企業の開発者はフレームワークのAPIを操作するだけになるのでは
- RSAカンファレンス2008でSAML2.0とInfoCardの相互運用性をテストした
- SAMLのSP→SAMLのIdP→InfocardのRP→InfocardのIdPとすすみ、Infocardで認証したら逆に戻ってくる
- SAMLとInfocardの間にはゲートウェイを使用しているが、そのままSAMLアサーションを使えるかも？
-
崎村さんによる相互運用の話
- OpenID の認証に CardSpace を使っている。
- これはデモではなく、実際に毎日自分が使っている
パネルへの所感
- 田辺さんのCardSpaceの説明や工藤さんの相互運用の話は、パネルではなく別セッションでじっくり聞きたいくらいの濃い話だった
- パネラーどうしの議論が無かったのは少し残念。まぁ、仕方ないのかな。
- 工藤さんのフレームワークが隠蔽というのは、tkudo’s weblog に書かれていた話のことかな？
これからアクセス管理 / SSO 基盤を構築するのなら, 特定のプロトコル (e.g. SAML, OpenID etc.) やバージョンに依存するのではなく, OpenSSO のように 「SAML 1.1 / SAML 2.0 / Liberty ID-FF / WS-Federation などの複数のフェデレーション・プロトコルの同時サポート (いわゆる『フェデレーション・ハブ』)」 の機能を備えたソフトウェアを選んだほうがいいと思う. 「うちのにんしょーきばん, Google Apps には SAML 2.0 で SSO できるんだけど, salesforce.com や WebEx は SAML 1.1 なので連携できないんだよね」 というのでは, ちょっと切ない…
- 一つの仕様に対応するだけでも大変なのに、相互運用までできるところは体力がある大手に限られるだろうなと思った
- 個人的には無理に一つにまとめて重くなるよりは、多様性があるほうがいいな。
- ゲートウェイ（グッドラッパー）が頑張るのであれば歓迎。仕様が複雑になるのは歓迎しない。
思っていた以上に刺激を受けたセミナーだった。 参加してよかった。 でも、最近はインプットばかりなので、何かアウトプットを出さないと飽和しそう…。