フェデレーションのシナリオ

  • [アーティクル]

ここでは、パートナー企業の従業員が相手企業のドメインのリソースにアクセスするシングル サインオンのシナリオについて説明します。 フェデレーションのシナリオは、主に ID プロバイダー、要求プロバイダー、証明書利用者の 3 者で構成されます。Windows® Identity Foundation (WIF) には、この 3 つすべての要素を構築するための API が用意されています。

次の図は、Fabrikam の従業員がログインし直さずに (つまり、シングル サインオンで) Contoso.com のリソースにアクセスする場合の一般的なフェデレーションのシナリオを示したものです。

89a58a75-d05f-4424-ab28-c7ca1fd20ede

このシナリオに参加する架空のユーザーを次に示します。

  • Frank: Contoso のリソースにアクセスする必要がある Fabrikam の従業員。

  • Daniel: アプリケーションに必要な変更を実装する Contoso のアプリケーション開発者。

  • Adam: Contoso の IT 管理者。

このシナリオで使用するコンポーネントを次に示します。

  • web1: 部品注文の Web アプリケーション。ASP.NET で構築され、関連する部品へのアクセスを制御します。

  • sts1: Contoso.com 内で要求プロバイダーの役割を持ち、アプリケーション (web1) が想定しているような要求を発行する STS。 Fabrikam.com との信頼を確立しており、Fabrikam 従業員へのアクセスを許可するように構成されています。

  • sts2: Fabrikam.com 内で ID プロバイダーの役割を持ち、Fabrikam 従業員の認証のエンド ポイントを提供する STS。 Contoso.com と信頼を確立しています。そのため、Fabrikam の従業員は、Contoso.com のリソースにアクセスできます。

前の図に示すように、このシナリオの流れは次のとおりです。

  1. Contoso の管理者 Adam が、アプリケーション (RP) と sts1 間の信頼を構成します。

  2. Contoso の管理者 Adam が、sts2 を ID プロバイダーとする信頼を構成します。

  3. Fabrikam の管理者 Frank が、sts1 を要求プロバイダーとする信頼を構成し、アプリケーションにアクセスします。

このシナリオに必要な基本的な手順

このサンプル シナリオは、説明することのみを目的としています。 このシナリオを運用環境で実現するために必要な実際の手順とは異なる場合があります。

要求プロバイダーの設定

Contoso.com の管理者である Adam には 3 つの選択肢があります。

  1. Active Directory® フェデレーション サービス (AD FS) 2.0 などの STS 製品をインストールする。

  2. LiveID STS などのクラウド STS 製品を利用する。

  3. WIF を使用して、カスタム STS を構築する。

どれを選ぶかは、ビジネス ニーズ、スケジュール、技術リソースの確保、予算など、さまざまな要因に依存します。 このサンプル シナリオでは、Adam は 1 番目の選択肢を選び、AD FS 2.0 の製品ドキュメントに従って、RP-STS として AD FS 2.0 をインストールしたものとします。

アプリケーションを要求に対応させる

web1 を要求に対応したアプリケーションとするために、Daniel は WIF をインストールし、次のコードを追加して、要求を列挙します。 詳細については、「FedUtil: RP から STS への信頼を確立するためのフェデレーション ユーティリティ」、「Visual Studio テンプレート」、および「証明書利用者アプリケーションの構築」を参照してください。

// Get the access to IClaimsIdentity IClaimsIdentity claimsIdentity = ((IClaimsPrincipal)Thread.CurrentPrincipal).Identities[0];

foreach ( Claim claim in claimsIdentity.Claims ) { // Before using the claims validate that this is an expected claim. // If it is not in the expected claims list then ignore the claim. if ( ExpectedClaims.Contains( claim.ClaimType ) ) { // Write out the claim or use the claim as needed by application logic WriteClaim( claim, table ); } }

証明書利用者アプリケーションから STS への信頼の確立

RP アプリケーションから STS への信頼は、Daniel が FedUtil: RP から STS への信頼を確立するためのフェデレーション ユーティリティ ツールを使用して確立します。 このツールは、さらに、RP アプリケーションのメタデータを生成し、その xml ファイル (metadata.xml) を RP アプリケーションのフォルダーに格納します。 RP アプリケーションの web.config ファイルは、STS (sts1) に関する情報で自動的に更新されます。

要求プロバイダーにおける証明書利用者アプリケーションの構成

RP アプリケーションとの信頼は、Adam が AD FS 2.0 の製品ドキュメントを参照して確立します。

Fabrikam における ID プロバイダー (IP) の構成

Fabrikam.com の管理者である Frank には 3 つの選択肢があります。

  1. AD FS 2.0 などの STS 製品を購入し、インストールする。

  2. LiveID STS などのクラウド STS 製品を利用する。

  3. WIF を使用して、カスタム STS を構築する。

このサンプル シナリオでは、Frank は 1 番目の選択肢を選び、IP-STS として AD FS 2.0 をインストールしたものとします。 また、Frank は、AD FS 2.0 の製品ドキュメントを参照して、要求プロバイダーとして Contoso.com との信頼を確立します。

Web アプリケーションへのアクセス

Frank は Fabrikam ドメインのユーザーとして Fabrikam にログインします。 ログイン後、ブラウザーを起動して、Contoso.com の RP アプリケーション ページにアクセスします。 既に Fabrikam と Contoso 間にはフェデレーションの信頼が確立されているため、Frank は認証し直すことなく、Contoso のリソースにアクセスすることができます。

サンプル リソース

エンド ツー エンドのシナリオの完全なサンプルについては、次のサンプルを参照してください。

  • End-to-end\Federation for web services (アクティブ ケース)

  • End-to-end\Federation for web app (パッシブ ケース)

これらのサンプルは、複数のカスタム STS および 1 つの RP を使用する単一のシステムで動作するようになっています。