(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
飲み会は,
1/18 (金) に決行ということで.
いまのところ参加者は以下の通り:
当日まではまだひと月くらいあるので, 都合のつくかたは
<tatsuoDOTkudoATsunDOTcom> へのメール, コメント, トラックバック,
口頭, 電話などなど, なんらかの方法での参加表明, お待ちしてます.
(Translate to English)
Thursday Dec 13, 2007
ZIGOROu さんに名指しされたので,
とりあえず
openid-ja
に入ってみた.
IRC のほうは,
いまちょっと微妙にいそがしいので,
少々お時間をいただきたく...
そういや日本語のメーリング・リストとしては,
リバティ・アライアンスが運営してる sig-japan
もある.
こちらは SAML / Liberty / OpenID / プロビジョニング / SSO
に限らずアイデンティティ一般を対象としてるので,
このへんに興味のあるかたはぜひどうぞ.
あと以前つぶやき気味に書いた飲み会の話,
先日の Liberty Day
の会場で何人か
(崎村さんとか高橋さんとか)
に打診してオッケーもらってたにもかかわらず,
その後ずっとのびのびにしてしまってた.
すみません.
ということでそろそろアイデンティティ飲み会やりたいんですが,
来月中旬あたりに東京のどこかでどうでしょ?
本エントリへのコメント, もしくは <tatsuoDOTkudoATsunDOTcom>
へのメールにてご連絡いただければ幸いです
(おすすめの場所があれば, ついでに教えてもらえるとありがたいです).
ちなみに個人的には 1/18 (金) がいいかなと思うけど,
あまり予定があわなそうだったらその前後の日で調整します.
それでは, よろしくお願いします!
(Translate to English)
Tuesday Nov 06, 2007
どうやらはてなスターでは,
ユーザが OpenID を使ってログインした段階で,
ローカルにそのユーザのログイン・セッションを生成するっぽい.
でも OpenID の現行の仕様にはシングル・ログアウトが定義されていない
(というか過去の議論
*1
*2
*3
を読む限りでは, 意図的に定義しない) から,
OpenID プロバイダ側でログアウトしても,
はてなスター側のログイン・セッションは破棄されずに残ることになる.
どう対処するかを勝手に考えてみた:
- OpenID の仕様上, これは期待どおりの挙動なので, なにも対応しない
- はてなスター側でログイン・セッションを管理するけど, セッションの有効時間を比較的短くする (30 秒とか, 5 分とか)
- OpenID でログインしている場合には 「xxx という OpenID でログインしています. はてなスターからのログアウトはこちら」 と表示する
- はてなスター側ではログイン・セッションを管理せずに, OpenID URL の妥当性を毎回確認する (かなり使い勝手が悪くなりそう)
- OpenID プロバイダでログアウトしたときに, 同時に使っていた Relying Party でもログアウトするような, ブラウザのアドオンを開発する
- OpenID におけるシングル・ログアウトの仕様を提案する
個人的には 2. がいいかなと思う.
最後のふたつはたぶんないだろうな...
(Translate to English)
Wednesday Oct 31, 2007
ひとつ前のエントリと微妙に関係するんだけど,
ユーザ自身が 「オーソリテイティブ・ソース」
になることのできるアイデンティティ情報が実はけっこう限定的であることは,
意外と見すごされてるのかもしれない.
先の例でいうと, 「銀行預金」 は自分自身の財産だから,
それを増減させる権限, すなわち預金残高の 「ライフサイクル」
のオーソリテイティブ・ソースはユーザになる.
これだけみると, あたかもその属性はユーザが完全に管理できるかのようにみえるけど,
しかし預金残高がいくらなのかを他者に認めさせるためには,
その他者にとって信頼することのできる別のオーソリテイティブ・ソース
(たとえば, ユーザの預金を管理している銀行) に,
「いま預金はいくらです」 ということを表明してもらわなくてはならない.
一方,
ユーザが 「ライフサイクル」 と 「現在の状態」 の,
両方のオーソリテイティブ・ソースになれる属性とはどういうものか考えてみると,
ひとつは Yvonne が
挙げているような情報,
すなわちユーザの 「プリファランス (preference)」.
たとえば 「わたしは菜食主義者です」 とか 「わたしの好きな色は青です」 とか.
もうひとつは
Gerald Beuchelt
の指摘を読んでなるほどと思ったんだけど,
ユーザが自分の意志で, 自分を表すために用いる 「ハンドル (あるいは pseudonym,
あるいはペルソナ)」.
どのハンドルを名乗るかをユーザは自由に選択することができるし,
またハンドルの生成・削除も自由に行なうことができる.
この両者のうち,
重要なトランザクションの中で本当に役に立つのはどちらだろうか?
っていったら, 多くの場合は前者のような 「一見自分の持ちもののようにみえて,
しかしその信憑性を他人に認めてもらうには第三者の表明が必要」
な情報しかないだろう.
ただ後者の類の情報に関してはユーザの管理下に置いておいたほうが,
プライバシーやメンテナンス・コストの面からもなにかと都合がいいと思う.
これらをうまいこと組み合わせるには,
Project Concordia
で考えられているような, OpenID と ID-WSF の連携がいいんじゃなかろうか.
前者の情報は ID-WSF の属性交換で,
ちゃんと権威のあるオーソリテイティブ・ソースを発見して, そこから直接情報を入手.
他方後者の情報は OpenID で, ユーザが好きなようにハンドルやプリファランスを指定.
なかなかおもしろそう.
(Translate to English)
Saturday Sep 29, 2007
いろいろ気になるネタはあったんだけど,
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
- [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
のエントリ.
(Translate to English)
Wednesday Sep 19, 2007
SDC 連載
「アイデンティティ管理の基礎と応用」
の第 9 回は,
前回インストール・設定した
OpenID Extension for OpenSSO
の動作確認.
今回は、 OpenID Extension for OpenSSO (以下 OpenID Extension) の動作を確認していきます。
アイデンティティ管理の基礎と応用(９):OpenID Extension for OpenSSO: OpenSSO の能力を活かした OpenID プロバイダの構築 (2/2)
本連載では
OpenID Extension の動作に最低限必要な設定の紹介にとどまっているけど,
これを実際の運用にあたってどのように構成していくかは,
Hubert
が
OpenID.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 を, ぜひおためしください!
(Translate to English)
Friday Sep 14, 2007
おととい書いたエントリに関して,
Shinichi Tomita さんがコメントしてくれてた.
どうもありがとうございます
(たしか,
2 年前の Liberty Alliance Dayでお会いしたことがありますよね).
書きかたがうまくなかったけど,
ぼくが言いたかったことのひとつは 「少なくとも現状は」 というところ.
「relying party 側が高いリスクを負うトランザクション」
に OpenID を適用した事例, そしてそこから得た教訓や最善慣行,
あるいはビジネス要件や法制度との関係についての考察は,
SAML / Liberty ID-FF と比較するとまだそれほど出揃っていないから,
もうちょっと様子をみたほうがいいんじゃないだろうか.
次に
IdPからRPへ向かっての事前制約がない、という点においては、
利点は失われてないと思うのだけど、この点はどうなのだろうか
については,
そのあとで冨田さん自身も
[アイデンティティ情報を世間一般に解放することが]
IdPにおいて受け入れられないことだという意見であるなら、
結局のところSAMLの「確立した信頼関係」
と等価なものを追い求めることになるのかもしれない
とおっしゃっているように,
IdP となる事業者が対象の RP を固定したいと考える場合もあるだろう.
その動機はたとえばサービスの囲い込みとか,
信頼関係にない RP
に損害を与えてしまって紛争にまきこまれたりしないためのリスク回避とか.
繰り返しになるけど,
IdP から RP へ向かっての事前制約がない
ことが IdP
のビジネスにどのような意味を持つのかを検討するには,
先行事例や研究が, 現状まだ十分とは言えないと思う.
(もしかしたら FUD (Fear, Uncertain, Doubt)
っぽく読み取れてしまうかもしれないので補足しておくと,
ぼく自身はこれに関しては OpenID のコンセプトのほうが柔軟性があると感じている)
ちなみに SSOCircle
というところが OpenSSO を使って SAML2 IdP 機能を提供してる
(実際には OpenID Extension
も導入されてて, OpenID プロバイダとしてもサービスしてる) んだけど,
ここのメタデータの交換方法 (連携のための設定) は
Get the SSOCircle Identity provider Metadata
して
importing your entity
するだけみたい.
はたしてうまくいくかどうかはさておき
(OpenSSO つながりの立場からいうとうまくいってほしいんだけど,
サービス提供者を引き込むにはキャラ立ちが弱いかな...),
こういう SAML の使いかたもあるということで.
最後に,
前にもちょっと書いたけど,
「ユーザ・セントリック」 とか
「デジタル・アイデンティティの民主化」
(苦笑) とか言われてるのに,
それとは真逆にあるホワイトリストとか
PKI を導入して信頼関係の問題を解決しようとするのは後ろ向きだと思う
(や, 理性ではそれらの必要性を理解できる. だけど, ねえ...).
ソーシャル・グラフとかユーザのコンテクストとか OpenID プロバイダの経営倫理,
過去の取引内容をソースとして,
Rapleaf
のようなところがユーザの 「そのトランザクションでの」
リピュテーション・スコアを計算し,
それをもって RP がサービス提供の可否を決定する,
そんな方向に進化していったらいいなあ.
P.S.
そういえばこないだ
Interop Tokyo 2007 の IdM ネタのパネルに参加したとき,
事前の打ち合わせで崎村さんと
「今日はリピュテーションに関して議論してみますか!」
と若干盛り上がったにもかかわらず,
結局本番では時間切れになっちゃったんだった.
一回このへんが好きな人同士で飲み会やりたいすねー.
(Translate to English)
Wednesday Sep 12, 2007
Burton Group の人による 「OpenID ってこういうものだよ」
の第二弾 (ちなみに前回は自動車のキー解除だった) は,
名づけて
OpenID-Inspired Bridge Buying.
あいかわらずうまいこというなあ.
The caller responds “I’m the bridge owner; I’m going to pass you to someone who will verify that I own the bridge.”
Burton Group Identity Blog: Freakonomics of OpenID
結局のところどうやって OpenID を使うかは,
トランザクションに関与する主体のうち,
だれが相対的に高いリスクを負うのかで決まる.
たとえば 「橋の押し売り」 のケースであれば,
おカネを払うことで本当に橋の所有権が得られるのか怪しいから,
買い手 (relying party) はいろいろな方法で “ACME bridge verification” の評判
(リピュテーション) を確認したり, あらかじめ信頼できる 「橋確認業者」
を勝手に自分の電話帳に書いておく (ホワイトリスト) ことになる.
一方でブログへのコメントやまとめサイトの編集に OpenID を適用する場合,
サービス提供者側が OpenID に対応することのリスクはあまりないので,
無条件にエンドユーザの OpenID を受け入れても
(promiscuous trust system
)
全然オッケー.
ただしそこに参加するユーザにとっては,
自身のアイデンティティがおびやかされる
(なりすまされたりする) ことがリスクになるから,
信頼のおけるアイデンティティ・プロバイダを選択したり,
自分自身がアイデンティティ・プロバイダになったりすることになる.
はてさて, OpenID は今後, 前者のような
「relying party 側が高いリスクを負うトランザクション」
の基盤に組み込めるようになるんだろうか!?
まあやってできなくはないだろうけど
(Sure, we can invent one
のくだりは皮肉がきいてておもしろい),
少なくとも現状は, SAML のような
「確立された信頼関係に基づく運用が大前提」
のしくみを使ったほうがいいと思う.
(Translate to English)
Wednesday Aug 22, 2007
今月の SDC 連載
「アイデンティティ管理の基礎と応用」
は
OpenID Extension for OpenSSO について.
はじめは動作確認までまとめようと思ってたんだけど,
設定手順を書くだけでけっこうな分量になってしまったので,
残りはまた来月.
OpenSSO に OpenID Extension for OpenSSO を組み合わせることによって、
OpenSSO のアクセス管理 / シングル・サインオン (SSO) アーキテクチャを最大限に活用した、
高機能な OpenID プロバイダを構築することができます。
今回は、この OpenID Extension for OpenSSO のインストールから設定までをご紹介します。
アイデンティティ管理の基礎と応用(８):OpenID Extension for OpenSSO: OpenSSO の能力を活かした OpenID プロバイダの構築 (1/2)
「365 Main が停電したせいで LiveJournal の OpenID サービスがいっとき死んだ ※」
例をひくまでもなく,
アイデンティティ・プロバイダは可用性が命
(実際にはそれだけじゃないけど).
だからこそ,
WAN 越しでマルチマスタ・レプリケーションできる LDAP ディレクトリと各コンポーネントを冗長化できるアクセス管理システムを最大限活かすことのできる,
OpenID Extension for OpenSSO をぜひどうぞ.
ちなみにいまチェックしてみたところ,
GlassFish v2 は執筆時点の RC1 から現在は
RC3 に,
OpenSSO も 20070821 版が出ているので,
これから OpenSSO を試すにはこれらの最新版を使ったほうがいいと思う.
あと OpenID Extension
も先週末までひとつバグがあったので,
もしこのフィックスが入る前のソースを使ってる場合にはアップデートをよろしくおねがいします.
※ 公平を期すために書いておくと,
弊社の外向けサイトも 365 Main にホストされてた (そして同じくダウンした)
んだよね...
(Translate to English)
Friday Aug 17, 2007
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 プロバイダは以下に限定されている.
- myopenid.com
- claimid.com
- livejournal.com
- verisignlabs.com
- myvauthid.com
- openid.sun.com
- myvidoop.com
- signon.com (*)
- idtail.com (*)
- xlogon.net (*)
同上
このように特定の OpenID プロバイダをあらかじめ決め打ちしておくこと
(「ホワイトリスト」) については
[Whitelisting is] against the spirit.
だとか
OpenID without white lists is what I call a promiscuous trust system
だとか賛否両論あるけど
(ぼく個人は 「OpenID の理念がどうであれ,
しくみをどう使うかはそれを使う人次第」 だと思う),
いずれにせよリストに
openid.sun.com
が入ってるのは, なんかちょっとうれしい.
(Translate to English)
Friday Jul 06, 2007
証明（authentication）と認証（authorize）は明らかに異なります。簡潔に説明するならば、ことユーザーのIDに対する証明と認証については次のように定義することができるでしょう。
- 証明
ユーザーが自分のものであると主張するIDに対して、そのIDが確かにそのユーザーであることを保証すること
- 認証
証明されたIDを認めて受け入れること
仕様から学ぶOpenIDのキホン − ＠IT
アイデンティティ管理 / ディジタル・アイデンティティの文脈で
authorize っていったら, ふつうは 「認可する」 という言葉をあてはめると思うけど.
つまり authorization とは 証明されたIDを認めて受け入れること
ではなく, 「authenticate された ID を認めて, どのようなサービスを提供するか判断する」
ということ.
この判断プロセスを 「認証」 と表現してしまうと, 余計な混乱を招くような気がする.
あと
●Identity Provider
(中略) どのようにしてEnd Userが彼らのIdPを（Consumerに対して）証明するかは、OpenID Authenticationの範囲外です
仕様から学ぶOpenIDのキホン − ＠IT
という箇所も, 原文は
How the End User authenticates to their Identity Provider is outside of the scope of OpenID Authenticaiton.
OpenID Authentication 1.1
となってるから, 素直に 「End User がどのように自身を Identity Provider に対して証明するか
(本人 / 本物確認) は,
OpenID Authentication の範囲外です」 と訳したほうがいいんじゃないだろうか.
(Translate to English)
Thursday May 31, 2007
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
とかで試してみるといいかも.
(Translate to English)
Tuesday May 29, 2007
来月のイベント告知をもう一本.
Interop Tokyo 2007
のコンファレンスにて, パネルに参加することになった.
お題はアイデンティティ管理.
- 6月15日 14:00～15:30
- C25 アイデンティティ管理の最新トレンド ～Lightweight Open認証技術群～
- ■ 講師 Chair /Speaker
- Chair
- 高橋 健司 NTT情報流通プラットフォーム研究所
- Speakers
- 工藤 達雄 サン・マイクロシステムズ株式会社
- 小野田 哲也 マイクロソフト株式会社
- 崎村 夏彦 株式会社野村総合研究所
セッション名とスピーカーのバックグラウンドを見た感じ,
内容的には SAML/Liberty, CardSpace, OpenID ネタがいろいろ出そう.
そしてぼくには SAML/Liberty の帽子をかぶることを期待されているっぽいなんだけど,
そうするべきなのかどうか, ちょっと悩み中.
モデレータ役の高橋さんに 「『アイデンティティ管理』 って言いながら 『にんしょー』
しか話題にしないのって, なんか不十分じゃないですか?
アクセス権限のライフサイクル管理の話もしないと意味無いんじゃないですか?
あとたぶん他のお二方は B2C
の世界のアイデンティティしか対象にしないんじゃないかと思いますが,
エンタープライズでのアイデンティティ管理 (つうかプロビジョニング / 監査)
には言及しなくてもいいんですか?」
的な質問をしたところ
「そのあたりも語ってもらって結構ですよ」
という回答を一応もらってるんだけど,
副題の 「Lightweight Open 認証技術群」 からは,
かなり外れてるかも.
社会人らしく 「SAML/Liberty 大好きっ子」 をまっとうするか,
「にんしょーにんしょー言う前に,
アクセス権限の付与・剥奪をどうやって管理するか考えないと意味ないじゃん」
と, 空気を読まずに主張するか,
うーん, どうしようかな.
とりあえず考え中...
(Translate to English)
Thursday May 10, 2007
「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 のは社用車だな, きっと.
«
Previous page |
Main
|
Next page »
|
|
|
|
