Tuesday Jan 08, 2008

OpenID をどう扱うかは, それを扱うサイトの考え次第

ひとつ前のエントリに関して, ネタ元のたけまるさんからたくさんのツッコミをいただいた. ありがとうございます & すみません, 正月休み中の一本目だったので, 浅知恵ご容赦ください... 以下, いろいろコメント.

まず簡単なところで, たけまるさんの環境では 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 とかであっても), 各サイトがアイデンティティをどう扱うかというポリシー決めがまずは重要かと.

Friday Sep 28, 2007

SAML での動的な信頼関係確立とか, OpenID まわりでちょっと興味をひいたこととか

いろいろ気になるネタはあったんだけど, Identity Insights の記事チェックや ISACA東京支部の例会 (b.s.c./tkudo で告知するの忘れてた...) のスライド作成に追われてて, ちょっと時間がたってしまった. ここらでひとまずまとめ書き.

  • IdentityMeme.org » Blog Archive » Latest revisions of SAML-lSSO and SAML OpenID Profile
    • Jeff Hodges による SAML OpenID Profile のアップデート. Service Provider (SP) は事前に Identity Provider (IdP) のメタデータを持たずに, ユーザが指定した OpenId String を via Yadis, XRI, or HTTP GET によって解決し, IdP を決定する. また IdP も事前に SP の情報は持たずに, SP からの <AuthnRequest> 中の AssertionConsumerServiceURL を使って SP のエンドポイントを決定する.
  • Pat Patterson : Superpatterns: YADIS/XRI Identifier Resolution with SAML 2.0
    • で, それに近いことをやったのが Pat のデモ. しかしこのデモでは, SP は IdP のメタデータを動的に取得しているものの (cf. saml-metadata-2.0-os.pdf の 4.1.1 Publication), IdP は SP のメタデータをあらかじめ静的に持っている, とのこと. ただそのへんは OpenSSO のコードにちょっと手を加えるだけでなんとでもなる (by Pat).
  • saml-core-2.0-os.pdf
    • ということで, 技術的に言えば SAML は双方向の信頼関係がなくても動作する. ただし SAML 2.0 仕様の Assertions and Protocols (3.4.1.4 Processing Rules) には次のように書いてある. つまり responder (IdP) が presenter (SP) を認証できない場合には, エラーを返却しなくてはならない (MUST) ということ.

      If the responder is unable to authenticate the presenter or does not recognize the requested subject, or (中略), then it MUST return a <Response> with an error <Status>, and MAY return a second-level <StatusCode> of urn:oasis:names:tc:SAML:2.0:status:AuthnFailed or urn:oasis:names:tc:SAML:2.0:status:UnknownPrincipal.

      これをどのように解釈するか. 素直にとれば, 「あらかじめ信頼関係を確立していない SP からの AuthnRequest を IdP は拒否しなくてはならない」 と理解するのが自然だろう. けど IdP が SP をどのように認証するかはここには書かれていないから, SP のメタデータを IdP が持っていなかったとしても, 「わたしはなんらかの方法で動的に SP を認証できます!」 と IdP が言い張るのもアリかもしれない.
  • 9. NZ SAMS Constraints on OASIS SAML v2.0 Metadata - New Zealand E-government Programme
    • ちなみにニュージーランド政府の SAML 導入では, 動的なメタデータ交換を禁止してる. その理由も含めて, SAML 運用のプラクティスとして非常に参考になる.

      Deployment guidance: Metadata Publication Resolution is NOT universally supported in vendor products (especially the DNS DDDS-style of publication). Metadata Publication/Resolution is most useful for automatic/dynamic establishment of associations between the partners. It is unlikely to attract significant numbers of SAML v2.0 deployments. Instead, metadata files are typically created and exchanged out of band between co-operating partners and then imported into the local system to configure interaction with the partner. This provides significantly better administrative control over system configuration and prevents partners from making a change that breaks interoperability.

  • Anyway Sun’s OpenID IdP: Business Purpose
    • プラクティスといえば, Lauren Wood が OpenID.sun.com のまとめを書いている. So in the formal security review of the system, one of the first questions was, what’s the purpose of this system? Under 35 accesses of some consumer site (relying party) per week, most weeks We use HTTPS for everything except the openid identifier itself などなど.
  • Pushing String » Sun OpenID IdP: protocol and implementation review
    • 上のエントリを承けての, Eve Maler のフォローアップ.
  • [OpenID] [legal] Draft OpenID Intellectual Property RightsPolicy for Review
    • OpenID 仕様の IPR Policy についての疑念. The proposed rules would also prevent all OpenID implementations from re-using portions of the text in the standard, for documentation, which may be a typical real-world scenario とはさすがにならないと思うけど, どうなんだろか.
  • LDAP.com - Commentary by Mark Wahl, CISA - Digital ID World and OpenID URLs (20070925)
    • France Telecom の OpenID に関して, その発表があったセッションに出席してたらしい Mark Wahl のエントリ.

Wednesday Sep 19, 2007

SDC の IdM 連載 (9): 続: OpenID Extension for OpenSSO

lis.example.com

SDC 連載 「アイデンティティ管理の基礎と応用」 の第 9 回は, 前回インストール・設定した OpenID Extension for OpenSSO の動作確認.

今回は、 OpenID Extension for OpenSSO (以下 OpenID Extension) の動作を確認していきます。
アイデンティティ管理の基礎と応用(9):OpenID Extension for OpenSSO: OpenSSO の能力を活かした OpenID プロバイダの構築 (2/2)

本連載では OpenID Extension の動作に最低限必要な設定の紹介にとどまっているけど, これを実際の運用にあたってどのように構成していくかは, HubertOpenID.sun.com システムに関してまとめた以下のエントリが参考になると思う.

  • OpenID @ Work - Architecture
    OpenID.sun.com の提供するサービスの構成. ぼくの書いた記事の中ではユーザの登録を OpenSSO 管理者 (amadmin) が手動で行なったり, OpenID Identifier でポイントされる HTML を静的に置いたりしたところを, 一方の OpenID.sun.com ではユーザ登録を OpenSSO の機能を使ってセルフサービス化し, また HTML を動的に生成しているところがポイント.
  • OpenID @ Work - Infrastructure Description
    OpenID.sun.com の機器構成. ぼくの書いた記事の中では全部をひとつの GlassFish インスタンスで実行してるところを, OpenID.sun.com ではユーザ情報をちゃんと Directory Server に格納し, かつ OpenSSO も含めて冗長化. さらに前段にファイアウォール / ロード・バランサを配置して, 負荷分散と SSL の終端処理も行なっている.

なお前回今回の記事をご覧いただくとわかるように, OpenID Extension は OpenSSO とは独立して動作する Web アプリケーションとして実装されている (OpenSSO からみると, OpenID Extension は Policy Agent インスタンスのひとつとして認識される). つまり OpenSSO 側には単に OpenID Extension からの通信を受けつけるための接続情報だけ登録すればよくて, OpenSSO システムになにか特別なモジュールを組み込む必要はない. そしてぼく自身はまだ確認できていないんだけど (すみません), この OpenID Extension は Sun Java System Access Manager システムと組み合わせても動作するはず.

もしすでに Sun Java System Access Manager を導入・運用されているサイトで, さらに OpenID プロバイダの実現可能性を探りたいという野望 (?) をお持ちのかたは, 既存の環境にほとんど影響を与えずに導入することのできる OpenID Extension for OpenSSO を, ぜひおためしください!

Friday Aug 17, 2007

OpenID.sun.com を使って AOL の一部にログインできるようになった, らしい

AOL が, とりあえず現時点ではアカウント管理サイトに対してのみだけど, 外部の OpenID プロバイダを使ってログインできるようになったみたい.

So here is the scoop. We did finish the infrastructure work on the AOL login side, required to support 3rd party OpenID users to login into AOL, (以下略)
AOL & OpenID - Status Update | dev.aol.com

ただし, サポートする OpenID プロバイダは以下に限定されている.

  1. myopenid.com
  2. claimid.com
  3. livejournal.com
  4. verisignlabs.com
  5. myvauthid.com
  6. openid.sun.com
  7. myvidoop.com
  8. signon.com (\*)
  9. idtail.com (\*)
  10. xlogon.net (\*)

同上

このように特定の OpenID プロバイダをあらかじめ決め打ちしておくこと (「ホワイトリスト」) については [Whitelisting is] against the spirit. だとか OpenID without white lists is what I call a promiscuous trust system だとか賛否両論あるけど (ぼく個人は 「OpenID の理念がどうであれ, しくみをどう使うかはそれを使う人次第」 だと思う), いずれにせよリストに openid.sun.com が入ってるのは, なんかちょっとうれしい.

Thursday May 31, 2007

OpenID.sun.com - OpenID at Work

OpenID.sun.com がいよいよ運用開始! (via たまたま見つけた del.icio.us のブックマーク. てか, まだ社内にアナウンスされてないっぽい!?)

ホーム・ページの紹介文が簡潔にまとまっててよさげなので, さらっと訳してみた.

Sun Identity Provider for OpenID

OpenID は軽量かつ非集中的な認証システムであり, 今日の Web を構成する一部となりつつあります. 市場をリードするアイデンティティ管理ソリューションをさまざまな顧客に提供していくという戦略の一環として, Sun は重要なテクノロジーのすべてにコミットしていますが, OpenID もそのひとつです.

それゆえに, わたしたちは OpenID アイデンティティ・プロバイダを立ち上げました (といっても, ヒネリが効いてます!). わたしたちは, Web 上のアイデンティティに関して最適なソリューション, そして利便性, コントロール, セキュリティ, プライバシーの要件を充たすソリューションとはなにかを, 直接体験することで学びたいと考えています.

わたしたちが OpenID アイデンティティ・プロバイダに加えた 「ヒネリ」 とは, 「このシステムにアカウントを所有する人は Sun の社員である」 と保証すること, です. アカウント所有者は自分自身のユーザ名を自由に選択することも, また実際の氏名のかわりに架空の名前を使うこともでき, そして Sun のメール・アドレスを使ってサインアップする必要もありませんが, そのアカウント所有者は 「Sun の社員」 でなくてはならないのです. わたしたちはパートナーに, このサービスを用いて認証された Sun の社員に対する, 特別なサービスの提供について話を進めています. もちろんこの OpenID のしくみはまた, OpenID を受けつけるウェブサイトであれば, どこででも利用することができます.

ということで, Sun の中の人はどしどしこの 「ヒネリの効いた OpenID サービス」 に参加しよう! ちなみに新規アカウント登録画面にアクセスするとユーザ名とパスワードを訊かれるんだけど, ここですでに持っている Sun Online Account を使ってログインしてしまうと, そこから先に進めないので要注意 (つうか, ぼく自身が説明読まずにやってたらちょっとハマってしまった). 正しくは Use your Sun email address and your corporate password to log in. と書いてある通り, たとえばぼくだったらユーザ名に 「タツオ.クド@sun.com」 を指定してログインすること. あとはページの指示通りに登録を進めていけば, すぐに使えるようになるはず. たとえば Ma.gnolia.com とかで試してみるといいかも.

Thursday May 10, 2007

「OpenID とはなにか」 の, あまりにも的を射た定義

「OpenID とは, だれかに対して自分がそのクルマの所有者であることを示すために, キーホルダーのアンロック・ボタンを押す行為の Web 版である」 だって. この表現はすばらしい!

(OpenID is) a web version of showing someone you own a car by hitting the "unlock" button on your key fob.
Burton Group Identity Blog: Braying About Sun's OpenID Support

で, そのクルマがなんなのかは, また別の話. もしかしたらレンタカーかもしれないし, 盗難車かもしれないし, オヤジの愛車をだまって借りてきただけかもしれない.

このたとえでいくと, Sun のは社用車だな, きっと.

Monday May 07, 2007

Sun が社員向け OpenID Provider サービスをローンチ

たぶんすぐに sun.com のほうでもアナウンスされると思うけど, PR Newswire がいちばん早かったので.

現状の OpenID が 「ブログへのコメント」 のような低リスクのトランザクションにしか役にたたない (意訳) のを改善するためになにが必要か, どう運用していけばよいかを探るべく, Sun みずからが実際に社員向け OpenID Provider を運用したり (システムは当然 OpenSSO と OpenDS によって構築), 逆に自社サイトを OpenID 対応にしたり, Sun(TM) Web Developer Pack に OpenID サポートを入れたりと, いろいろ試していく予定.

それにしても, 約 34,000 人いる社員全員にいきなり OpenID サービスを提供する (つまり ID の真正性を Sun が担保する) とは, 社員ながらびっくり. blogs.sun.com もそうだったけど, あいかわらずやることが極端だなー. (もちろんほめ言葉)

About

tkudo

Search

Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today