• [アーティクル]

 

Web アプリケーション用のフェデレーション ID

多くの会社がパートナーとリソースを共有することを望みます。しかし、それぞれのビジネスが独自のセキュリティ領域として存在し、そのディレクトリ サービス、セキュリティ、認証が独立しているとき、どのようにしたらリソースの共有を実現できるのでしょうか。解決策の 1 つはフェデレーション ID です。フェデレーション ID により、複数の個別のセキュリティ領域から 1 つのアプリケーションを使用するときに発生する問題のいくつかを解決できます。フェデレーション ID を使用すると、従業員は、ローカルの企業資格情報で、自社と信頼関係にある外部ネットワークにログインできます。概要については、第 2 章「クレーム ベースのアーキテクチャ」の「領域間での ID のフェデレーション」を参照してください。

注意

フェデレーション ID は、独立したセキュリティ領域どうしをリンクします。

 

この章では、Adatum が顧客の 1 つである Litware に対して、第 3 章「Web 用のクレーム ベースのシングル サインオン」で紹介した a-Order アプリケーションの使用を許可する方法について学習します。

前提条件

Adatum は既に従業員にシングル サインオン (SSO) を設定しているので、次のステップに進む準備ができています。顧客も、a-Order プログラムを使用することによって注文の進行状況を開始から終了まで追跡することを望んでいます。顧客は、プログラムが顧客自身の企業ドメイン内にあるアプリケーションのように動作することを期待します。たとえば、Litware は Adatum と長い付き合いのあるクライアントです。Litware の営業マネージャーの Rick は、Litware の資格情報でログオンし、a-Order プログラムを使用して、Adatum に出した注文のすべての状況を確認できることを望んでいます。つまり、Rick は Adatum の従業員と同じ SSO 機能を使用したいと考えています。しかし、a-Order を使用するためだけに Adatum から区別された専用の資格情報を持つことは避けたいと考えています。

注意

サードパーティ ユーザーのアカウントを保守することは、高額のコストが発生するおそれがあるため、Adatum は、Web アプリケーションを使用する他社のユーザーのアカウントを保守することは望みません。フェデレーション ID を使用すると、アカウント保守のコストを低減できます。

 

目標と要件

このシナリオの目標は、フェデレーション ID によって Adatum と Litware との間のパートナーシップを効率よく向上させられることを示すことです。フェデレーション ID を使用すると、セキュリティ ドメインは別のドメインから到着する ID を受け付けます。これによってドメインのユーザーは、追加の資格情報を提示することなく、別のドメイン内のリソースに自由にアクセスできます。Adatum 側発行者は、Litware を信頼して、その従業員に関するクレームを正式に発行します。

目標とは別に、このシナリオにはいくつかの要件があります。その 1 つは、注文ステータス ページおよび表示される情報に対してアクセス要求があったとき、Adatum は、プログラムへのアクセスを要求するパートナーに基づいてアクセスを制御する必要があるということです。つまり、Litware は自社の注文を参照できるだけで、他社の注文は参照できないようにする必要があります。また、Litware では、Rick などの Sales (営業) 部門の従業員が注文を追跡できるようにします。

もう 1 つは、Litware はプログラムにアクセスする Adatum の数多くのパートナーの 1 つに過ぎないため、Adatum は、ユーザーの資格情報に対応する発行者を特定できる必要があります。これは、"ホーム領域検出" と呼ばれます。詳細については、第 2 章「クレーム ベースのアーキテクチャ」を参照してください。

この章の 1 つの前提は、Adatum 側発行者と同様に Litware も、WS-Federation を使用する発行者を既に展開していることです。

注意

Ff359110.cdb150a3-baac-4cf3-97d3-73c54b3a02a6(en-us,PandP.10).pngこのようなシナリオで考慮する可能性があるもう 1 つのプロトコルには、SAML (Security Assertion Markup Language) があります。ADFS 2.0 は SAML をサポートします。

 

WS-Federation は、認証と承認のために固有のシステムを持つ企業どうしがセキュリティ境界で ID を共有する方法を定義した仕様です。(WS-Federation の詳細については、第 2 章「クレーム ベースのアーキテクチャ」を参照。) これが可能になるのは、Litware と Adatum との間で双方を保護する契約が既に結ばれている場合だけです。2 番目の前提は、どの従業員が a-Order アプリケーションにアクセスできるかを Litware が決定できるということです。

ソリューションの概要

Rick が Litware ネットワークにログインしたとき、ソリューションが準備されていれば、Rick は Litware アプリケーションにアクセスするのと同じようにして a-Order にアクセスします。Rick の立場から見るとそれだけです。彼が特別なパスワードやユーザー名を持つ必要ありません。普段どおりに業務を行うことができます。図 1 に、Rick のエクスペリエンスを快適にするアーキテクチャを示します。

注意

アプリケーションを変更して、パートナー組織からクレームを受け付けることができます。

 

図 1

Adatum と Litware との間のフェデレーション ID

これを見るとわかるように、Adatum が SSO を設定してからこれまで、インフラストラクチャに 2 つの変更が行われています。Adatum と Litware のセキュリティ ドメイン間に信頼関係が成立し、Adatum 側発行者の構成にフェデレーション プロバイダー (FP) としての機能が加わりました。フェデレーション プロバイダーは、ID を検証するのではなく、a-Order アプリケーションなどのリソースへのアクセス権を付与します。クライアント要求を処理するとき、a-Order アプリケーションは Adatum 側発行者に依存します。一方、Adatum 側発行者は、このシナリオでは ID プロバイダー (IP) として機能する Litware 側発行者に依存します。図では実装の選択を 1 つしか表していませんが、Adatum の IP と FP を分離することも可能です。各ステップでは、クライアント ブラウザーによる HTTP リダイレクトも使用しますが、簡略化して図には示していません。

以下の手順では、別のセキュリティ ドメインのユーザーにアクセス権を付与します。

  1. Rick は Litware のネットワークでコンピューターを使用中です。彼は既に Active Directory で認証されています。Rick はブラウザーを開き、a-Order アプリケーションに移動します。このアプリケーションは、Adatum 側発行者 (FP) を信頼するように構成されています。アプリケーションには、要求元を特定する情報はありません。アプリケーションは、Rick の要求を FP にリダイレクトします。
  2. FP は、信頼する ID プロバイダーの一覧を含むページをユーザーに表示します。この時点で、FP には Rick の所属はわかりません。

注意

Ff359110.d5a6277d-d383-4e05-b1ea-e53dc4c27b93(en-us,PandP.10).pngサンプル コードではホーム領域検出を明示的に行っていますが、この方法は注意が必要です。たとえば、この方法では Adatum のパートナーのすべてが公開されますが、公開されることを望まない企業が出てくる可能性があります。

 

  1. Rick が一覧から Litware を選択すると、Adatum の FP は、Rick の身元を確認するために、Rick を Litware 側発行者にリダイレクトします。
  2. Litware の IP は、Rick の資格情報を確認し、セキュリティ トークンを Rick のブラウザーに返します。ブラウザーは、トークンを FP に送信します。このトークンに含まれるクレームは、Adatum FP 向けに構成され、Adatum が必要とする Rick の情報を保持します。たとえば、クレームは Rick の名前、および Rick が営業組織に属していることを明示します。ユーザーの資格情報を確認するプロセスには、追加のステップとして、ログオン ページの表示、Active Directory のクエリが考えられるほか、他の属性リポジトリに対するクエリも発生する可能性があります。

注意

Ff359110.8a797b0e-f36f-4044-876d-6579827a76b3(en-us,PandP.10).pngAdatum の FP は、Litware の IP に対する "証明書利用者" です。

 

  1. Adatum FP は、Litware が発行するセキュリティ トークンを検証して読み取り、a-Order アプリケーションが使用できる新しいトークンを作成します。Litware が発行するクレームは、Adatum の a-Order アプリケーションが理解できるクレームに変換されます。(Litware のクレームを Adatum のクレームに変換するマッピング ルールは、Litware 側発行者を ID プロバイダーとして受け入れるように Adatum が発行者を構成したときに決定されています。)
  2. クレーム マッピングの結果、Adatum 側発行者は一部のクレームを削除し、a-Order アプリケーションが Rick をユーザーとして受け入れるために必要なそれ以外のクレームを追加します。Adatum 側発行者はブラウザー リダイレクトを使用して、アプリケーションに新しいトークンを送信します。WIF はセキュリティ トークンを検証し、クレームを抽出します。また、ClaimsPrincipal を作成し、HttpContext.User に割り当てます。その後、a-Order アプリケーションは、承認の決定を行うためにクレームにアクセスできます。たとえば、このシナリオでは、注文は、クレームとして提供される組織によってフィルター処理されます。

注意

Ff359110.910ac075-fe98-40b9-b640-a8ab9a56e0d7(en-us,PandP.10).pngこれらの手順の詳細については、「付録 B」を参照してください。ブラウザーをクライアントとして使用するための、詳細なメッセージのシーケンス図が示されています。

 

FP として機能する Adatum 側発行者は、アプリケーションと外部発行者との間を仲介します。これは、Adatum 側発行者が引き受ける論理的なロールと見なすことができます。FP には 2 つの責任があります。1 つは、Litware 側発行者との信頼関係を維持することです。これは、FP が Litware のトークンおよびクレームを受け入れて理解することを示します。

注意

個別の信頼ドメインの発行者間に信頼関係を確立する方法については、この章の「セットアップと物理展開」を参照してください。

 

もう 1 つは、Litware クレームを a-Order が理解できるクレームに変換する必要があるということです。a-Order アプリケーションは、Adatum の FP (これは信頼できる発行者です) からのみクレームを受け入れます。このシナリオでの a-Order は、Web サイトに対する操作を承認するために、タイプが Role のクレームを想定します。問題は、Litware クレームが、Adatum からのものでなく、ロールを持っていないことです。シナリオでは、Litware クレームは、従業員の名前および組織グループを明示します。たとえば、Rick の所属組織が Sales (営業) であるといったようにです。この問題を解決するために、FP は、Litware クレームを Adatum クレームに変換するマッピング ルールを使用します。

次の表に、Adatum FP がどのように Litware からの入力クレームを Adatum 出力クレームに変換するかをまとめます。

入力条件 出力クレーム

クレーム発行者: Litware

クレーム タイプ: Group、クレーム値: Sales

クレーム発行者: Adatum

クレーム タイプ: Role、クレーム値: Order Tracker
クレーム発行者: Litware

クレーム発行者: Adatum

クレーム タイプ: 会社、クレーム値: Litware

クレーム発行者: Litware

クレーム タイプ: name

クレーム発行者: Adatum

クレームのコピー

 

ADFS 2.0 には、発行者が新しいトークンを作成するときの動作を定義できるクレーム ルール言語が含まれています。これらのルールは、一般に、一定の条件の組み合わせが true であれば、何らかのクレームが発行されるということを示します。

以下に示すのは、Adatum FP が使用する 3 つのルールです。

  • => issue(Type = "http://schemas.adatum.com/claims/2009/08/organization", Value = "Litware");
  • c:[Type == "https://schemas.xmlsoap.org/claims/Group", Value == "Sales"] => issue(Type = "https://schemas.microsoft.com/ws/2008/06/identity/claims/role", Issuer = c.Issuer, OriginalIssuer = c.OriginalIssuer, Value = "Order Tracker", ValueType = c.ValueType);
  • c:[Type == "https://schemas.xmlsoap.org/ws/2005/05/identity/claims/name"]=> issue(claim = c);

すべてのルールで、"=>" の前の部分は、ルールが適用されるためには true になることが要求される条件です。"=>" の後の部分は、実行されるアクションを示し、通常は追加クレームの作成です。

最初のルールは、値 Litware を含むタイプ Organization のクレームを FP が作成することを示します。つまり、この発行者 (Litware) のために、FP はルールに指定されたクレームを作成します。2 つ目のルールは、値 Sales を含むタイプ Group のクレームが存在する場合、値 OrderTracker を含むタイプ Role のクレームを FP が作成することを示します。3 つ目のルールは、タイプ name のクレームをコピーします。

ソリューションの重要な部分の 1 つは、ホーム領域の検出です。a-Order アプリケーションは、認証のためにユーザーをどの発行者に送信するかを知る必要があります。Rick がブラウザーを開き、http://www.adatumpharma.com/ordertracking と入力したとき、a-Order は、Litware 側発行者が Rick を認証できることをどのようにして知るのでしょうか。実際は、a-Order はそのことを知りません。a-Order アプリケーションは、その決定を FP に依存します。a-Order アプリケーションは、常にユーザーを FP にリダイレクトするだけです。

注意

Ff359110.f88077a5-3aa6-44ca-b2bd-fd0a00769b07(en-us,PandP.10).pnga-Order アプリケーションは、パートナー固有の詳細情報を持っていません。パートナーの詳細情報は FP に保持されています。

 

このアプローチには潜在的に 2 つの問題があります。1 つは、Litware と Adatum との関係について情報を公開します。また、ユーザーにとっては手順が 1 つ増え、どちらの選択が適切であるか迷う可能性もあります。

注意

Ff359110.d5a04df5-5506-4001-ace1-289ef5acdf02(en-us,PandP.10).pngまた、フィッシング攻撃の危険も増します。

 

これらの問題を解決するには、ユーザーのホーム領域に関するヒントをアプリケーションに提供します。たとえば、Litware はパラメーターを送信する際、送信者のセキュリティ ドメインを示すクエリ文字列内にパラメーターを含めることができます。アプリケーションは、このヒントを使用して FP の動作を特定できます。詳細については、第 2 章「クレーム ベースのアーキテクチャ」の「ホーム領域検出」を参照してください。

注意

Ff359110.40b77564-5898-4e31-bc33-da1f98564650(en-us,PandP.10).png発行者は、ある人物のホーム領域を指定するための手段として whr パラメーターを受け入れることができます。

 

メリットと制限

フェデレーション ID は、柔軟なインフラストラクチャをクレームがどのようにサポートするかを示す 1 つの例です。FP で信頼関係を設定し、正しいクレーム マッピングを作成することで、Adatum は顧客を簡単に追加することができます。WIF のために a-Order でのクレーム処理は簡略化されます。また、Adatum が ADFS 2.0 を使用しているために、クレーム マッピング ルールの作成もかなり単純です。a-Order アプリケーション自体は変更されませんでした。また、フェデレーションを作成するにあたって、SSO の実装で最初に設置したインフラストラクチャを少しずつ強化することが必要になりました。

別のメリットとして、Litware が発行するクレームは、組織のコンテキストで意味を持つ内容 (Litware の従業員とそれらのグループ) に関するものであるということが挙げられます。Litware と Adatum の ID の相違は、すべて受信側である Adatum の FP によって修正されます。Litware は、Adatum 固有のクレームを発行する必要がありません。これは技術的に可能ですが、会社は新しい関係とアプリケーションを追加していくので、管理がすぐに困難になったりコストが高くなる可能性があります。

注意

フェデレーション ID では、保守やトラブルシューティングの必要性が軽減します。ユーザー アカウントをセキュリティ領域間でコピーしたり保守したりする必要がありません。

 

実装の内部

https://claimsid.codeplex.com にある 2-Federation という名前の Visual Studio ソリューションは、フェデレーションの使用方法を示す一例です。アプリケーションの構造は、第 3 章「Web 用のクレーム ベースのシングル サインオン」で確認したものとよく似ています。フェデレーション ID を追加することで、再コンパイルや Web.config ファイルの変更を行う必要はありませんでした。代わりに、発行者がフェデレーション プロバイダーとして機能するように構成され、ID プロバイダーとして機能する発行者との間に信頼関係が確立されました。このプロセスは、次のセクションで説明します。また、フェデレーション プロバイダー ロールを処理するために、モック発行者が拡張されました。

注意

フェデレーション ID をクレーム対応の既存のアプリケーションに追加する場合は、構成を変更するだけで実行できます。

 

セットアップと物理展開

CodePlex にある 2-Federation という名前の Visual Studio ソリューションは、初期状態ではスタンドアロンの開発マシン上で実行するように構成されています。このソリューションには、Litware と Adatum の両方のモック発行者を実装するプロジェクトが含まれています。

開発とテストへのモック発行者の利用

モック発行者は、エンドツーエンドのアプリケーションを単一ホストで実行するのに使用できるため、開発、デモ、およびテストに役立ちます。WIF SDK には、SecurityTokenService 基本クラスから派生する単純な発行者クラスを簡単に作成できる Visual Studio テンプレートが含まれています。そこで、このシナリオに付随するダウンロード可能なコード サンプルに示すように、GetScope メソッドと GetOutputClaims メソッドに定義を指定します。

Adatum 側の開発者は、アプリケーションを展開する際、Adatum と Litware が提供するサーバーを使用するように構成を変更します。そのためには、Litware 側発行者と Adatum 側発行者の間に信頼関係を確立し、Adatum 側発行者の a-Order.OrderTracking アプリケーションの Web.config ファイルを変更する必要があります。

信頼関係の確立

運用環境では、Adatum と Litware は、ADFS 2.0 などの運用クラスのセキュリティ トークン発行者を使用します。シナリオが機能するためには、Adatum 側発行者と Litware 側発行者との間に信頼関係を確立する必要があります。一般に、このプロセスには 7 つのステップがあります。

注意

Ff359110.88ab8023-0492-4881-a078-a71c4e2f82ff(en-us,PandP.10).png信頼を確立するための手順は、メタデータを使用して自動化できます。たとえば、ADFS 2.0 では、FederationMetadata.xml ファイルを使用することによってより多くを自動化することができます。サンプル コードで提供されるモック発行者は、このメタデータを提供しません。

 

  1. トークン署名の公開キー証明書を Litware 側発行者からエクスポートし、Litware のトークン署名証明書を Adatum 側発行者ホストのファイル システムにコピーします。
  2. Litware を信頼された ID プロバイダーとして認識するように、Adatum 側発行者を構成します。
  3. Adatum 側発行者からの要求を受け入れるように Litware 側発行者を構成します。
  4. a-Order 追跡アプリケーションを Adatum 側発行者内の証明書利用者として、構成します。
  5. Litware 内の、Adatum 側発行者に固有のクレーム ルールを編集します。
  6. Litware 側発行者に固有のクレーム変換ルールを Adatum 側発行者で編集します。
  7. a-Order 追跡アプリケーションに固有のクレーム ルールを Adatum 側発行者で編集します。

これらの各ステップの実行方法の手順については、製品発行元が提供しているドキュメントを参照してください。このガイドに含まれるサンプルの手順は、https://claimsid.codeplex.com/にあります。

関連情報

フェデレーションとホーム領域検出の詳細については、https://msdn.microsoft.com/en-us/magazine/cc163520.aspx の「Active Directory フェデレーション サービスの開発者のための手引き」を参照してください。併せて、https://blogs.msdn.com/vbertocci/archive/2009/04/08/one-does-not-simply-walk-into-mordor-or-home-realm-discovery-for-the-internet.aspx の「モルドールへの険しい道、またはインターネットにおけるホーム領域の検出」も参照してください。

WS-Federation メタデータ ドキュメントの生成に役立つツールについては、http://blogs.thinktecture.com/cweyer/archive/2009/05/22/415362.aspx の「Christian Weyer のブログ」を参照してください。

ADFS 2.0 クレーム ルール言語の詳細については、https://technet.microsoft.com/en-us/library/dd807118%28WS.10%29.aspx の「クレーム ルール言語」を参照してください。

前の章 | 次の章

ページのトップへ