Thursday Jul 03, 2008

最近のアイデンティティをとりまく 3 つの R

2008 年も折り返し地点を過ぎ, IIWBurton Group Catalyst Conference などの重要イベントもひと段落して, なんとなく今年のアイデンティティ界隈の流行りものがみえてきた. それはロール (role), 評判 (reputation), 関係 (relationship) の 3 つ.

ロール (role)

リソース固有の権限をグルーピングし, それをどのような場合に付与・剥奪するかのベースとなる 「ロール・マスタ」 は, 従来の IdM システムではどちらかというとおまけ的な扱いだった. しかし昨年後半以降 (Sun が Vaau を買収したり, 某同業他社が某社を買収してから), ロール情報にもアイデンティティ情報と同様のライフサイクル (生成, 分析, 修正, 削除, 承認 etc.) があって, きちんとした管理が必要だという認識が, 徐々に広まってきてる.

幣部でも最近 Sun Role Manager を Sun IdM ソリューションのパートナー向けに個別説明したり, エンドユーザー向けにセミナーを (まだ国内で出荷してないので, 若干フライング気味に) 開催してるんだけど, 「IdM をすでに理解している人」 に対してのウケが非常にいい. 国内でのリリースが楽しみ.

評判 (reputation)

いわずもがなという気もするけど, とりあえず IBMr とやらは気になる...

関係 (relationship)

どうやらこれが今回の Burton Catalyst の目玉だったらしい. 多くの参加者が書いている所感のうち, Mark Dixon のエントリと Dave Kearns の記事がよくまとまっている.

とくに Mark のメモはすごくよいので (その他のエントリもおすすめ), 一部よくわからないところはあるけど, 勝手に訳してみた.

  • わたしたちは自身のアイデンティティを知っているし, 自分と同じように, 他人のアイデンティティも正しいことを期待している.
  • 他人がどうふるまうかを予測するために, わたしたちは彼らのアイデンティティを, 彼らとのやりとりをベースにして作りあげる.
  • 企業や組織もまた, 関係をもとにして, (顧客の) アイデンティティを作りあげる.
  • アイデンティティの世界が広がっていくにつれて, 関係は薄まっていく一方, アイデンティティは適切でなくなっていく.
  • 「ロングテール」 とは, ビジネス上のつきあいがそれほどない人たちとの, やりとりの頻度が少なくなることを意味する.
  • 企業が正確な 「顧客のアイデンティティ」 を作り上げるには, 人々に関して, よりひんぱんに, 精度の高い観察をするための方法を見出す必要がある.
  • もしその情報収集システムが露骨だと, 人々はそれに抵抗する. 関係が, よりよいデータ収集によって強固なアイデンティティ・モデルをもたらすための場をつくり出す.
  • 「良い関係ふたつ」 は 「悪い関係ひとつ」 よりも優れている. ある二者の関係を仲介する存在は, しばしば役に立つ.
  • 関係こそがコンテクストである. コンテクストが, アイデンティティ情報のセキュリティとプライバシーを保護する.
  • Burton Group はリレーションシップ・オブジェクトを提唱した. このオブジェクトによって, 関係というものを, オンライン・システムが利用できるようなかたちに定義する.
  • このモデルでは, 関係は以下に分類される.
    • カストディアル (Custodial) - 密接なやりとりが行なわれる. 各当事者はお互いに, 他者の利益を最優先にして行動する. (企業と従業員との関係など)
    • コンテクスチュアル (Contextual) - おもなやりとりは, 仲介者を通じて行なわれる. 各当事者は, 広く同意されている制限事項への遵守に合意する. (企業間とか)
    • トランザクショナル (Transactional) - やりとりは, トランザクションを仕立てるアイデンティティ・プロバイダによって仲介される. 人々は, 自身が何者であるかをさらけださない. (顧客とか)
  • クレジット・カードのモデル (カード発行者がカード・ホルダに対し, カード詐欺に関する責任をほとんど要求しない) のような関係は, 信頼を築きやすい.
  • オンライン上で成功する企業は, 課金によって顧客と密接に関係することができるだろう. テレコムが今まさにそれ. スタートアップはそのような関係の構築を狙っている.

Discovering Identity: Catalyst: A Relationship Layer for the Web

最後は引用が長くなってしまったけど, ここしばらくはこの 3 つの R を軸にいろいろ考えていきたいなー, と思う今日このごろ.

Tuesday Oct 30, 2007

アイデンティティ・オラクルの価値

いまちょっと時間ができたので, すこし前にアイデンティティ好きの人たちの間で話題になっていた 「アイデンティティ・オラクル」 をめぐる一連のエントリを, いくつかつらつら読んでみた.

感じたことをいくつか.

Bob Blakley 氏のもともとのエントリでは the Identity Oracle needs to have a valuable asset, to which GiCorp strongly desires access. This asset is the big database of personal data, (中略) And allows the Identity Oracle to charge for its services, つまりアイデンティティ・オラクルが大量の個人契約者情報を預って, それをもとに派生情報を契約企業 (サービス提供者) に提供するモデルを想定しているけど, そもそもその 「大量の契約者情報」 の正しさをだれが保証するんだろう.

たとえば契約者が個人情報のひとつとして 「わたしは○×銀行の預金残高は 1 億円です」 という情報をアイデンティティ・オラクルに預けるとする. たぶんそこでアイデンティティ・オラクルは契約者に預金通帳なり残高証明書なりの提示を求めることになると思うんだけど, でもそれらは 「ある瞬間の預金残高」 を示すものでしかない. だから, 後日アイデンティティ・オラクルがこの預金残高情報を使って 「このひとはカネ持ってます」 と契約企業に回答したとしても, そのときには当該契約者は破産してるかもしれない. 結局, アイデンティティ・オラクルが有用な情報を契約企業に提供しようといくらがんばっても, その基となる情報が信頼できないと意味がない.

「預金残高が 100 万円を切ったら契約者は三営業日以内にアイデンティティ・オラクルに申し出なくてはならない」 とかいう感じで, 契約者に情報の新鮮さを保つよう義務を負わせればよいのかな. でもそれってめんどくさそうだし, だいたいがけっぷち状態のまっただ中にいる契約者が, わざわざ 「わたしは破産しました」 などというネガティブな情報をアイデンティティ・オラクルに連絡しないような.

一方で Nishant Kaushik 氏は, アイデンティティ・オラクルが契約者の一次情報をさまざまなオーソリテイティブ・ソースからオンデマンドに取り込んで, それらの情報から派生した結果を契約企業に提供するモデルを描いている. これであれば, 「○×銀行の預金残高」 を確認する相手として最もふさわしい, 「○×銀行」 そのものから, 確認時点での情報を得ることができる.

でもこれにもちょっとひっかかる点があって, それはアイデンティティ・オラクルが, 複数の, 契約者次第ではもしかしたら不特定多数のオーソリテイティブ・ソースと, 契約者の情報をやりとりしなくてはならないところ.

アイデンティティ・オラクルが, 契約者の指定した見ず知らずのオーソリテイティブ・ソースとの間で, 契約に基づく信頼関係をばんばん結ぶことができるような世界は, あまり現実的ではないと思う. かといってごく限られたオーソリテイティブ・ソースからしか情報を引っ張ってこれないというのでは, アイデンティティ・オラクル自体のサービスの魅力を落とすことになってしまうし.

...いずれのやりかたにしても, アイデンティティ・オラクルが権威のある回答を返すことは, ちょっと期待できないんじゃないかと思えてきた. たぶん, 第三者としての意見表明はできるだろうけど. つまり, 「この人は金持ちです」 ではなくて, 「(一ヶ月前の情報に基づいて判断して) この人は金持ちっぽいです」 とか 「(その契約者に関して唯一 available なオーソリテイティブ・ソースである 「近所のスーパーでの買いもの履歴」 をもとに判断して) その人は金持ちっぽいです」 とか.

で, こんなアイデンティティ・オラクルにカネを払いたい企業って, いんの?

Wednesday Sep 12, 2007

「OpenID とはなにか」 の, あまりにも的を射た定義 (橋の押し売り電話編)

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 のような 「確立された信頼関係に基づく運用が大前提」 のしくみを使ったほうがいいと思う.

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 のは社用車だな, きっと.

Friday Feb 16, 2007

RCSL: 関係継続性ソケット・レイヤ

またもや Burton Group ネタ, しかも直近の IdM 商売にはたぶん直接結びつかない話.

Mike Neuenschwander という人が Relational Continuity Sockets Layer (略して RCSL: 「アーシズル」 と読ませたいらしい) という概念を提唱してる.

... a kind of SSL sessions for relationships - for now I'll call it Relational Continuity Sockets Layer. It would allow multiple participants to interact on a channel that is secure for the duration of the relationship or at least one risk cycle (this means longer-lived sessions than SSL) and allows for relation IDs (similar to session IDs).
Burton Group Identity Blog: Law of Relational Risk

これに対する Mark Wahl のフォローアップもあわせてどうぞ.

This RCSL abstraction has several promising benefits for use in identity relationships.
Identity relationship management and the Relational Continuity Sockets Layer abstraction (2007/2/7) - LDAP.com - Commentary by Mark Wahl, CISA

ユーザを認証したあとどのようなサービスを提供するか (認可するか) については, 事前にユーザに付与しておいたアクセス権限情報やそれらをたばねるロール情報を使って決定することができる. しかし場合によってはあらかじめ設定されていない / 設定できない情報もとにして認可決定したいこともあるはずだ.

たとえば

  • 第三者機関の管理する, そのユーザの与信情報
  • どこかのネット・オークションでの, そのユーザの取引評価
  • あるソーシャル・ネットワーキング・サービスでの, そのユーザの友達リスト

などなど.

これらの情報はいまはアプリケーション・レベルで扱われてる (外部に問い合わせたりするためのロジックを書いてる) けど, それをもっと下の, SSL 的な位置で処理したらどうよ!? というのが, この RCSL というコンセプト (だと思う. 斜め読み). こういう 「信頼関係をミドルウェアで処理するスキーム」 といえば昔あったアイデントラス / エレノアが有名だけど (← 反論は受けつけません), 「ソケット・レイヤ」 という命名や, リピュテーションの活用を考えているあたりがいかにも今風にみえる.

だれか SAML ベースで RCSL 実装しないかなあ. Authentication, Attribute, Authorization Decision に次ぐ第四のステートメントとして Reputation Statement を定義. で, それを含むアサーションの発行主体となるのが Reputation Authority. 「いまアクセスしてきてるユーザと自分とはどういう関係なのか」 という質問をサービス・プロバイダから受けた Reputation Authority は, そのユーザに関するいろいろな評判の収集と, それがサービス・プロバイダに対してどのような意味をもつかを分析し, そして Reputation Statement を含む SAML アサーションをサービス・プロバイダに返却. それをもとに, サービス・プロバイダはサービスの内容を変化させる. なんかかっこよさげだ!

Friday Jan 26, 2007

2007 年の IdM 動向予測 by Burton Group

Burton Group が, 今年および今後のアイデンティティ管理市場動向に関する予測を発表した. 曰く, 法令遵守のためのアイデンティティ統制が引き続き最大のビジネス・ドライバーとなるとのこと. そのほかのキーワードは以下の通り:

  • SOA におけるアイデンティティ・サービス
  • インフォメーション・カード (e.g. Microsoft CardSpace)
  • より強力な認証

リポート (有料) をざっと読んでみた. たぶん IdM 関係者にとっては新味を感じられる内容ではないけど, IdM にこれまで関心の無かった人がとりあえずマーケットの動向を概観するための資料としては, 各分野がいい塩梅に要約されてるんじゃないかと思う. ただ一点, ベンダ比較表の横軸に 「マインドシェア」 を持ってくるのはどうなんだろうなー. 意味のある比較ができるとはちょっと思えないんだけど.

Monday Nov 06, 2006

世界一受けたい IdM コンサルティング

米国バートン・グループといえば, アイデンティティ管理に関わっている人ならみんな一目置いているアナリスト会社. 彼らは IdM に関して市場調査だけではなくコンサルティング・サービスもやっているんだけど, 実際にコンサルティングを受けた組織 (カルフォルニア大学デービス校) が, その成果物を以下に公開している.

IET : Identity Management
UC Davis Recommended Identity Management Architecture and Migration Strategy Executive Overview

スライドを見た感じ, やってること自体は

  • 多方面の関係者にインタビューを行なう
  • 顧客のシステム要件を整理する
  • リファレンス・アーキテクチャをもとに, 顧客にあった推奨アーキテクチャを作成する
  • フェーズ化された導入計画をたてる
  • プロジェクトの費用を試算する
  • 推奨ベンダを紹介する
  • ガバナンス・フレームワークを提示する

と, それほど意外なところはないんだけど, そこかしこに 「これは IdM に力入れてないと出てこないだろうなー」 といったエッセンスがちりばめられている (バーチャル・ディレクトリの推奨ベンダのひとつとして OpenDS を挙げるなんて, お目が高い!). おすすめ.

Tuesday Aug 02, 2005

ゼネラル・モーターズが Sun Java Enterprise System をグローバル IT のためのソフトウェア基盤に採用

徹さん藤井さんが書いているように, GM の Java Enterprise System (Java ES) 採用が先週公式に発表された.

米国サン・マイクロシステムズ社 (本社:米国カリフォルニア州サンタクララ、 会長兼 CEO :スコット・マクニーリ、以下サン)は、 ゼネラル・モーターズ・コーポレーション(以下 GM ) がグローバル IT の基盤ソフトウェアとして、 Sun Java(TM) Enterprise System を採用したことを発表しました。 この契約により、 Sun Java Enterprise System のサブスクリプション数はおよそ 100 万件に達します。
ゼネラル・モーターズが Sun Java Enterprise System をグローバル IT のためのソフトウェア基盤に採用

報道発表資料によれば, Java ES 導入の目的のひとつはアイデンティティ管理であった.

GM は以前より Sun Java Web Infrastructure Suite と Sun Java Application Platform Suite を利用しており、今後はこれに Sun Java Identity Management Suite を追加してポータル機能を拡張し、 安全で信頼性の高い環境を維持するとともに、 シングル・サインオンを採用して複数のパスワードを持つ必要をなくし、 より使いやすくする予定です。

Burton Group Catalyst NA 2005 の GM のセッションの資料を見てみると, アイデンティティ管理の対象となるユーザは相当な数に上るようで,

  • 情報システムへのアクセスが 40 万人 (正社員, 契約社員, サプライヤ, ディーラー, 小売業者, 流通業者, 合弁企業, アライアンス企業)
  • 物理的なファシリティ (入退館システムとか?) へのアクセスが 40 万人
  • そのほか退職者, 寡婦・寡夫, 消費者を含めるとさらに 100 万人以上

と, 少なめに見積もっても 100 万人以上いるらしい. このような

利用者数 (ID 数) >> 従業員数

という状況だと, Java ES の提案する企業内の従業員 (契約社員やパートタイムを含まない) 単位のサブスクリプション・ライセンスは, ユーザ数や CPU 数単位のライセンスと比べてかなり魅力的だったのではないだろうか.

また Sun Java Identity Management Suite 導入の目的は単にポータルのユーザ ID を管理するというだけではないらしく, 以下の記事曰く 「SOA のために Sun の開発ツールとアイデンティティ管理ツールを活用する」 のだそうだ.

GM was already a longtime SeeBeyond customer, using Sun's directory and portal products, but the new agreement will see the automotive giant leverage Sun's full development and identity management tools for an SOA built on Java and running on Sun's Solaris 10 operating system.

"GM is utilizing the full Java Enterprise System stack for cross component integration between our application server, our portals and our Web servers," said Fred Killeen, director of systems development and interim chief technology officer at GM. "As we begin to include new technologies within Java ES, such as the Sun Java Identity Management Suite, we will look at portlet standards such as WSRP, JSR-168 and SAML for the integration."
SearchWebServices.com: GM tabs Sun for SOA development

世間一般の SOA 云々の話は開発手法とかサービス・インタフェースのネタがほとんどで, サービス連携におけるアクセス制御や認証・認可・属性情報のライフサイクルを管理するアイデンティティ管理が SOA の基盤であると認識している人は少ないように感じる. そういう意味で, GM の戦略は先見の明があると思う.

Monday Jul 25, 2005

ネットワークこそがコンピュータであり, アイデンティティこそがネットワークである

The Network is the Computer.
Identity is the Network.

こないだの Burton Group Catalyst NA 2005 にて, ジョン・ロアコノ が使ったスライドに書いてあったフレーズ. なんかかっこいい.
Identity is the Network

Friday Jul 01, 2005

Sun Identity Management Update - June 2005

SIMN header
Sun Identity Management Update の最新号が今週公開された. 以下, 内容をいくつか簡単にご紹介したい.


Sara Gates, Vice President of Identity Management: The Shape of Things to Come

Sara Gates による, アイデンティティ管理の過去 (Internet Age) と現在 (Extranet Age) のまとめ, そして将来 (Participation Age) の展望.

'01 くらいに登場した 「アイデンティティ管理」 は企業システムのアクセス権設定を自動化することによる効率向上と費用低減が目的だったが, 現在では社内ユーザだけではなく社外の取引先や顧客にまで管理対象を広げてきた. その中で, 企業秘密のような組織情報やクレジットカード番号のような個人情報をどうやって守るか, 情報の改ざん防止に関する法律・条例を遵守するにはどうすればよいか, が新たな課題となっている.

これらセキュリティとコンプライアンスに関わる課題を解決し, 「参加の時代」 を実現するために, 今後のアイデンティティ管理には次のような機能が求められる.

  • アイデンティティ連携: 組織の壁を越えたアイデンティティ情報の再利用 (面白い表現だ)
  • アイデンティティ・サービス: 散在するアイデンティティ情報の統合
  • アイデンティティ監査・セキュリティ: アイデンティティに関するすべての活動の集中監視

Webcast: Beyond Provisioning - Expert Perspectives on Identity Auditing and Compliance

Sun, Deloitte & Touche, Gartner による, アイデンティティ管理とコンプライアンスに関するウェブキャスト. PDF 形式のスライドがダウンロードできる.

Customer Success: The Henkel Group

グローバルな製造業 (従業員約 5 万名, 世界 125 ヶ国に展開) における導入事例. Sun Java System Identity Manager により, 厳密な認可とアクセス管理, SAP R/3, Lotus Notes, Microsoft Active Directory, Novell eDirectory の ID 統合, 既存ID管理システム (メインフレーム) のリプレースを実現した.

Sarbanes-Oxley Compliance Journal: How to Solve Your Biggest Compliance Problem in a Sustainable Way

Sara Gates が Sarbanes-Oxley Compliance Journal に寄稿した, アイデンティティ・ベースの監査についての記事.


そのほか Sun Java System Directory Server Enterprise Edition における Active Directory から Directory Server へのパスワード同期の技術 Q&A, アイデンティティ連携のホワイトペーパー, 今月行なわれる Burton Group Catalyst Conference でのおトク情報など, 経営層向けから技術寄りまでいろいろなネタが盛り込まれている. Sun のソリューションに限らずアイデンティティ管理に興味のあるかたはぜひどうぞ.

Wednesday Dec 15, 2004

ID 連携の相互運用性

Burton Group の今月リリースしたレポート (有料) が面白い.

ID 連携は pairwise (一対一の個別関係) から始まり community (業界団体等が主導する関係), dynamic (連携機能・制度の広範な普及化) へと発展するもので (先日の Webcast で CEO の Jamie Lewis も話していた), その過程で重要となるのが interoperability, assurance, そして trust であると主張している.

相互運用性 (interoperability) はこの中でもとくに基礎となる要素であり, 実際の作業も比較的進んでいる. 目立った活動としては E-Authentication の Interoprability Lab と Liberty Alliance の適合性試験があり, 以下のようなテスト結果がすでに公開されている. どちらのリストにも Sun Java System Access Manager (旧称: Identity Server) が含まれているのが非常に素晴らしい :)

ちょうど先週, SAML 2.0 の相互運用性試験が実施されていた. 主催は Liberty Alliance, ホストは GSA eAuthentication Interop Lab. と言っても SAML 2.0 はまだ策定途中の仕様なので, 製品の不具合チェックというよりも, 公開審査および投票に向けて仕様の不明確な点を洗い出す (参考: OASIS SSTC の電話会議の議事録) という意味合いが強い. ちなみに Sun も参加. ほかにどんなベンダが参加してたか? 実はワシントンに行って作業してきた担当者に教えてもらったんだけど, それは機密保持契約があるのでここには書けないのであった. (Sun が参加した, というところまで公にするのはオッケイとのこと)

Liberty がフェーズ 2 仕様を発表してからもう一年以上たったし, SAML 2.0 も来年初頭には定まる見込みということで, もしかしたら 2005 年は ID 連携仕様の動向よりも相互運用性のほうに注目が集まるかも.

Friday Nov 26, 2004

Sun Expert Exchange: Enabling the Virtual Enterprise with Identity Management

先日の Webinar (山中進吾もネタにしてたやつ) に伴って行なわれた, Sun 主催の ID 管理に関するオンライン・チャットの筆記録が公開されている.

これがなかなか面白い. というか 「おー, ここまで言っちゃうのかー」 というネタもいろいろ記録されてて, インサイダーの立場からするとちょっと複雑な気持ちになる ;) その中からいくつかご紹介.

競合他社

「IBM と競合する」 とはっきり述べた上で, Sun と比較したときの IBM の弱味を次のように挙げている.

  • Sun Java System Identity Manager はプロビジョニング製品とメタディレクトリ製品が統合されているが, IBM はそれぞれ別個の製品 (Access 360 を買収して揃えた Identity Manager と, 以前からあった Directory Integrator の 2 製品) なので, 導入の費用・複雑性が上昇する.
  • Sun Java System Identity Manager はエージェントレス・アーキテクチャによって導入の負担を下げることができるが, IBM はいまだエージェントレス・テクノロジへの対応が遅れている.
  • Sun Java System Directory Server は負荷分散, フェイルオーバ, Web インタフェースのような, ディレクトリ・サービスに必要とされる機能を標準で提供しているが, IBM の場合はサードパーティ製品の導入か, ディレクトリとは別個の製品として購入が必要となる.

また 「Oracle の ID 管理と比べてどうか」 という質問には, 以下のような回答をしている.

  • Sun はディレクトリ, アクセス管理, プロビジョニング / 同期の機能を包括的なアイデンティティ管理スイートとして提供しており, これらを統合して使うことも, 他社の製品と組み合わせて使うこともできる.
  • また異種システムへの対応も考えられており, Oracle 環境 (たとえば Oracle Applications や Oracle RDBMS へのプロビジョニング) もそのひとつである.
  • 一方 Oracle のアイデンティティ管理ソリューションというのは, 基本的には Oracle のアプリケーションやデータベース・プラットフォームに対する ID 管理を主眼に置いたものである.

Sun と Microsoft との相互運用性

一番目はともかく, 二番目は言っちゃって良かったのかなあ. ``convergence'' という言葉をどのような意味に取るかで, ニュアンスはだいぶ変わってくるけど.

  • まずは, お互いの製品の相互運用性の保証をするところから始めている. たとえば Microsoft Exchange と Sun Java System Directory Server との連携など.
  • また, アイデンティティ連携の標準を融合させる作業を行なっている.

Sun アイデンティティ管理ソリューションの導入事例

導入企業の一社である, Merrill Lynch Global Private Client (Merrill Lynch の小口部門) のチーフ・アーキテクトが直接回答している. これは直接 Webinar のスライドを見たほうが分かりやすいかもしれない.

  • 現在 600 支店, 25,000 人の環境に Sun Java System Identity Manager を展開しているところ.
  • また約 150 万人の小口顧客をサポートするためにも, このロール・ベースの ID 管理を導入した.
  • 導入に際しては全体的なアプローチを行なった. SOA の考え方を取り入れて再設計したりとか.
  • 新しいアーキテクチャのフレームワークのひとつとして, 統一された, 矛盾のない, 監査可能なロール・ベースのアクセス管理 (RBAC) が必要となり, それをアイデンティティ管理によって実現した.
  • ROI はいま集計中だけど, 600 支店にわたる ID 統合や, 既存システムの整理などによって, きっと良い結果が得られるはず.

アイデンティティ・フェデレーション

Burton Group の人がアツく語ってる. たくさんあるので, とりあえず要点だけ.

  • アイデンティティ・プロバイダは ID の有効性を保証する立場にあるので, それに相応する責務が発生する. ID の不正使用のような問題が起きたときの紛争解決を有利に進めるには, 監査証跡やログ管理が重要.
  • B2B での Federated SSO は導入されつつあるが, ID の登録・許諾は個々のサイトに委ねられたまま. 登録プロセスの標準, と呼べるものはまだない.
  • フェデレーションは既存のビジネス・プロセスが確立している 「ペア」 同士から始まる. なぜなら, 何か問題が起きたときに直接双方で解決できるから. グローバルな信頼モデルが実現するのはそのあと, 第三者的なサービス (業界団体とか, 米国だと eAuthentication とか) を介して広がるのではないか.
  • 我々の調査では, 現在までに 200 以上の企業が B2B での認証情報の連携 (Web SSO) に SAML を導入している.
  • モバイル・サービス事業者は課金・決済の仕組みをすでに持っているから, アイデンティティ・プロバイダとなって他のサービス・プロバイダにサービス提供する商機がある. でもいずれにせよ, アイデンティティ・プロバイダに伴う責務については慎重に検討する必要がある.
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