アーキテクチャ・ジャーナル クレーム ベースのアイデンティティ管理 ―― オンプレミス ソリューションとクラウド ソリューション ―― Vittorio Bertocci 2009/07/06
Page1 Page2 Page3 Page4

■基本的な定義

　ここでは、クレーム ベースのアプローチを読み解く際に必要となる、さまざまな概念や構造について、例を交えて説明します。

●クレーム

　クレームとは、認証対象となるエンティティ（“サブジェクト”）に関する事実で、認証を行う別のエンティティ（“オーソリティ”）によって言及されます。

　クレームは、サブジェクトの任意の側面を表していればなんでもよく、実在する人物でも抽象的なリソースでもかまいません。クレームの典型的な例としては、“ボブは 21 歳を過ぎている”、“ボブは Contoso.com ドメインのリモート デバッガー グループに属している”、“ボブはスター アライアンス加盟航空会社のシルバー エリート メンバーである”などが挙げられます。クレームはオーソリティによって承認されます。このため、監視においては、オーソリティの信頼性に基づいてクレームに含まれている事実の真偽を判断します。

●信頼

　エンティティ A がエンティティ B の発行したクレームは真実であると判断した場合に、“A は B を信頼している”と見なされます。非常に単純ではありますが、ここではこの定義で十分です。サブジェクトに関する B の言明を信頼することで、A はそのクレームを直接検証する手間を省くことができます。なお、このような場合も、エンティティ A は、クレームが実際に B により発行されたものであって偽造ではないという点については、確認を行う必要があります。

●トークン

　セキュリティ トークンとは、オーソリティによって署名された XML コンストラクトで、クレームの他に資格情報を含む場合があります。

　セキュリティ トークンは XML フラグメントが記載されたアイテムで（「参考資料」セクションの「WS-Security」の項を参照）、次の 2 つの異なる役割を果たします。

• クレームを伝える手段を提供する。
• 暗号化に対応し、資格情報の認証において処理の一部を担う。

　非対称暗号方式を利用しているため、トークンが署名されているという事実に基づいて、そこに含まれるクレームのソースを簡単に確認できます。

　トークンには、キーやキー参照などの暗号化情報も含まれており、SOAP メッセージの暗号化と署名の際に利用できます。これらの処理は、資格情報の検証プロセスに組み込むことが可能です。なお、ここで“資格情報”とは、呼び出し元が既知のユーザーであることを確認するメカニズムで使用されるあらゆる情報のことを指します。例としては、パスワードや証明書が挙げられます。詳細については、私（Vittorio Bertocci）のブログ内の記事「The Tao of Authentication」を参照してください（URL は「参考資料」セクションに記載）。

　トークンでは、X509 証明書などの特定の認証テクノロジを反映させたり、SAML のような形で発行することが可能です（SAML とは、Web サービス セキュリティの分野でよく言及される標準的なトークンのフォーマットです）。新しいテクノロジが出現しても、プロファイルの仕様に基づいてテクノロジを反映したトークンを作成できるこのしくみは、将来的にも有効です。

●セキュリティ トークン サービス（Security Token Services: STS）

　セキュリティ トークン サービスは、WS-Trust（「参考資料」セクションの「WS-Trust」の項を参照）の仕様に基づくセキュリティ トークンを発行する Web サービスです。

　STS は、セキュリティ トークン要求（Requests for Security Token: RST）メッセージを処理し、RST 応答（Requests for Security Token Responses: RSTR）に基づいてトークンを発行します（図 1 参照）。通常、RST の処理には、呼び出し元の認証と、呼び出し元自身について言及したクレームを含むトークンの発行処理が伴います。STS では、RST で受け取ったクレームの内容を変換したクレームを発行することもあります 詳細については、私のブログ内の「R-STS」に関する記事を参照してください（URL は「参考資料」セクションに記載）。

図 1: セキュリティ トークンの構造

●アイデンティティ メタ システム（Identity Metasystem: IdM）

　IdM は、クレーム取得のため、特定のテクノロジにとらわれない抽象化レイヤーを提供するモデルです。

　これは非常に単純化した定義であり、実際のモデルに厳密には対応しておらず、たとえば、ポリシー配信やシステム管理には触れられていません。詳細については、「参考資料」セクションの「WS-Security」、「WS-Trust」の項を参照してください。

　すべてのアイデンティティ管理テクノロジは、標準的なパターンにのっとって、ほぼ同じ機能的役割を果たしており、多くの場合、同じタスクが遂行されています。IdM は、そうしたパターンや役割を抽象化して記述し、あらゆるシステムの動作を“クレームの交換”という観点からモデル化していますが、実装の詳細な方法については個々のテクノロジに委ねています。必要なレベルの抽象化は、WS-* 標準など、オープンで相互運用可能なプロトコルを利用して実現されます。

　IdM には次の 3 つの役割が記述されます。

• サブジェクト: クレームの定義時に言及しましたが、サブジェクトとは、トランザクションで確認する必要のある存在を指し、人、物を問わず該当します。

• リライング パーティ（Relying Party: RP）: RP は、アクセスを許可する前に認証を要求するリソースのことを指し、例としては Web サイトや Web サービスなどがあります。“Relying（信頼）”という語句が使用されているのは、確認が必要なサブジェクトに関するクレームを取得する際にアイデンティティ プロバイダーを信頼することに由来しています。

• アイデンティティ プロバイダー（Identity Provider: IP）: IP とは、クレームの定義時に言及したオーソリティ エンティティのことを意味します。IP はサブジェクトに関する情報を所有し、その情報をクレームの形で示すことができます。RP は IP を信頼し、IP のクレームに基づいてサブジェクトの認証と承認を判断します。なお、IP がトークンの形でクレームを発行する場合にはよく STS が利用されますが、“STS = IP”ではない点に注意してください。STS は、IP がジョブを遂行するために使用するツールの 1 つです。

■クレーム対応型ソリューションのアーキテクチャ パターン

　前述の基本的な定義は新しい認証アプローチの基盤となるもので、各要素を組み合わせることによって、どのようなシステムでもトランザクションでも記述できます。この新しいアプローチによって、従来は切り離して扱うことが難しかった（1）呼び出し元情報の取得（クレームに基づく）、（2）既知のユーザーであることの確認（証明書に基づく）という機能を分離することが可能になり、シナリオに合わせて選択ができるようになりました。詳細については、私のブログ内の記事「The Tao of Authentication」を参照してください（URL は「参考資料」セクションに記載）。

　なお、標準的なシナリオを記述する場合に非常に有効なパターンが存在します。この後、最も代表的な 3 つのパターンを取り上げ、クレーム ベースのアプローチがもたらすメリットを従来のアプローチと比較しながら説明します。すべてのパターンは、オンプレミスおよびクラウドの両方のアーキテクチャに使用できます。

INDEX
	［アーキテクチャ・ジャーナル］
	クレーム ベースのアイデンティティ管理
	1．クラウドの無限の可能性とクレーム・ベースのソリューション
	2．クレーム・ベースのアイデンティティ管理を理解するための基礎知識
	3．クレーム・ベースのアイデンティティ管理のアーキテクチャ・パターン
	4．クレーム・ベースのアイデンティティ管理をクラウドで利用する利点

「アーキテクチャ・ジャーナル」

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）