(Translate to English)
Monday Feb 28, 2005
CEC 2005 二日目.
昨日と同様, 午前は全体セッション, 午後はブレイクアウト 5 本の構成.
全体セッションは各製品分野の EVP (Executive Vice President)
たちが 1 時間ずつプレゼンテーションを行なった.
ソフトウェア担当 EVP である John Loiacono のパートで披露された
Sun Java System Identity Auditor
のデモンストレーション, good でした
(© 藤井さん).
関係ないけど,
他のスピーカーはみんなカジュアルな服装
(昨日の Jonathan にいたっては Dallas Mavericks のジャージ) だったのに,
x64 ネタで登場した
Andy Bechtolsheim
だけ一人ぱりっとしたスーツを着てて,
しかし話の内容はいちばん技術者寄りというギャップにちょっとウケた.
昼ごはんは昨日と同様, サンドイッチ + ポテトチップ + 特大クッキーの,
いわゆる brown bag lunch.
これに飽きた岩片さんはサラダを選択したのだが, はたしてその中身はこんなんであった ↓
野菜というか, むしろこれは植物だ.
さて, 午後に参加したブレイクアウトは以下の通り.
19:00 から, 引き続き Moscone Center で Club CEC と名打ったイベントが行なわれた.
AC/DC のトリビュート・バンド, その名も AC/DShe
のライブを Corona 片手に見物し, 本日は終了.
(Translate to English)
Friday Nov 26, 2004
先日の 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 を導入している.
- モバイル・サービス事業者は課金・決済の仕組みをすでに持っているから,
アイデンティティ・プロバイダとなって他のサービス・プロバイダにサービス提供する商機がある.
でもいずれにせよ,
アイデンティティ・プロバイダに伴う責務については慎重に検討する必要がある.
|
|
|
|
