(Translate to English)
Saturday Apr 26, 2008
木曜の晩, ひそかに申し込んでた
OpenID Tech Night vol.1
に行ってきた.
以下, ZIGOROu さんのエントリをパクり引用しつつ,
所感などをつらつらと.
OpenID Authentication 2.0 〜概要とシーケンス・トレース〜
会場について, 席に置いてあったクリアファイルを見たら,
このセッションの配布資料と一緒に,
Final: OpenID Authentication 2.0 - Final
の全文をそのまま 2up 両面で印刷したのが入ってた.
率直に言ってそのときは 「うわ, いきなりこれはきっついなー」 と思ったんだけど,
でもこのセッションが進むにつれて,
「手元に仕様書が紙ベースで用意されていて,
ちょっとわからないところがあったらすぐに仕様の記述を確認できること」
のありがたさをつくづく感じさせられたという, そういう内容でした.
もきちんと話していて素晴らしいーと思った。
ぼくが興味深く思った (というか, まともに仕様読んでないだけなんだけど) のは
のくだり.
キャッシュしてる assoc_handle を更新する方法も仕様化されてたのか.
あと, Yahoo! がいつのまにか localhost な RP
をサポートするようになってたのは知らなかった.
Yahoo! OpenID FAQ
にはまだ
Yahoo! will only support Relying Parties running on
webservers with real hostnames (略) running on standard
ports
と書いてあるけど,
このへんの制限を実際はすこし緩和してきてるみたい.
Realmとreturn_to辺りの話とか、RP Discoveryとかの話は＠ITの連載とかでいつか真面目に話そうかなと思います。
ぼくも, この RP Discovery のネタがセッションの中で出てきたときには,
そこまで話すのかーと思ってニヤニヤしてしまった.
ちなみに資料では 「利用している OP は殆ど無い」 となってるけど,
少なくとも一社,
Yahoo! がやってるらしい.
Building Relying Party Best Practice
すごくわかりやすかった.
ただ,
- Claimed Identifier Claimed Identifier をそのままRP 上での“ID”扱いする
- あるいは RP 上での上での“ID”に紐付ける
のどちらがいいのかは,
一概には言えないと思う.
たしかに利便性とか可用性とかの面では後者が有効であることに同意なんだけど
(てか, これって SAML とか Liberty の世界の
「アイデンティティ・フェデレーション」 っすね),
たとえば 「おれはこの Flickr の URL
を使って己のディジタル・アイデンティティを確立していくぞ!」
という,
Eve Maler が名づけるところの
「Me generation」
の人にとっては, そのサービスが,
積極的に自分の Flickr URL をさらけだしてくれることを望むのではないかと.
飲み会とか
=natさんやtkudoさん、mizzyさんなどと帰りにちょっと呑んで来ました。
なんかプチアイデンティティ飲み会の様相を呈してた.
XRI と CanonicalID の事、あとClaimed Identifier の fragment の話
ただ、これは固定IPアドレスみたいな物であると同時に、仮に =zigorou が別のジゴロウさんになったとした場合、異なるCanonicalIDが割り振られる。つまり再利用しないって事みたい。
ドメイン失効とか乗っ取られたりしたらその Identifier は一見他人を表してしまうけど、そうならないように、Canonical IDは個人にユニークな値を割り振る。
ぼくはいまだに XRI 2.0 FAQ
を斜め読みしてるような知識レベルなので,
素人考えなのかもしれないけど,
この 「一人の持つ複数の i-name (e.g. =zigorou) が,
最終的には一つの i-number (e.g. =!545A.6972.43FA.38AD) にひもづく」
というしくみは,
いわゆる 「ペルソナ」 との相性があんまよくないように見える.
つまり性質の異なる RP ごとに, それぞれ違う i-name を用いても,
結局は一人の個人に結びついてしまうんじゃないかと.
まあそのへんは,
OpenID の場合には URL ベースであれば 「ディレクテッド・アイデンティティ」
(どの RP にどの OpenID URL を渡すか,
たとえば暗号化された値にするか Flickr URL にするかを,
ユーザが自分の意志をもって 「指図する (direct)」)
ができるから, 別にいいのかな.
関係ないけど, ぼくのような XRI 素人にとっては,
そもそもの XRI のなりたちを解説する以下のエントリが非常に参考になった.
それと今度
XRI 2.0 の webinar
があるらしくて, ちょっと興味あるんだけど,
日時が日本時間の 5/7 未明なんだよなあ...
=nat さんは次回の Identity Conference で基調講演として XRI/XRDS と Reputation について基調講演して下さる予定です。
YAPCとかIIW(?)とかあるんで5月24日以降だといい感じみたい＞id:mizuno_takaaki
ついでに, その
Internet Identity Workshop
のお話とかも聴きたいなー. ぜひぜひ. > =nat さん
Reputation の話
セキュリティレベルの監査とか、OP, RP, Userの3者の間で各々の評価を行う仕組みが出来て、評価する枠組みが "公平" だとしても、Reputation で高い得点となったとしても、実際にユーザーに使われてて、広く認知されてなかったりなんて事もありそうとtkudoさんが言ってたんだけど、僕もそれに同意。
表現がうまくなくてすみません...
ぼくが思ったのは, たとえば
Yahoo! OpenID のリピュテーション・スコアは低くなるだろう, とぼくは勝手に想像してる
(みんなにタダでアカウントを配ってるから) んだけど,
だからといって, RP がそれをもって Yahoo! の OpenID
の受け入れを拒否するようなことはないのではないか,
でもそしたら 「リピュテーション・スコア」 って何のためにあるのかわからないなー,
ってことです.
でもしらふの状態でもう一度考えてみると,
Yahoo! のようなメガ OpenID プロバイダは,
海千山千ある中でも例外的な存在として扱ったほうがいいのかもという気がしてきた.
うーん.
今度改めて。
同じく.
しょこたん
しょこたん似の人に写真を撮られるなどした。
名前聞かなかったけど idcon 来て下さい。
あまりのアイデンティティ・セレブっぷりに軽く嫉妬しましたw
=katsu さん
ブログ書いてたら教えて下さい。あと書いてなかったら書いて下さい（ぇ
=katsu さんのブログだから,
やっぱ =katsu/(+blog) ですかね... と思ったら,
ホントにあった!
そのほか
OIDF の裏話とか,
某 OP はギャグでやってんのかとか,
ZIGOROu さんと帰りの電車でずーっとアイデンティティ・トークし続けたりとか,
いろいろ楽しかった!
関係者のみなさまありがとうございました & 次回もよろしくお願いします.
(Translate to English)
Monday Apr 14, 2008
今週金曜 (4/18) 発売の月刊 Computerworld 2008 年 6 月号に,
『コンシューマーからエンタープライズへ ──
本格化する OpenID の明日を探る』
という記事を寄稿した.
内容は, 「IT マネージャー」 向けに
- OpenID 仕様の概要
- 最近の動向
- Web サービス・ベンダの目論見
- 「ディレクテッド・アイデンティティ」
- エンタープライズ分野への適用
- 普及への課題
を概観する, 全 6 ページ.
冒頭 2 ページの PDF が
IDG Direct
からダウンロードできるようになっているので,
よろしければご高覧くださいませ.
(Translate to English)
Monday Mar 24, 2008
ソースは脳内 (すみません). こないだ出てた
という調査結果をみて,
なんかこれって数年前のフィード・リーダーの普及状況と似てるなあと思っただけ.
ちょっと検索してみたら, 3 年半前はこんな感じ↓だったらしい.
RSSリーダーの利用者は全体の4.7％で、あまり利用されていないことが明らかになった。
CNET Japan, 2004 年 8 月 11 日
で, 昨年の調査結果は以下. こちらは 「使っている」 ではなくて 「使ったことがある」 だけど.
RSS リーダーの「利用経験がある」人も、過去調査では16〜18％程度であった値が、今回はついに2割を越えている。
japan.internet.com, 2007 年 4 月 6 日
いま多くのサイトにフィードがついてるのと同じように,
もしかしたら OpenID もこの先 2, 3 年たったら,
いろんな Web サイトが受け入れるようになる
(リライング・パーティになる) かも.
けど一方 OpenID を自覚的に使うユーザは,
その段階でも全体の 2 割くらいに留まるんじゃないだろうか.
(Translate to English)
Tuesday Mar 18, 2008
昨日、サイボウズ・ラボにてIdentity Conference #01を開催しました。
Identity Conference #01を開催しました - Yet Another Hackadelic
ということで,
おととい (日曜日) 会社の近くで開催された
Identity Conference #01 + 第 2 回アイデンティティ飲み会に行ってきた.
勉強会のほうでひとコマ 30 分ほど
「技術比較: OpenID と SAML」
の紹介をさせていただいたんだけど,
なんかグダグダですみませんでした...
ZIGOROu さん,
きれいにまとめてくださってありがとうございます...
そういや,
ぼくが言った 「OpenID Provider と Relying Party の総当たりテスト」 って,
OSIS のやつです.
ご参考まで.
あと,
自分の保有する複数のディジタル・アイデンティティを束ねるという意味では
CardSpace とか
Clickpass
とか,
もっと単純に OpenID Authentication 2.0 の
Directed Identity
なんじゃないかなと思ったけど,
Relying Party の特徴とか, いま現在のコンテクストをみて
「このような場ではこのようなアイデンティティが適切でしょう」
と教えてくれるアイデンティティ・プロバイダ
(あえて OpenID Provider と限定しない)
は, たしかにおもしろそう.
勝手に名づけるなら, Suggested Identity
ってとこかな.
(Translate to English)
Thursday Jan 24, 2008
あ, あと
そのために、SAMLでは各SP<=>IdPのペアごとに異なる中間の識別子を使っている。
SAMLについて自由勝手に紹介 - snippets from shinichitomita’s journal
で思い出したけど (なお 「使っている」
というよりは 「使うこともできる」 のほうが適切かと),
OpenID 2.0 を採用した一部の IdP でも,
このようなやりかたをしている / しようとしているみたい.
具体的には OpenID.ee と
Yahoo!.
それぞれとくに OpenID.ee では自身の管理しているアカウント名とは別の識別子を,
RP (Relying Party) ごとにランダムに生成し払い出すらしい.
3. openid.ee/4e1243bd22c66e76c2ba9eddc1f91394e57f9f83 which is a "pseudo-anonymous" or "opaque" per-site identifier. - used for 'partial anonymity', something that consumers very often would like to use.
[OpenID] OpenID 2.0, PAPE and directed identities
Also note that even when you use Yahoo ID to sign in to a site that accepts openid, there is no personal information being shared. By default only an encrypted identifier (e.g. https://me.yahoo.com/a/D.GGRt8BtuO56ICRqYtp287qNA) will be shared with the RP.
[OpenID] Opt out of Yahoo OpenID?
Yahoo! JAPAN がやろうとしている OpenID Provider の設定は知らないけど,
もし Yahoo! と同じだとすると,
Yahoo!IDは微妙にセンシティブだと思っていて、あまり公開したくない
ような人からも受け入れてもらえそう.
加えて Yahoo! の場合には,
- Flickr の photos URL (例: www.flickr.com/photos/naveen)
- Yahoo! の URL (例: me.yahoo.com/naveen)
RP ごとにランダムに自動生成される URL (例: 上記のような me.yahoo.com/a/D.GGRt8BtuO56ICRqYtp287qNA)
のいずれかからユーザが選べるようになるそうだ.
Yahoo! みたいなところは
「抱えているアイデンティティの量が突き抜けている」
というだけで IdP としてものすごく有利だろうなあ
(逆に, その一点だけでも他の IdP
と差別化できる) と以前考えたけど,
それだけに満足せずいろいろなひねりが入ってそうで,
ちょっと楽しみ.
1/28/'08 追記:
Yahoo! JAPAN も OpenID 2.0 オンリーの模様.
※お客様の安全を考慮して、Yahoo! JAPANのOpenIDでは、OpenID2.0の仕様に対応したサイトにしかログインできません。
OpenIDとは？ - Yahoo! JAPAN
4/14/'08 追記:
ちょっと前に気づきつつ訂正しそびれてたけど,
Yahoo! の 「encrypted identifier」 は結局 OpenID.ee のとは違って,
「RP ごと」 に払い出されるものではなかったんだった.
つまり
there is no correlation inhibition
てこと.
がっかり.
(Translate to English)
Monday Jan 21, 2008
先週の金曜日は七時半から十一時すぎまで,
ずーっとアイデンティティねたで盛り上がることができてしまった.
ぜひまたやりましょー!
以下, 参加されたみなさんのエントリから, いろいろ思い出しつつ...
ZIGOROu さん:
OpenIDだとかSAMLだとかの切り口の違いって、
って話で分けられるのかなとか思いました。
第1回アイデンティティ飲み会 - Yet Another Hackadelic
マジレス厳禁
のところ, 真面目にフォローアップしてすみません...
けど, これには基本的に同意.
OpenID, SAML,
あるいはほかのアイデンティティ・フレームワークの中からどれを使うべきかを決定する一番の要件は,
- Idetity Provider (IdP; OpenID でいうところの OpenID Provider)
- Service Provider (SP; 同 Relying Party)
- エンドユーザ
の三者の中でのおカネの流れだと思う.
Identity Provider と Service Provider,
つまり「組織から組織へと」
おカネが流れる場合には, 組織対組織の信頼関係を表現するのに最適
(というか現実解) である PKI
にネイティブに対応した SAML 仕様が適している
(余談だけど, 個人対個人とか個人対組織のための
PKI ってホントに広まらないよなあ...).
Google Apps Premier Edition
なんかも
the partner must provide Google with the URL for its SSO service as well as the public key that Google should use to verify SAML responses
と書かれていることから推測すると,
企業 (IdP) からの SAML レスポンスにディジタル署名をつけさせて,
信頼できない企業へのサービス提供の防止と,
企業が表明した SAML レスポンスに対する否認防止をねらってるっぽい.
一方,
組織間ではなく 「Identity Provider とエンドユーザとの間」
「Service Provider とエンドユーザとの間」 におカネが流れる場合,
あるいはまったくおカネが流れない場合, あるいは広告モデルの場合には,
事前の信頼関係の構築を明に暗に求める SAML 仕様はちょっと重たい.
こういう分野には OpenID のような考えかたのほうが向いてるはず.
ただこれらの向き不向きはあくまでも現状であって,
OpenID + リピュテーション・サービスとか,
動的フェデレーション可能な SAMLとかが実現すると,
また状況は変わってくるんだろうなーと思う.
あと
名指しすると反応してくれるかもと言うことで、
同上
ということなので, ぼくも勝手にエンタープライジーな方面で名指ししてみる :)
ご都合があえば, 次回ぜひ!
まちゅさん:
言われてみれば SAML の話ってあんまりネットにでてこない。
第1回アイデンティティ飲み会 (エンタープライズとWebの素敵な出会い) - まちゅダイアリー (2008-01-18)
たしかに.
他にあるとすると, 手前味噌だけど, 昨年書いたコレ↓とかどうでしょ.
SAML, Liberty Alliance, ID-WSF などをさらっと紹介してます.
冨田さん:
ソーシャルブックマークサイトなどでブックマークされてるのをみると、あまりidentityタグって使われてない。なんでも「認証」って、おいおい（tkudo）
アイデンティティ飲み会 - snippets from shinichitomita’s journal
そうそう, 飲み会の席でも言ったけど,
きちんと identity タグを使ってるのって冨田さんくらいなんじゃないかという印象がある.
しかもいまみたら,
ちゃんと
identity タグと
authentication タグを使いわけてるし.
さすが.
ちなみにぼくのプライマリのブックマーク先は,
社内にある某 del.icio.us クローンだったりする.
ずっこくてすみません...
これからは
del.icio.us/tkudo
をちゃんと更新することにしよう.
全然関係ないけど、大昔工藤さんにおしえてもらったこのブログが好きです。翻訳かけて読んでます。
Korean Identity Management(KIM)
同上
同じく, ぼくもこんなフィード経由で読んでます →
http://preview.tinyurl.com/ytl7z7
たけまるさん:
終電が早かったので先に帰ったのですが，
支払いを忘れてしまいました ＞＜
ホントに申し訳ありません．特に幹事の工藤様，早急に支払いますので連
絡くださいませ．
... 内容については書く元気がなくなったので，ZIGOROu さんや machu さ
んのブログを見てください．まぁ，支払いを忘れるくらい盛り上がったっ
てことで．．
たけまる / 第1回アイデンティティ飲み会 (と信じられないようなミス)
たけまるさん,
一応あとでご連絡しますけど,
でも飲み代は第 2 回のときでもいいですよー.
それよかぜひ内容書いてください!
ここギコねねさん:
行ってみた感想としては、とりあえず「ほとんど判らなかった」状況でした...。
特に、私の席は周囲がエンタープライズ系の人中心で、OpenID/SAMLで言うところのSAMLの話題が中心だった（もしかしたらOpenID/SAMLを問わないアイデンティティ一般の普遍な話題だったのかもしれませんが、それすら判らない状態）ので、そちら方面はほとんど知らない私はキーワード収集するのが精一杯と言う感じでした。
ここギコ！: アイデンティティ飲み会、行って参りました
すみません...
しかもぼくも高橋さんとかと
「Data Portability
とかいう今こそ ID-WSF People Service
が注目されるべき!」
とか
「アドレス帳のポータビリティとコンタクト・ブックのポータビリティはわけて考えないといけないですよ!」
とか, OpenID とはあんま関係ないことばっか話してたような気がします...
ともあれ, みなさん満足していただけたみたいで,
企画して良かったです!
(Translate to English)
Friday Jan 18, 2008
Ω ΩΩ ＜ な, なんだってー (棒読み)
2006年、2007年あたりから注目が集まりだしたOpenID。対象Webサイトで登録する必要なく、認証情報を流用できるので便利だ。そしてそれをさらに発展させたものがSAMLというプロトコルだ。
MOONGIFT: » セキュアなシングルサインオンを実現する「simpleSAMLphp」:オープンソースを毎日紹介
こういう明らかな事実誤認が生まれてしまうのは, 残念ながら
SAML 自体よく知られていないからだと思うんだけど,
さておき SAML を使うとなにができるのかをてっとり早く試してみたい,
というかたにオススメしたいのが SSOCircle.
ここでアカウント作ってから, Google Apps (ssocircle.com ドメイン)
へシングル・サインオンしたりシングル・ログアウトしたりする
(Daniel のエントリが参考になる)
ところまで, だいたい 2, 30 分でできるはず.
昼休みとかの空いてる時間にでもどーぞ.
(Translate to English)
Friday Jan 11, 2008
「アイデンティティ飲み会」の件,
以下のみなさまに案内を送った (つもり).
もし届いていなかったらご連絡くださいませ.
それでは, 来週金曜の晩に!
(Translate to English)
Thursday Jan 10, 2008
そういや
trust
で思い出したけど,
正月休みに読んだたとえ話, ちょっとウケた.
One more thought on the love and trust linkage. One of the fellow identerati told me this:
Identity federation is like high school sex. Everyone is talking about it. But hardly anyone is doing it. And even the ones that are doing it, are not doing it right (and not for the right reasons either).
For federation to be long lasting, there should be love. And trust.
itickr.com » Blog Archive » Love.Federation.Cello Tape.Collaboration…and Viagra
OpenID は
promiscuous
だから,
きっと love や trust は不要に違いない ;)
P.S. ちなみにこの言い回し自体はけっこう使われてるっぽい.
(Translate to English)
Thursday Jan 10, 2008
なんかここ最近, SAML という単語を見かけることが多い気がする.
逆説的だけど, OpenID への関心が高まることで SAML の再評価がすすむのかも.
OpenIDやOAuthと、LDAPやSAMLなどのシングル・サインオン（Single Sign On）は似ているようで違う。その違いをちゃんと理解できていないので、勉強モードで調べた情報をまとめてみた。かなり長くなってしまったので、まずはまとめから。
OpenID や OAuth の役割と、既存のシングル・サインオンとの違い：Goodpic
冒頭の 「LDAP や SAML などのシングル・サインオン」
という記述にものすごく違和感を感じるけど
(「RDBMS や SAML などのシングル・サインオン」 と書いてるのに等しい),
そのような瑣末な点を除くと,
信頼 (trust) に関する考えかたに起因する SAML と OpenID
の違いがよくまとまってると思う
(とくに 「これからは、個人的な理解の整理です」 以降).
なお
SAML と OpenID とを同時に説明してる資料としては,
紹介されてる
Pat のスライドのほかに
Eve Maler のもオススメ.
(Translate to English)
Tuesday Jan 08, 2008
ひとつ前のエントリに関して,
ネタ元のたけまるさんからたくさんのツッコミをいただいた.
ありがとうございます &
すみません, 正月休み中の一本目だったので, 浅知恵ご容赦ください...
以下, いろいろコメント.
まず簡単なところで,
たけまるさんの環境では OpenID.sun.com を使った再現ができなかったという話から.
この OpenID プロバイダは他の一般的なやつとは違って,
アカウント発行の際に申請者が Sun の正社員かどうかを確認するという,
ちょっと変わった運用方針をとっている.
だから Sun の正社員以外のかたがサインアップしようとしても,
そのときに使うアカウントが Sun Online Account (Sun の Web サイトでのユーザ ID.
これは誰でも取得できる) だと,
Forbidden
Your client is not allowed to access the requested object.
になってしまう.
そしてここからが本題なんだけど, OpenID.sun.com は各正社員にひとつずつしか
OpenID identifier を提供しない.
よって
「ユーザが OpenID を使って RP にログイン → RP だけからログアウト →
OpenID を使って RP に再ログイン」 のときに,
同一の OpenID プロバイダにある複数の OpenID を使いわけるというユースケースは,
OpenID.sun.com においては起こりえない.
だからそのような 「起こりえない要求」 を
OpenID.sun.com が受けたときには,
その試みを不審なものとみなして,
verification を一方的に中断してしまうのもひとつの実装
(というか運用方針) かなー,
と考えたのが前回のエントリ.
たとえば
OpenID.sun.com に存在するぼくの利用可能な OpenID identifier
が仮に 「http://openid.sun.com/くどう」 だとして,
かつ OpenID.sun.com にぼくがログインしている状態であるとする.
このときにぼくがどこかの RP に 「http://openid.sun.com/くどう」 以外の
「http://openid.sun.com/代表取締役社長」
みたいな OpenID identifier を使ってログインを試みたら,
RP から問い合わせを受けた OpenID.sun.com は
「なんでくどうが社長を名乗ってるんだ!? なんかあやしい」
と判断するような感じ.
ただ, 中断させるために
openid.mode=cancel を返してもいいかどうかというと,
たけまるさんのご指摘の通り,
たしかにユーザにとってはわかりにくいっすね.
すごくまっとうな挙動
とまでは, ちょっと言えなかったかも...
まあ OpenID.sun.com のような一風変わった OpenID プロバイダではなく,
一般的なところであれば,
たけまるさんの提示された
ログインユーザ名と OpenID が異なっていたとき，IdP はユーザをログアウトさせてしまえば良い
というやりかたは理にかなっていると思う
(user-experience
に投げてみるとおもしろそう).
あるいは OpenID プロバイダごとに存在する挙動の違いを無視するために,
(ユーザにとっては不便だけど) 必ず max_auth_age=0 を指定するような
Relying Party の運用もアリだろう.
いずれにせよ OpenID うんぬんというよりは
(もっと言えば, OpenID に限らず SAML とかであっても),
各サイトがアイデンティティをどう扱うかというポリシー決めがまずは重要かと.
(Translate to English)
Saturday Jan 05, 2008
このへんは実装依存なのかなと思う.
適当な Consumer に 1つめの OpenID (例 http://example.com/foo) でロ
グインを試みます．すると，IdP に redirect されるので，ユーザ名 (foo)
とパスワードを入力します．そして，Consumer に redirect されます．
次に，Consumer からログアウトし，2つめの OpenID (例 http://example.com/bar)
でログインを試みます．予想では，ユーザ名 (bar) とパスワードの入力
を求められると思っていました．
ところが，livedoor では「認証に失敗しました」というエラーが表示さ
れます．
Vox では，1つめのユーザ名 (foo) でログインした Vox サイトがされま
す (Consumer に redirect されることもありません)．
ユーザとしては，1つめのユーザ名 (foo) はログアウトし，2つめのユー
ザ名 (bar) とパスワードを入力することを期待するように思います．
たけまる / 複数の OpenID を切り替えて使うときの振る舞い (シングル再ログイン?)
いま Identity Provider に
OpenID.sun.com,
Relying Party に
Dopplr
を使って上記のフローを追試してみたところ,
Dopplr で
2つめの OpenID (例 http://example.com/bar) でログインを試み
たとき, OpenID.sun.com
(というか OpenID Extension for OpenSSO)
は即 Dopplr に 「openid.mode=cancel」 のレスポンスを返却してきた
(個人的には, これはすごくまっとうな挙動に思える).
あとたけまるさんのエントリでは
ログインユーザ名と OpenID が異なっていたとき，IdP はユーザをログアウトさせ
るやりかたが紹介されてるけど,
RP から明示的に IdP にユーザのインタラクティブな再認証を行なうよう要求する,
というのでもいいのではないかと.
若干それるけど,
SAML 2.0 だと, Service Provider (SP: OpenID でいうところの RP)
から IdP に, Web ブラウザのリダイレクトを経由してリクエストされる AuthnRequest の中で,
ForceAuthn を true (すでに認証済みであったとしても, このタイミングで認証必須),
IsPassive を false (ユーザのインタラクション必須)
に指定することで, 上記のような挙動を期待することができる
(ご参考:
E-Authentication Federation Architecture 2.0 Interface Specifications の 1.7.2.1 Session Reset
の項の記述).
ひるがえって,
OpenID ではどうするか?
ちょっと調べてみた感じでは,
Provider Authentication Policy Extension (PAPE) 1.0 を採用して,
RP から IdP へのリクエストの中で
max_auth_age
(IdP が当該 End User を何秒前に認証したか)
を "0" にすればオッケーっぽい.
PAPE 1.0 はまだ草稿段階だけど, どうすかね.
(Translate to English)
Saturday Dec 15, 2007
|
|
|
|
