at posts/single.html

第1回アイデンティティ飲み会 (エンタープライズとWebの素敵な出会い)

ずっと前から楽しみにしていたアイデンティティ飲み会に行ってきた。 場所は中目黒の某所(公表されてないので一応自重)。 一見、飲食店に見えないたたずまいで、事前に「入り口が分かりにくいですよ」と聞いていなければ絶対に入らないようなところだった。 店の前まで来たのに、一度駅まで戻られた方もいらっしゃったようで。 でも本当に素敵なお店だった。

幹事をしていただいた工藤さんに本当に感謝です。

集まった皆さんも豪華な顔ぶれで、ちょっと恐縮。 id:ZIGOROuさんもおっしゃっていたけど、エンタープライズ系とWeb系の人がこうやって出会う機会ってあまりないと思う。

SAML と OpenID のバトルを期待してたんだけど(冗談)、そんなことはなく終始なごやかな感じだった。

OpenID については、使う人が意識しないと使えないようじゃまだまだだねーとか、そういう話がでてた。 やっぱり僕も、 RP (Consumer) 側で ID (OpenID の URL) を入れる仕様は、どうも馴染まないんじゃないかという気がしている。 OP (IdP) の Reputation 問題もあるし、以下のように使った方が現実的かも。

  1. RP 側では認証に使う OP を指定する (はてなでログイン, livedoorでログインみたいな選択式)
  2. OP 側で ID とパスワードを入力する。このときの ID は OP ローカルの ID (はてななら kmachu みたいな)
  3. OP から RP へ OpenID (www.hatena.ne.jp/kmachu) が伝えられる

これだと利用者が OpenID を意識することはない。入力する ID はいつもと同じはてなIDでOK。 OpenID はバックエンドで使われるだけ。 利用者が選べる OP が制限されるデメリットはあるけど、受け入れる OP を RP が決めるほうが現実的かもね。

ちなみに、タイムリーに OpenID 対応を表明した Yahoo! も、こんなボタンを用意してる。

6.png

SAML の話

言われてみれば SAML の話ってあんまりネットにでてこない。 オンラインで読める文書だと、4年前の資料だけどこれがいいかも。 一応、僕の名前も載ってたりする。

まだ SAML1.1 の頃で、 Liberty ID-FF と合流する前なんだけど、概要とユースケースと仕様書の日本語訳が載っているので、なんとなくイメージはつかめてもらえるかもしれない。

SAML はいくつかの仕様から構成されているけど、ベースとなっているのは「アサーション」と呼ばれる認証情報を規定したもの(付録A参照)。 ここでは、認証情報を複数のサーバで共有するためのフォーマットを規定している。 OpenIDでいうと、クエリに openid.*** というパラメータを付けるのと同じようなもの。 この時点ではシングルサインオンとかはまだ関係なくて、汎用的に使えるものになっている。 @IT:強力なSSOを実現するXML認証・認可サービス(SAML)の図1で Authentication, Attribute, Authorization と書かれているように、認証・認可サービスのためのベースのフォーマット。 AtomPP のための Atom みたいなものかなぁ(よく分からずに言ってみた)。

んで、アサーションを使ったシングルサインオンを規定しているのが、付録Bの Bindings and Profile 。 この中の 4.1 Web Browser SSO Profiles of SAML で、シングルサインオンのフォーマットが規定されている。 このときはまだ Liberty ID-FF の仕組みが含まれる前なので、「仮名」や「シングルログアウト」の話は含まれてなかったように記憶してる。 (ID-FF の仕様が SAML2.0 に盛り込まれたのは 2005年)

SAML2.0 以降の話は僕も詳しくないので、id:shinichitomitaさんに期待。

ちょっと前に話題になっていたけど、 OpenID と SAML の大きな違いは信頼関係を事前に結ぶかどうか (最近のSAMLは結ばないモデルもあるみたい) 。 Gmail と livedoor のように大きなシステム同士が結びつく場合は SAML で、もう少しライトな Web 系のサービス (ブログやSNS) で本人の同一性を確認したい場合は OpenID という使い分けなんだろうね。

関連する日記