(Translate to English)
Thursday Jan 24, 2008
先週の飲み会をうけて,
冨田さんが
SAML の紹介を書いている.
ただ、今回はきっとtkudoさんが添削してくれるはずなので、
かなりのびのびと書いちゃいます。
SAMLについて自由勝手に紹介 - snippets from shinichitomita’s journal
と言われましても,
ツッコむべき間違いが見あたらないんですが ;)
あえて指摘するなら, どーでもいい部分で,
社内 IdP (Idenity Provider) として例示するのであれば
Sun Identity Manager
じゃなくて
Sun Java System Access Manager
のほうがしっくりくるなあってことくらい.
ちなみにぼくにとっての SAML2 の萌えポイントをひとつ挙げるなら,
実は過去にも何回か言及してるんだけど
(これとかこのへん),
やっぱり IdP Proxy.
これによって, たとえば以下にあるように,
あるサービス (SP: Service Provider) を利用したいときにその
SP の属する信頼の輪 (CoT: Circle of Trust) の中の IdP ではなく,
別の CoT 内の (つまり当該 SP とは直接の信頼関係にない) IdP を使って
SSO するようなことができる.
SACSIS2005 チュートリアル: アイデンティティ管理技術とその利用事例
Figure 4: Interconnection between two CoTs - MWS Network Identity Phase 2 Architecture Draft Version 1.0 – 1 June 2005
そういえば 2/15 (金) に都内で
「SAML2.0を利用したアイデンティティ連携」 のセミナーがあるみたい
(もしかしてこれが例の, SAML ブートキャンプ!?).
萌えどころ以外をさらにちゃんと学びたい人は,
これに出てみるといいんじゃないかと思う.
- 「第一回Liberty Alliance 技術セミナー」
- 日時 2008/2/15(金) 15:00〜17:00 (受付は14:45に開始いたします)
- 会場 NEC 本社ビル http://www.mapion.co.jp/c/f?uc=4&pg=1&ino=BA363571&grp=nec
- 参加料 無料 （事前登録制）
- スケジュール
- 15:00〜16:30 [SAML2.0を利用したアイデンティティ連携]
- 16:30〜17:00 質疑応答
- 講師 畠山 誠 日本電気株式会社 共通基盤ソフトウェア研究所
(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 11, 2008
「アイデンティティ飲み会」の件,
以下のみなさまに案内を送った (つもり).
もし届いていなかったらご連絡くださいませ.
それでは, 来週金曜の晩に!
(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)
Wednesday Oct 31, 2007
ひとつ前のエントリと微妙に関係するんだけど,
ユーザ自身が 「オーソリテイティブ・ソース」
になることのできるアイデンティティ情報が実はけっこう限定的であることは,
意外と見すごされてるのかもしれない.
先の例でいうと, 「銀行預金」 は自分自身の財産だから,
それを増減させる権限, すなわち預金残高の 「ライフサイクル」
のオーソリテイティブ・ソースはユーザになる.
これだけみると, あたかもその属性はユーザが完全に管理できるかのようにみえるけど,
しかし預金残高がいくらなのかを他者に認めさせるためには,
その他者にとって信頼することのできる別のオーソリテイティブ・ソース
(たとえば, ユーザの預金を管理している銀行) に,
「いま預金はいくらです」 ということを表明してもらわなくてはならない.
一方,
ユーザが 「ライフサイクル」 と 「現在の状態」 の,
両方のオーソリテイティブ・ソースになれる属性とはどういうものか考えてみると,
ひとつは Yvonne が
挙げているような情報,
すなわちユーザの 「プリファランス (preference)」.
たとえば 「わたしは菜食主義者です」 とか 「わたしの好きな色は青です」 とか.
もうひとつは
Gerald Beuchelt
の指摘を読んでなるほどと思ったんだけど,
ユーザが自分の意志で, 自分を表すために用いる 「ハンドル (あるいは pseudonym,
あるいはペルソナ)」.
どのハンドルを名乗るかをユーザは自由に選択することができるし,
またハンドルの生成・削除も自由に行なうことができる.
この両者のうち,
重要なトランザクションの中で本当に役に立つのはどちらだろうか?
っていったら, 多くの場合は前者のような 「一見自分の持ちもののようにみえて,
しかしその信憑性を他人に認めてもらうには第三者の表明が必要」
な情報しかないだろう.
ただ後者の類の情報に関してはユーザの管理下に置いておいたほうが,
プライバシーやメンテナンス・コストの面からもなにかと都合がいいと思う.
これらをうまいこと組み合わせるには,
Project Concordia
で考えられているような, OpenID と ID-WSF の連携がいいんじゃなかろうか.
前者の情報は ID-WSF の属性交換で,
ちゃんと権威のあるオーソリテイティブ・ソースを発見して, そこから直接情報を入手.
他方後者の情報は OpenID で, ユーザが好きなようにハンドルやプリファランスを指定.
なかなかおもしろそう.
(Translate to English)
Wednesday Oct 03, 2007
アイデンティティ管理に特化したカンファレンスとしては国内最大の,
Liberty Alliance Day.
今年は 10/26 (金) に品川インターシティホールにて開催される.
参加費用無料. ただいま事前登録受付中.
Sun からなにを展示しようか考えていたんだけど,
どうやら今回は
Pat
による OpenSSO のブースがちゃんと用意されるようなので
(ちなみに前回の Pat's 屋台はちょっとかわいそうなことになってた),
こちらでは一昨年, 昨年に引き続き
Sun Java System Identity Manager
を中心に紹介する予定.
もちろん Identity Manager のバージョンは最新の 7.1 だし,
準備が間に合えば Sun のミドルウェア・スタック全部入りデモも置こうと思っているので,
当日はぜひ弊社ブースにお立ち寄りくださいませ.
(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)
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 Jul 25, 2007
昨年末に
2007 年はどうなるか. まず, IdM とは 「パッケージをいれればオッケー」 ではなく 「継続的なイニシアチブ」 であることに多くの人が気づく. あと, 「職務分掌徹底のためのアクセス権限管理の大変さ」 がようやく実感されるようになる. 最後に, SAML 2.0 が ASP / アウトソーシング方面で地味に広がる.
IdM ゆく年くる年 - tkudo's weblog about identity management
と予測したけど,
とりあえず三番目のやつは的中ってことでいいですかね.
(要求仕様のひとつに 「アカウント情報を学内各種情報システムと連携」 という利便性を実現する必要があったが) SAML ベースの Single Sign-On （SSO） API の利用によって実現への確証を得た。(中略) SSO を用いればキャンパス内の全ての IT サービスへの展開をも可能とする。
Google Apps Education Edition の導入事例: 日本大学
Gmailならサーバからサポートまで無料で利用できる上、ライブドアとのID連携機能も容易に構築可能だ。「公開仕様のSAML（Security Assertion Markup Language）に対応しているから、ID連携も当社が開発でき、相手先が作業し終わるのを待つ必要もない」
livedoorメールにGmail採用 「黒字化へ最後の一押し」 - ITmedia News
このまま
- Google Apps / Gmail を利用したい企業が増える
- 利用する上で, さらに SSO したい企業 (アウトソーサー) は,
自社のアクセス管理 / SSO システムに SAML2 IdP 機能を付加することになる
- 結果的に SAML2 IdP 機能を持った企業が増える
- それらの企業が, Google Apps / Gmail 以外のサービス・プロバイダ (アウトソーシー) にも
「御社も SAML2 SP 対応してよ (そうすれば自社の SAML2 IdP がさらに活用できるから)」
とリクエストする
- それを承けてサービス・プロバイダも自社のサービスに SAML2 SP 機能を付加することになる
- 結果的に SAML2 SP 機能を持ったサービス・プロバイダが増える
- それらのサービス・プロバイダのサービスを利用したい企業が増える
- 2. にもどる
となって, さらに 2. と 3. のあいだに
- 企業が
Sun Java System Access Manager
を導入して自社のアクセス管理 / SSO システムを SAML2 IdP 対応にする
加えて 5. と 6. のあいだに
- サービス・プロバイダが
Sun Java System Federation Manager
を導入して自社のサービスを SAML2 SP 対応にする
が入るといいなー.
(Translate to English)
Thursday Jun 21, 2007
今月の SDC 連載
「アイデンティティ管理の基礎と応用」
は
アイデンティティ Web サービス.
IdM の基本的なところは,
これでひととおりおさえた, かな...
相互に連携する Web サービスを、
最終的にサービスを受ける 「利用者」 を中心に置いて実行させるには、
すべての Web サービスが 「そのサービスをリクエストしている大元は誰か」
を認識することが必要です。
そのためには、
Web サービス間で 「ユーザのアイデンティティ」
を相互に流通させることが必要です。
これを実現するためのアーキテクチャが、
「アイデンティティ Web サービス」 です。
アイデンティティ管理の基礎と応用(６):アイデンティティ Web サービス:エンド・ツー・エンドのアイデンティティ連携
|
|
|
|
