セキュリティ・マネジメント

ソーシャルブックマークに登録：
印刷用ページの表示

SOAを技術面から支える「アイデンティティ管理」の重要性

SOAシステムで本領を発揮するアイデンティティ管理基盤の構築ポイント

（2007年03月20日）

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

　アイデンティティ・プロビジョニング・システムでアイデンティティ・リポジトリに正確なアイデンティティ情報を設定することによって、サービスは的確にアクセスの認証・認可を行えるようになる。

　しかし、利用者がサービス提供者に直接アクセスするのではなく、複数のサービスを経由して間接的にサービスを利用するような構成においては、提供されるサービスを「だれが」利用しているかというサービス利用者のアイデンティティを特定することは簡単ではない。

　図4のような構成におけるエンティティ間のアクセス認証・認可を考えてみよう。

図4：サービス連携におけるユーザー・アイデンティティ情報の相互運用の問題

　ポータル・サービスがユーザーを認証し、アクセス可能な範囲を認可することはたやすい。また、ビジネス・サービスがブローカー・サービスからのアクセスを受け付ける場合に、「サービスに対する」認証・認可を行うことも比較的容易であろう。

　しかし、ビジネス・サービスにおいて、リクエストの大本がどの「ユーザー」なのかを判断し、適切なアクセス権限を適用するには、いったいどうすればよいのだろうか。

　ここで必要となるのが、各サービスが「ユーザーのアイデンティティ」を認識し、サービス間で相互に流通させるためのアーキテクチャ「アイデンティティ対応SOA（Identity-Enabled SOA）」である。

　アイデンティティ対応SOAを実現するためには、さまざまな要素技術を適切に取捨選択する必要があるが、実装および実世界において最も適用が進んでいるのが、標準化団体リバティ・アライアンス（以下、リバティ）が策定する各種仕様群である。

　リバティは2001年9月に設立された、現在150を超える組織（企業、非営利組織、政府機関など）が参加するビジネス・アライアンスであり、オープンなアイデンティティ標準の策定、ビジネスおよび導入ガイドラインの作成、プライバシー保護のためのベスト・プラクティスの開発、ならびに仕様適合性試験の実施などを行っている。

　2002年にリバティが公開した最初の「フェーズ1仕様」（バージョン1.0）は、基本的にWebブラウザによるドメイン間のフェデレーテッドSSO（シングル・サインオン）にフォーカスしていたため、現在でも「リバティ仕様はSSOである」という誤解が少なからず存在している。しかし、2003年にリリースした「フェーズ2仕様」以降、リバティは「アイデンティティWebサービス」（アイデンティティ情報を軸に相互連携するWebサービス）の標準化・普及に注力している。

　リバティの各種仕様のうち、主要なものを3つ以下に挙げる。

アイデンティティ連携フレームワーク（ID-FF）：Webベースのドメイン間SSOのフレームワーク。現在はOASISのSAML（Security Assertion Markup Language）2.0に統合されている。
アイデンティティWebサービス・フレームワーク（ID-WSF）：アイデンティティWebサービスを開発・運用するためのフレームワーク。2006年にバージョン2.0の最終版を公開した。
アイデンティティ・サービス・インタフェース仕様（ID-SIS）：ID-FFおよびID-WSFを活用する、具体的なアイデンティティWebサービスのインタフェース仕様。個人情報の参照・更新を処理するためのパーソナル・プロファイル・サービスなどを定義している。

　ここではリバティが提唱するアイデンティティWebサービスのユースケースを、B2B（企業間）におけるサプライヤー・サービスの利用を例にとって紹介しよう（図5）。

図5：リバティID-WSFのユースケース例

（1）まず、ユーザーは社外のサプライヤー・ポータル（SP）へアクセスする。ここでユーザーは社内のアイデンティティ・プロバイダー（IdP）でどのような認証状態にあるかという情報（認証ステートメント）をポータルに提示することで、ログイン処理を省略することができる。これがリバティの定めるドメイン間での連携SSOである。

　また、このインタラクションの過程でIdPからSPへ提供される情報は、認証ステートメントだけではない。IdPは同時に、「当該ユーザーが利用可能なアイデンティティWebサービスに関する情報」を管理するサービス、すなわちID-WSFディスカバリ・サービス（DS）の位置を示すブートストラップ情報も送付する。SPはこの情報を基に、ユーザーが利用可能なサービスをDSに問い合わせることができるようになる。

（2）ユーザーからの消耗品発注を受け、サプライヤー・ポータルは取引を処理するための業務サービスを実行する。

（3）このとき、業務サービスは、ポータル経由でキックされた処理リクエストが正当なものかどうか（あるいは、実際に発注したのはだれか）を把握する必要がある。そこでこのサービスは、ID-WSFにおけるWebサービス・クライアント（WSC）として動作し、DSに「このユーザーの情報を提供するサービスの場所」を問い合わせる。

（4）DSはユーザーの情報を提供するサービス（注1）を実装した社員情報サービス（EP）へのアクセスを許可し、EPへのポインタをWSCに返却する。

（5）WSCはEPに、ユーザー属性を提供するようリクエストする。

（6）EPはリクエストされたユーザー属性をすぐに返却することも可能だが、ユーザーの意向に基づいて公開の可否を制御することもできる。これを実現するのが、ID-WSFインタラクション・サービス（IS）である。EPはDSにISの場所を問い合わせる。

（7）その結果得られたポインタを基にして、ISに「ユーザーへの同意確認」をリクエストする。

（8）ISはユーザーに自身の属性を提供してもかまわないかどうか、携帯端末やインスタント・メッセージング（IM）、あるいはWebブラウザなどを介して確認する。

（9）ユーザーは自身の属性情報のうち、サプライヤーに対して提供してもよい属性を選択し（場合によっては公開を拒否し）、ISに回答する。

（10）ISはその結果をEPに返却する。

（11）EPは同意の得られた属性のみをWSCに提供する。WSCは受け取った属性を基に、現在発注処理をリクエストしているのがだれなのか、あるいは、そのユーザーに対するサービス提供が認可されているのか、どのようなサービスを提供するべきなのかを判断し、適切な結果を返す。

　このように、リバティ仕様を活用することによって、ドメイン間でのアイデンティティ情報の交換をエンド・ツー・エンドで行うことが可能となる。

　また、異なるエンティティ間のアイデンティティをお互いに匿名性を保ったまま結び付けるための仕組みや、上述のISによる「ユーザーの同意を得たうえでの」ユーザーの属性提供の仕組みなど、リバティ仕様があらかじめユーザーのプライバシーとセキュリティを十分に考慮していることも特筆に価する。現実のサービス連携における必須要素の1つであるアイデンティティの課題に正面から取り組んでいるのはリバティ仕様だけであると言っても過言ではないはずだ。

注1：ここではID-SIS社員プロファイル・サービス仕様（ID-SIS-EP）

アイデンティティ管理システムの構築ポイント

　アイデンティティ管理市場は、今、空前の活況を呈しており、ベンダー各社から数多くのアイデンティティ・プロビジョニング製品、ならびに、アイデンティティ・フェデレーション製品が提供されている。

　しかし、アイデンティティ管理システムを構築するにあたっては、製品を比較する前に、まずアイデンティティ情報がどのように管理・運用されているかを把握したうえで、構築フェーズを設定することが重要である。

　第1のステップは、既存の各サービスがどのようなアイデンティティ情報を必要としているか、そして、その情報のライフサイクルがどのようなビジネス・プロセスに基づいているかを洗い出すことから始まる。アカウント申請のユースケースや承認フローを文書化することによって、改善のポイントが明確になる。

　次に、アイデンティティ・リポジトリの統合とプロセスの整理を行う。ここで注意すべき点は、アイデンティティ・ライフサイクル・プロセスに影響を与える関係者が想像以上に多いということだ。サービス・オーナーやコンプライアンス担当者、人事システム担当者、セキュリティ責任者など、さまざまな利害関係者から意見を集めなければ、最適なプロセスは見いだせない。

　そしてこの段階で、プロセスを実装するためのアイデンティティ・プロビジョニング製品を選定する。アイデンティティ監査やワークフロー・エンジンを内蔵したフル・パッケージを導入して将来の拡張に備えるのか、それともデータ同期のみで十分なのかは、今後どのようなプロセスを取り込んでいくかによっておのずと決まってくるはずだ。

　その後、アイデンティティ情報が適切にプロビジョニングされたサービスの間で、標準仕様に基づくエンド・ツー・エンドのアイデンティティ・フェデレーションを実現する。ここでもアイデンティティ・フェデレーション製品ありきではなく、まずはアイデンティティ情報をサービス規約にどう取り込むかを定義し、それを受けて最適な製品を検討することが重要である。

　さらに、サービス連携は組織間、あるいは企業間へと広がっていく。ここでは技術的な要件よりも、ドメイン間でのサービス利用契約や紛争解決の手続きが重要度を増すことになる。これらを円滑に進めるうえでも、リバティの成果物であるベスト・プラクティスやガイドラインが役に立つだろう。

　こうしたフェーズを踏むことが、アイデンティティ管理の構築を成功に導くカギであると筆者は考えている。

＊　　＊　　＊

　アイデンティティ情報はすべてのサービス提供の基礎となる要素であり、SOAを導入するうえでも十分に検討すべき課題の1つである。適切なアイデンティティ管理はサービスへのアクセスに秩序をもたらし、ひいてはSOAのガバナンス向上に貢献する。

　そのためにはまず、アイデンティティ・プロビジョニングによって、だれにどのようなアクセス権限を付与するかを完全にコントロールする。その上で、運用時の認証・認可をアイデンティティ単位で行うアイデンティティ・フェデレーションを実施することで、「アイデンティティ対応SOA」を実現することが可能となるのだ。

（月刊Computerworld 2007年3月号に掲載）

前のページへ < ｜1｜2｜