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

■基本パターン: サブジェクト - IP - RP

　このパターンは、最小限の認証管理が行われる状況に対応します。ここでは、サブジェクトがアクセス制限の設けられたリソース（RP）へのアクセスを試みています。こうしたケースは、Windows ユーザーがネットワーク共有にアクセスしようとする場合、スマート クライアントがセキュリティで保護されたWeb サービスを呼び出す場合、ネット サーファーがアクセス制限のあるコンテンツを閲覧しようとする場合など、あらゆる状況で発生します（図 2 を参照）。このパターンの処理順序は次のとおりです。

1. RP が要件をポリシーの形で発行します（外部での処理）。要件には次の内容が含まれます。
   1. クレームのリスト。
   2. RP がクレームのソースとして信頼する IP。
   3. RP が使用できる認証テクノロジの詳細（利用可能なトークンのフォーマットなど）。
2. サブジェクトが RP のポリシーを参照し、条件を満たしているかどうかを確認します。実装では、これは、サブジェクトが、RP の信頼する IP から適切なトークンを入手できるかどうかを確認する手続きになります。
3. サブジェクトが適切な IP を呼び出し、RP のポリシーに適合するトークンを要求します。実装では、これは、多くの場合、IP が利用する STS に RST メッセージを送信する手続きになります。
4. IP が RST を受け取り、サブジェクトを認証します。既知のサブジェクトである場合、IP は必要なクレーム値を取得してトークンに格納し、署名してサブジェクトに返送します。
5. サブジェクトがトークンを受け取り、RP の呼び出しに使用します。
6. RP がサブジェクトのメッセージからトークンを取得し、信頼する IP によって署名されているか、適切なクレームが含まれているかを調べます。両方の条件を満たしていることが確認された後は、次の処理が行われます。
   1. クレームの値がアクセス制御のロジックに入力されます。
   2. アクセス制御のロジックでクレームの値が承認されると、その値がリソースで有効となり、アクセスが許可されます。

図 2: “サブジェクト - IP - RP”のパターン（数字は本文に対応）

　説明をわかりやすくするため、リソースが Web サービスであると仮定してみましょう。そうすると、このパターンに数々の優れた特性があることがわかります。

●認証処理の外部化

　トークンとクレームを使用することで、リソース側でアイデンティティ管理用のコードを明示的に記述する必要がなくなります。トークンのシリアル化解除、署名の確認、通信時に使用したトークンのフォーマットに関係なくリソース開発者がクレームの値をスムーズに利用できるようにするための処理などを、RP ポリシーの発行を担うインフラストラクチャ側で実行できます。また、クレームの値に基づく承認の判断をインフラストラクチャ側で実行して、開発者の負担をさらに軽減することもできます。

　これは、あらゆるシナリオに当てはまるメリットですが、ホスティング テクノロジがさまざまに異なるクラウド環境では特に有効です。クレームによって、ホスト元のインフラストラクチャの要件や実行時に使用される認証テクノロジに制約されることがなくなるため、リソースを真に移植可能なものにすることができます。

●リソース レベルのポリシー

　リソース レベルでポリシーを指定できるため、きわめて迅速な展開、きめ細かな制御のほか、動的なネゴシエーションによる最適な認証テクノロジの選択が可能になります。また、相互運用可能な標準規格を使用しているため、ホスティング環境に関係なく機能する管理手法を確立できます。リソース自体を実行環境から分離しているため、クラウドを始めとする別の環境への移植もより容易になります。

●自律性

　すべてのリソースは自律的な手法で要件を指定し、サブジェクトではその要件に合わせて属性の調整を図ります。このサブジェクトとリソースの連携は、新しいメリットを生み出しています。両者は互いにとらわれずに変化することが可能であり、リソースにアクセス可能なサブジェクトは“リソースの要件を満たしているかどうか”という点のみに基づいて定義され、何らかの外的条件やインフラストラクチャの要件に制約されることはありません。どのような場合にも、リソースの要件とサブジェクトの属性のみを考慮すればよいため、このしくみは非常に安定しています。明示的なネゴシエーションや調整が不要なため、新しいユーザーの追加も非常に簡単です。

●認証と承認のロジックの一元化

　このパターンでは、属性の取得はすべて IP が実行します。RP は必要な情報をトークンの形で受け取るため、他のシステムへ問い合わせを行う必要はありません。これは、RP が属性へのアクセス権を持たない場合（航空会社 A がパートナーの航空会社 B にサブジェクトのマイレージ サービス ステータスを問い合わせる場合など）に有効な手法ですが、その他、属性取得のロジックを 1 か所に集約できるというメリットもあります。属性ストアへのアクセスを必要とするエンドポイントの数を減らし、管理性を高めてセキュリティの向上を図れると同時に、アクセス回数自体を減らすこともできます。サブジェクトはトークンを一度取得した後、その有効期限が切れるまで IP に再アクセスせずにトークンをキャッシュして再利用できるからです。また、承認の判断に IP を使用することも可能で、この場合もクレームによる情報を利用できます。ただし、こうしたケースは、IP がサブジェクトとリソースの双方と密接な関係にある場合に限られます。例として、“IP がディレクトリであり、そのディレクトリで管理されるリソースの 1 つが RP である”というシナリオが挙げられますが、ほとんどの場合、RP と IP の間には特筆すべき関係は見られません。

　ここで述べたことは、リソースがユーザー情報の確認に際して外部の IP を信頼する必要のある、多くのクラウド型のシナリオにとって重要なポイントとなる他、テクノロジやプラットフォームに依存しないトークンを使用してパートナー組織のユーザーを表すことで既存のフェデレーション機能の即応性を高めたい場合、さまざまな環境をまたがったソリューションを求めている場合などにも非常に有効です。

■クレーム変換を利用するパターン: サブジェクト - IP - クレーム変換 - RP

　前述のパターンは、通常の顧客向け（航空会社 A のマイレージ サービス利用者がパートナーの航空会社 B の Web サイトにアクセスするシナリオなど）から企業向けまで、さまざまなケースに適用可能です。企業では、Kerberos 認証シナリオを利用するほとんどのケースで利用でき、特定のテクノロジに依存しないというメリットも得られます。

　ただし、このパターンをそのまま適用することができない次のようなケースが存在します。

1. 間接的な信頼: IP とサブジェクトとの間に何らかの関係が結ばれている場合、RP がその IP を直接信頼できないことがあります。そのような場合は、媒介的なオーソリティを設定して信頼を間接的に確認することができます。たとえば、飛行機を利用する場合、なんらかの身元証明書を提示したとしても搭乗を許可してもらうことはできません。搭乗口では該当の航空会社により発行された搭乗券のみが信頼されるからです。手元にある身元証明（政府発行のパスポート、運転免許証など）が有効なのは、搭乗口ではなく、チェックイン カウンターで航空会社が発行する搭乗券を入手するときです。

2. クレームのフォーマット:サブジェクト側が認識可能なフォーマットで IP が発行したクレームを、RP 側では認識できない場合があります。これは、フォーマットの問題（例: イタリア語で書かれた私の身元証明書では“生年月日”は“nato il”であり、米国の酒場でバーテンダーにこれを提示しても彼は私の年齢を認識できない）に起因することもありますが、RP が受け取った生の情報に何らかの処理を施すことによってクレームを確認するような状況（例: RP が“飲酒可？”というクレームを要求し、“年齢”と“国籍”に関する情報を処理した結果に基づいて判断を下す）においても発生します。

　この新たな制約は、“クレーム変換”という新しい処理を追加することによって簡単に解決できます。クレーム変換とは、トークンをリソースへの到着に先立って加工するもので、RP はこれを利用して間接的なやり方で信頼を確認し、取得したクレームを適切なフォーマットに変換します。サブジェクトと RP の間にいくつものクレーム変換が介在する場合も、ポリシーの動的なネゴシエーションにより適切なルートが存在するかどうかが検証され、ルートが自動的に選択されるため、全体的な調整にわずらわされることはありません。

　クレーム変換の実装に最適なアイテムは、やはり STS です。クレーム変換では、発行されたクレームのデータ ソースのデータをそのまま設定する代わりに、STS が受信情報を処理する中心的な役割を担います。従来のフェデレーションのケースのように、STS は RP を所有するエンティティにより利用されることが多いため、この種の STS は通常、“R-STS（Resource STS: リソース STS）”、“RP-STS”などと呼ばれることがあります。詳細についてはブログ（URL は「参考資料」セクションに記載）を参照してください。

　クレーム変換にはいくつもの優れたメリットがあるため、今後、分散システムでのアイデンティティ管理パターンの主流になっていくと思われます（図 3 参照）。

図 3: 基本的なクレーム変換のパターン。サブジェクトは IP からトークンを取得し（1）、クレーム変換によって加工されたトークンを入手するために使用（2）。クレーム変換の R-STS（Resource-STS、後述）では、到着したクレームを処理して、サブジェクトに新しいトークンを発行（3）。サブジェクトは新しいトークンを使用してリソースの呼び出しを実行（4）

●リソースのクラスター化

　クレーム変換により、個々のリソースとエンタープライズ レベルのディレクトリとの間でのきめ細かな処理が可能になります。たとえば、R-STS を使用して、類似した要件を持つ複数のリソースを集約することで、個々のリソースのポリシー管理を簡素化し、間接的な信頼の確認やクレームの加工などの煩雑な作業を一元化することができます。エンタープライズ レベルでの対応は不要です。R-STS は、ネットワークの他の要素とうまく連携させることが難しい従来型のリソースを保護する、実質的な境界になります。以上は、クレーム変換の有効性を示すほんの一例です（図 4 参照）。

図 4: R-STS を使用すると、類似したポリシー要件を持つ複数のリソースをクラスター化できるため、信頼管理を簡素化し、認証/承認のロジックを外部処理するレベルを細かく制御することが可能になる

●承認の判断

　通常、IP が独立したエンティティであるのに対し、R-STS はほとんどの場合、処理対象のリソースに関する情報を保有しており、その情報に基づいて、承認の判断を下します。到着したクレームはサブジェクトのアクセス対象であるリソースの要件と共に処理され、サブジェクトが必要な権限を保有しているかどうかを基準に承認が行われますが、ここでは次のような異なる処理のパターンが存在します。

• サブジェクトが何の権限も保有していない場合、R-STS はトークンの発行を拒否し、呼び出しをブロックして、承認の判断を下します。

• サブジェクトが何らかの権限を保有している場合、R-STS は判断内容をクレームの形に整えます。これにより、RP では承認ロジックを実行する必要がなくなり、R-STS からクレームとして受け取った指示に基づいて判断を下します。

　トークン、クレーム、IP による認証処理の外部化については前に述べましたが、一部のケースでは、R-STS によって承認判断に該当する処理を実現できます。

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

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

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