次の方法で共有

複数のパートナーとのフェデレーション ID

  • [アーティクル]

この章では、多くの信頼関係を確立するアプリケーションに適用される特別な考慮事項について学習します。フェデレーション ID の基本構成要素 (発行者、信頼、セキュリティ トークン、クレーム) は前の章と同じですが、複数の信頼関係がある場合は、ID と承認に関していくつかの要件があります。この章では、ASP.NET MVC フレームワークを使用した、クレーム対応のアプリケーションの構築方法についても示します。

注意

多くの信頼関係が存在する場合には、特別な考慮事項が適用されます。

 

この章で説明するような Web アプリケーションでは、ユーザーと顧客に関して明確な概念が規定されています。アプリケーションの顧客は、組織である場合があります。また、各顧客が多くの個人ユーザー (従業員など) を持つ場合もあります。アプリケーションを使用する顧客が多くなると、新しい顧客の登録プロセスをできるだけ合理化する必要があります。このプロセスは、自動化することもできます。他の章と同様に、これらの概念はシナリオに基づいて説明すると一番わかりやすいでしょう。

前提条件

Fabrikam は、出荷サービスを提供する企業です。同社では、出荷指示の作成や追跡などの作業を顧客が実行できる Fabrikam Shipping という名前の Web アプリケーションを、サービスの一環として提供しています。Fabrikam Shipping は、Fabrikam のデータ センターで実行される ASP.NET MVC アプリケーションです。Fabrikam の顧客は、従業員がブラウザーを使用してこの出荷アプリケーションにアクセスできるようにしたいと考えています。

Fabrikam は、この新しい出荷アプリケーションをクレーム ベースにしました。設計上の多くの選択と同様に、この選択も顧客主導でした。今回、Fabrikam は大口顧客の Adatum と契約を結びました。Adatum の企業 IT 戦略 (「第 3 章「Web 用のクレーム ベースのシングル サインオン」」を参照) によると、ID サイロの撤廃が最終的には必要です。Adatum は、ユーザーが個々のユーザー名とパスワードを提供しなくても Fabrikam Shipping にアクセスできるようにしようとしています。Fabrikam は、類似の要件を持つ Litware とも契約を結びました。ただし、Fabrikam は、フェデレーション ID をサポートするインフラストラクチャを備えていない Contoso などの小口顧客もサポートしようとしています。

目標と要件

Adatum や Litware などの大口顧客は、次のような要件を求めています。

  • ユーザビリティ。Fabrikam Shipping 用の新しいパスワードとユーザー名を従業員が覚えなくても済むような状況を望んでいます。従業員に必要な資格情報は既存のものだけで済み、また、セキュリティ ドメイン内から Fabrikam Shipping にアクセスする際に、再び資格情報を入力しなくても済むような状況です。
  • サポート。Adatum と Litware にとって、従業員がたとえばパスワードを忘れた場合、Fabrikam に問い合わせてもらうよりも自社で管理する方が簡単です。
  • 信頼性。Adatum と Litware が認証および承認ポリシーを適用するのには理由があります。それは、リソースの展開先にかかわらず、アクセスするユーザーを制御する必要があるためです。Fabrikam Shipping にも同じことが言えます。従業員が退職した場合は、彼らがアプリケーションにアクセスできないようにする必要があります。

Fabrikam の目標は次のとおりです。

  • ユーザー ID の管理を顧客に委任する (可能な場合)。これにより、Fabrikam と顧客の間のデータの同期など、いくつかの問題を回避できます。荷物の送信者の連絡先は、このような情報の例です。これらの情報を最新に保とうとすると、Fabrikam ではすぐに作業負荷が大きくなるため、その正確さに関しては顧客が責任を持ちます。
  • コスト センターが存在する場合は、コスト センターが顧客に請求する。コスト センターは、顧客が指定します。これも、顧客が責任を持つべき情報のもう 1 つの例です。
  • 多くの顧客にサービスを販売する。新しい企業の登録プロセスを合理化する必要があります。Fabrikam は、顧客がアプリケーションをできるだけ自己管理するよう望んでいます。
  • 顧客がフェデレーションのインフラストラクチャを備えていない場合、それを提供する。顧客のために複数の認証メカニズムをサポートする場合は、それによるアプリケーション コードへの影響を最小限に抑える必要があります。

ソリューションの概要

目標と要件を確認したので、次にソリューションを確認していきます。第 4 章「Web アプリケーション用のフェデレーション ID」で説明したように、顧客側で ID プロバイダー (IP) として機能する発行者を含む、クレーム ベースのアーキテクチャを、このソリューションでは確立します。また、このソリューションには、Fabrikam 側でフェデレーション プロバイダー (FP) として機能する発行者も含まれます。既に説明したように、FP は、リソースと、リソースのユーザーに関するクレームを提供するすべての発行者との間のゲートウェイとして機能します。

図 1 は、独自の IP を持つ顧客用の Fabrikam のソリューションを示します。

 

表題の挿入

Ff359105.2d22c388-6e7e-4c0d-971d-2cb7472f994e(en-us,PandP.10).png

図 1

IP を持つ顧客用の Fabrikam Shipping

次の例に、このシステムがどのように機能するかを示します。このステップは、上の図の数値と対応しています。

ステップ 1: IP に資格情報を提示する

  1. Adatum の John が初めて Fabrikam Shipping を使用するとき (初めて https://{fabrikam host}/f-shipping/adatum にアクセスするとき) には、セッションは確立されていません。つまり、Fabrikam 側から見ると、John は認証されていない状態です。URL は、アクセスを要求している顧客に関するヒント (URL の最後の "adatum") を Fabrikam Shipping アプリケーションに提供します。
  2. アプリケーションは、John のブラウザーを Fabrikam 側発行者 (FP) にリダイレクトします。これは、Fabrikam の FP がこのアプリケーションの信頼できる発行者だからです。リダイレクト URL の一部として、アプリケーションは、顧客のホーム領域に関するヒントを提供する whr パラメーターを FP に含めます。whr パラメーターの値は、http://AdatumADFS/Trust です。
  3. Fabrikam の FP は、whr パラメーターを使用して顧客の IP を確認し、John のブラウザーを Adatum 側発行者にリダイレクトし直します。

注意

Ff359105.8e1af5d2-67cd-4765-b4e1-a783a4383733(en-us,PandP.10).pngこのシナリオでは、ホーム領域の検出が自動化されています。第 4 章「Web アプリケーション用のフェデレーション ID」で説明したように、ユーザーがホーム領域を提供する必要はありません。

 

  1. John の使用しているコンピューターがドメインに属しており、企業ネットワーク内に存在しているならば、John は Adatum の IP に提示できる有効なネットワーク資格情報を既に所有しています。
  2. Adatum の IP は、John の資格情報を使用して認証を行い、Adatum のクレームのセットを含むセキュリティ トークンを発行します。これらのクレームには、従業員名、従業員のアドレス、コスト センター、および部門があります。

ステップ 2: IP のセキュリティ トークンを FP に送信する

  1. IP は、HTTP リダイレクトを使用して、発行したセキュリティ トークンを Fabrikam の FP にリダイレクトします。
  2. Fabrikam の FP は、このトークンを受け取って検証します。

ステップ 3: クレームをマップする

  1. Fabrikam の FP は、トークンのマッピング ルールを IP のセキュリティ トークンに適用します。クレームは、Fabrikam Shipping が認識できる形式に変換されます。
  2. FP は、HTTP リダイレクトを使用して、これらのクレームを John のブラウザーに送信します。

ステップ 4: マップされたクレームを送信し、要求されたアクションを実行する

  1. ブラウザーは、変換されたクレームを含む FP のセキュリティ トークンを Fabrikam Shipping アプリケーションに送信します。
  2. アプリケーションは、このセキュリティ トークンを検証します。
  3. アプリケーションは、これらのクレームを読み込み、John 用のセッションを作成します。

これは Web アプリケーションなので、すべての操作はブラウザーを介して行われます。(ブラウザー ベースのクライアントのプロトコルの詳細については、「付録 B」を参照してください。)

これらの操作の背後にある原理は、第 4 章「Web アプリケーション用のフェデレーション ID」で説明されている原理とまったく同じです。ただし、例外として、Fabrikam ではホーム領域の検出プロセスが自動化されます。この場合、ユーザーによる操作は必要ありません。ホーム領域は、最初に URL、次に whr パラメーターで渡された情報だけに基づいて生成されます。

注意

ホーム領域の自動検出は、多くの信頼関係が存在する場合に重要です。

 

Litware に関する手順も Adatum と同じです。ただし、使用される URL (http://{fabrikam host}/f-shipping/litware および Litware IP のアドレス) とクレームのマッピング ルールは異なります。これは、Litware によって発行されるクレームは、Adatum によって発行されるクレームとは異なるからです。Fabrikam Shipping は、Litware または Adatum の個々の発行者ではなく、Fabrikam FP を信頼していることに注意してください。このように間接的なレベルが存在するため、Fabrikam Shipping は Litware および Adatum の個々の違いから隔離されます。

また、Fabrikam は、独自の発行者を持たない Contoso などの顧客に代わって ID サービスを提供します。図 2 は、Fabrikam がこのサービスをどのように実装するかを示しています。

Ff359105.0c2f7561-d335-4981-83a0-7bac0834977c(en-us,PandP.10).png

図 2

IP を持たない顧客用の Fabrikam Shipping

Contoso は、独自の ID インフラストラクチャを持たない小規模な組織です。Contoso には、そのユーザーの認証を Fabrikam が信頼して任せられる発行者は存在しません。Contoso は、アプリケーションへのアクセスに従業員が独自の資格情報セットを必要としているかどうかも問題にしていません。

注意

小規模な組織は、独自の発行者を持たない場合があります。

 

Fabrikam は、Contoso のような小規模な顧客をサポートするために、独自の IP を展開しています。ただし、この発行者は Fabrikam が所有していますが、Adatum および Litware に属する IP と同様に、外部 IP のように処理されます。Fabrikam は "自分自身をフェデレートしている" とも言えます。

この IP は外部発行者として処理されるため、このプロセスは、Adatum および Litware によって使用されるプロセスと同じです。異なる点は URL とクレームのマッピングだけです。

注意

Contoso のような顧客向けに IP を展開することで、Fabrikam は、リモート ユーザーのアカウント管理 (たとえば、パスワードのリセット処理) にかかるコストを負担することになります。ただし、Fabrikam がこの作業を行う必要があるのは、独自のフェデレーション インフラストラクチャを備えていない顧客だけです。Fabrikam は、このサポートを必要とする顧客が徐々に減っていくと予想しています。
また、外部ユーザーのパスワード管理の作業を軽減する方法として、Fabrikam が LiveID や OpenID などのサードパーティの ID プロバイダーをサポートすることも考えられます。

 

Fabrikam Shipping でのクレームの使用

Fabrikam Shipping は、2 つの目的でクレームを使用します。アクセスを制御するためにロール クレームを使用し、ユーザー プロファイル情報を取得するためにもクレームを使用します。

注意

Fabrikam は、アクセス コントロールとユーザー プロファイルでクレームを使用します。

 

Fabrikam Shipping へのアクセス コントロールは、次の 3 つのロールのいずれかに基づきます。

  • Shipment Creator。このロールのユーザーは、新しい指示を作成できます。
  • Shipment Manager。このロールのユーザーは、出荷指示を作成したり、既存の出荷指示を変更できます。
  • Administrator。このロールのユーザーは、システムを構成できます。たとえば、出荷の優先順位を設定したり、アプリケーションの外観および動作 (ルック アンド フィール) を変更することができます。

Fabrikam Shipping がクレームとして要求するプロファイル情報は、送信者のアドレスと、請求のために必要な送信者のコスト センターです。コスト センターを使用することで、Fabrikam は詳細な請求書を提供できます。たとえば、異なる部署に属する Adatum の 2 人の従業員が異なる請求書を受け取ることができます。

Fabrikam は、Fabrikam Shipping を使用する新しい顧客ごとに、クレームのマッピングを構成します。これは、Fabrikam Shipping 内のアプリケーション ロジックがロール クレームの 1 つのセット (Shipment Creator、Shipment Manager、および Administrator を含む) しか認識できないために必要とされます。Fabrikam は、これらのマッピングを提供することで、顧客が提供するクレーム タイプの種類の多さがアプリケーションに影響することを回避します。

次の表に、顧客ごとのクレームのマッピングを示します。コスト センター、ユーザー名、および送信者のアドレスを表すクレームは単にコピーされるだけなので、表を見やすくするために除外してあります。

パートナー 入力条件 出力クレーム
Adatum

クレーム発行者: Adatum

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

クレーム発行者: Fabrikam

クレーム タイプ: Role、クレーム値: Shipment Creator

クレーム発行者: Adatum

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

クレーム発行者: Fabrikam

クレーム タイプ: Group、クレーム値: Shipment Creator

クレーム発行者: Fabrikam

クレーム タイプ: Group、クレーム値: Shipment Manager

クレーム発行者: Adatum

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

クレーム発行者: Fabrikam

クレーム タイプ: Role、クレーム値: Administrator
クレーム発行者: Adatum

クレーム発行者: Fabrikam

クレーム タイプ: Organization、クレーム値: Adatum
Litware

クレーム発行者: Litware

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

クレーム発行者: Fabrikam

クレーム タイプ: Role、クレーム値: Shipment Creator
クレーム発行者: Litware

クレーム発行者: Fabrikam

クレーム タイプ: Organization、クレーム値: Litware
Contoso

クレーム発行者: Fabrikam IP

クレーム タイプ: e-mail、クレーム値: bill@contoso.com

クレーム発行者: Fabrikam

クレーム タイプ: Role、クレーム値: Shipment Creator

クレーム発行者: Fabrikam

クレーム タイプ: Role、クレーム値: Shipment Manager

クレーム発行者: Fabrikam

クレーム タイプ: Role、クレーム値: Administrator

クレーム発行者: Fabrikam

クレーム タイプ: Organization、クレーム値: Contoso

 

注意

第 4 章「Web アプリケーション用のフェデレーション ID」にあるように、Adatum は Fabrikam 固有のクレームを発行することもできますが、Fabrikam ロールなどの Fabrikam 固有の概念によって Adatum 側発行者を妨害することになるため、これはお勧めできません。Fabrikam は、Adatum が自由にクレームを発行することを許容した上で、発行された Adatum クレームを Fabrikam クレームにマップするように FP を構成します。

 

実装の内部

Fabrikam Shipping アプリケーションは、ASP.NET MVC フレームワークと Windows Identify Foundation (WIF) を組み合わせて使用します。このアプリケーションの Web.config ファイルには、次の XML コードで示す構成情報が含まれます。Web.config ファイルの <system.webServer> セクションは、WIF が提供するモジュールおよび ASP.NET MVC HTTP ハンドラー クラスを参照します。WIF 情報は、前のシナリオで使用した情報と同じです。MVC HTTP ハンドラーは、<handlers> セクションに含まれています。

注意

Fabrikam Shipping は、クレームを使用する ASP.NET MVC アプリケーションです。

 

<system.webServer>

  ...

<modules runAllManagedModulesForAllRequests="true">

    ...

<add name="WSFederationAuthenticationModule" 

         preCondition=" integratedMode"   

         type="Microsoft.IdentityModel.Web.

                      WSFederationAuthenticationModule, ..." />

 

   <add name="SessionAuthenticationModule" 

         preCondition=" integratedMode"    

         type="Microsoft.IdentityModel.Web.

                           SessionAuthenticationModule, ..." />

  </modules>

  <handlers>

    ...

    <add name="MvcHttpHandler" 

         preCondition="integratedMode" 

         verb="*" 

         path="*.mvc" 

         type="System.Web.Mvc.MvcHttpHandler, ..."/>

    ...

  </handlers>

</system.webServer>

注意

Ff359105.5b69b8c2-78f9-4d5a-8781-7747d36d5f85(en-us,PandP.10).pngFabrikam が ASP.NET MVC を選択したのは、テストが容易であることとモジュール アーキテクチャが必要だったためです。Fabrikam は、これらの性質が、多くの顧客および複雑なフェデレーション関係を持つアプリケーションにとって重要だと考えました。

 

注意

Fabrikam Shipping は、WIF API で使用できるきめ細かいコントロールの一例です。Fabrikam Shipping では、MVC と WIF の使用方法が明らかにされていますが、これが唯一のアプローチではありません。また、現在、FedUtil.exe などの WIF が提供するツールは、MVC アプリケーションとは完全には統合されていません。現時点では、FedUtil プログラムを MVC アプリケーションに適用した後に、構成ファイルのセクションを編集できます。これは、Fabrikam の開発者が Fabrikam Shipping で行った方法です。

 

Fabrikam Shipping で ASP.NET MVC アーキテクチャを利用するためには、発行者への HTTP 要求のリダイレクトをカスタマイズする必要があります。そのためには、WIF のフェデレーション認証モジュール内から自動リダイレクトを無効にします。これを次の XML コードに示します。

<federatedAuthentication>

   <wsFederation passiveRedirectEnabled="false" 

     issuer="https://{fabrikam host}/{issuer endpoint}/" 

     realm="https://{fabrikam host}/f-Shipping/FederationResult" 

     homeRealm="http://tenant-to-be-replaced" requireHttps="true" 

   />

   <cookieHandler requireSsl="true" path="/f-Shipping" />

</federatedAuthentication>

注意

Ff359105.f49f5b94-2bbd-47f8-9a37-3407c4554e2f(en-us,PandP.10).pngpassiveRedirectEnabled を false に設定すると、WIF は発行者へのリダイレクトを行わなくなるため、これらの操作を完全に制御できるようになります。

 

passiveRedirectEnabled 属性を false に設定することで、認証されていないセッションの、発行者への組み込みのリダイレクトを実行しないように、WIF のフェデレーション認証モジュールに指示します。たとえば、Fabrikam Shipping は、WIF API を使用して、プログラム制御でこのリダイレクトを実行します。

ASP.NET MVC アプリケーションは、"ルート マッピング" と、ハンドラーを実装するコントローラーの概念を反映しています。ルート マッピングを使用すると、URL マッピング ルールを定義できます。受信された URL は、このルールにより、アプリケーションが提供するアクション メソッドに自動的にディスパッチされ、処理されます。(送信される URL も処理されます。)

次のコードは、Fabrikam Shipping が受信要求 (たとえば、"http://{fabrikam host}/f-shipping/adatum") のルーティング テーブルを確立する方法を示します。URL の最後の部分には、組織 (顧客) の名前が入ります。このコードは、Fabrikam Shipping の Global.asax ファイルに含まれます。

public class MvcApplication : System.Web.HttpApplication

{

  // ...

  public static void RegisterRoutes(RouteCollection routes)

  {     

    // ...       

    routes.MapRoute(

         "OrganizationDefault",

         "{organization}/",

         new { controller = "Shipment", action = "Index" });

  }

    // ...

}

注意

Ff359105.74abe5c8-ee9e-4f44-bb10-f7fea8a20fe0(en-us,PandP.10).pnghttps://www.asp.net には、ASP.NET MVC の概念に関する有益な情報が数多く掲載されています。

 

RegisterRoutes メソッドを使用すると、アプリケーションは、コードで URI をマップおよび処理する方法を ASP.NET MVC フレームワークに対して指示できます。これは、ルーティング ルールと呼ばれます。

MVC フレームワークは、受信要求 (たとえば、"http://{fabrikam host}/f-Shipping/adatum") を受け取った後、このルーティング ルールを評価することによって、要求を処理する適切なコントローラー オブジェクトを決定します。受信した URL は、ルート ルールごとにテストされます。要求は、最初に一致したルールを使用して処理されます。"f-Shipping/adatum" URL の場合は、アプリケーションの ShipmentController クラスのインスタンスがコントローラーとして使用され、Index メソッドがアクション メソッドになります。

[AuthenticateAndAuthorize(Roles = "Shipment Creator")]

public class ShipmentController : BaseController

{

   public ActionResult Index()

   {

      // ...

   }

}

ShipmentController クラスは、AuthenticateAndAuthorize という名前のカスタム属性で修飾されています。この属性は、Fabrikam Shipping アプリケーションによって実装されます。次は、この属性クラスの宣言です。

[AttributeUsage(AttributeTargets.Class | AttributeTargets.Method)]

public sealed class AuthenticateAndAuthorizeAttribute : 

                       FilterAttribute, IAuthorizationFilter

{

  // ...



  public void OnAuthorization(AuthorizationContext filterContext)

  {

    if (!filterContext.HttpContext.Request.IsSecureConnection) 

    { 

       throw /* ... */ 

    }



    if (!filterContext.HttpContext.User.Identity.IsAuthenticated)

    {

      AuthenticateUser(filterContext);

    }

    else

    {

      this.AuthorizeUser(filterContext);

    }



  // ...

}

AuthenticateAndAuthorizeAttribute クラスは、FilterAttribute クラスから派生し、IAuthorizationFilter インターフェイスを実装します。どちらの種類の属性も、ASP.NET MVC によって提供されます。MVC フレームワークは、コントローラー クラスに属性が適用されるとその種類を認識し、各コントローラー メソッドが呼び出される前に OnAuthorization メソッドを呼び出します。OnAuthorization メソッドは、既に認証が実行されているかどうかを検出し、実行されていない場合は AuthenticateUser ヘルパー メソッドを呼び出して、HTTP リダイレクトによってアプリケーションのフェデレーション プロバイダーにアクセスします。次のコードは、この処理方法を示します。

private static void AuthenticateUser(AuthorizationContext context)

{

  var organizationName = 

                (string)context.RouteData.Values["organization"];



  if (!string.IsNullOrEmpty(organizationName))

  {

    if (!IsValidTenant(organizationName)) { throw /* ... */ }

              

    var returnUrl = GetReturnUrl(context.RequestContext);



    var fam = 

        FederatedAuthentication.WSFederationAuthenticationModule;



    var signIn = 

        new SignInRequestMessage(new Uri(fam.Issuer), fam.Realm)

        {

          Context = returnUrl.ToString(),

          HomeRealm =RetrieveHomeRealmForTenant(organizationName)

        };



    context.Result = 

                  new RedirectResult(signIn.WriteQueryString());

  }

}

注意

Ff359105.74092883-4048-45b1-9a59-2a6379adcdc8(en-us,PandP.10).png アプリケーションを安全に保ち、SQL インジェクションなどの攻撃を回避するには、受信した URL のすべての値を検証する必要があります。

AuthenticateUser メソッドは、ルート テーブルから顧客の名前を受け取ります。(このコードは、顧客を組織として参照します。)この例では、顧客は "adatum" です。次に、このメソッドは、顧客が Fabrikam Shipping アプリケーションに登録されているかどうかを確認します。登録されていない場合は、例外を生成します。

次に、AuthenticateUserメソッドは、フェデレーション サインイン要求の作成に必要な情報を検索します。この情報には、発行者 (Fabrikam の FP) の URI、アプリケーションの領域 (発行者が最終的にセキュリティ トークンを返すアドレス)、ユーザーがアクセスしようとする URL、顧客のホーム領域の指定が含まれます。このメソッドは、この情報を使用して、WIF の SignInRequestMessageクラスのインスタンスを作成します。このクラスのインスタンスは、発行者への、現在のユーザーを認証するという新しい要求を表します。

基になる WS-Federationプロトコルでは、これらの情報は、Fabrikam の FP に送られる要求メッセージのパラメーターに対応します。次の表に、この対応関係を示します。

Parameter 名前 説明
wrealm 領域 これは、FP に対して Fabrikam Shipping アプリケーションを識別します。このパラメーターは、Web.config ファイルから取得され、トークンの送信先のアドレスになります。
wctx コンテキスト このパラメーターは、ユーザーによって要求された元の URL のアドレスに設定されます。このパラメーターは、発行者が使用することはありませんが、Fabrikam Shipping アプリケーションがユーザーを元のアドレスに送信できるように、チェーン内のすべての発行者が保持します。
whr ホーム領域 このパラメーターは、この要求の ID プロバイダーとして Adatum 側発行者を使用するように、Fabrikam の FP に指示します。

 

GetReturnUrlメソッドは、ユーザーがアクセスしようとしている URL を提供する、ローカル定義されたヘルパー メソッドです。たとえば、http://{fabrikam host}/f-shipping/adatum/shipment/newを提供します。

このメソッドは、WIF API を使用してサインオン要求メッセージを作成してから、結果をリダイレクト用に構成します。

この時点で、ASP.NET はユーザーのブラウザーを FP にリダイレクトします。それに対する応答として、FP は、第 3 章「Web 用のクレーム ベースのシングル サインオン」および第 4 章「Web アプリケーション用のフェデレーション ID」で説明されている手順を使用して、ユーザーを認証します。これには、ホーム領域として指定された ID プロバイダーへの追加の HTTP リダイレクトも含まれます。このガイドで前に示した例とは異なり、この例での FP は、顧客の IP のアドレスを推測するためにアプリケーションによって送信された whr パラメーターを使用します。FP は、IP からセキュリティ トークンを受け取り、それを Fabrikam Shipping が要求するクレーム タイプのトークンに変換した後、最初に指定された wrealm アドレスにそのトークンを POST します。これは、AuthenticateAndAuthorizeAttributeフィルターの SignInRequestMessageクラスで構成される特別な URL です。この例では、この URL は f-shipping/FederationResult です。

MVC ルーティング テーブルは、この POST メッセージを Fabrikam Shipping アプリケーションの HomeController クラスで定義されている FederationResult アクション ハンドラーにディスパッチするように構成されています。このメソッドを次のコードに示します。

[ValidateInput(false)]

public ActionResult FederationResult()

{

  var fam = 

        FederatedAuthentication.WSFederationAuthenticationModule;

  if (fam.CanReadSignInResponse(

                   System.Web.HttpContext.Current.Request, true))

  {

    string returnUrl = this.GetReturnUrlFromCtx();



    return new RedirectResult(returnUrl);

  }



  // ...

}

このコントローラーには、AuthenticateAndAuthorize 属性が適用されないことに注意してください。ただし、このアドレスに POST されたトークンは、戻り先 URL の明示的なリダイレクトがあるために、WIF フェデレーション認証モジュールによって処理されます。

FederationResult アクション ハンドラーは、ユーザーによって要求された元の URL を含む wctx パラメーターを、GetReturnUrlFromCtx ヘルパー メソッドを使用して読み込みます。これは、this.HttpContext.Request.Form["wctx"] という単なるプロパティ参照操作です。最後に、この URL へのリダイレクト要求を発行します。

POST の本体には、XML としてシリアル化されたセキュリティ トークンが含まれるため、このシナリオでは ValidateInput カスタム属性が必要です。このカスタム属性を提供しないと、ASP.NET MVC は、本体のコンテンツを安全でないものと見なし、例外を生成します。

次に、アプリケーションは要求を再処理しますが、このパスには認証されたユーザーが含まれます。前述した OnAuthorization メソッドが再度呼び出されます。ただし、今回は、最初のパスでの AuthenticateUser メソッドではなく、AuthorizeUser ヘルパー メソッドに制御を渡します。AuthorizeUser メソッドの定義を次のコードに示します。

private void AuthorizeUser(AuthorizationContext context)

{

  var organizationRequested = 

     (string)context.RouteData.Values["organization"];

  var userOrganiation = 

     ClaimHelper.GetCurrentUserClaim(

          Fabrikam.ClaimTypes.Organization).Value;

            

  if (!organizationRequested.Equals(userOrganiation,  

                     StringComparison.OrdinalIgnoreCase))

  {

    context.Result = new HttpUnauthorizedResult();

    return;

  }



  var authorizedRoles = this.Roles.Split(new[] { "," }, 

                          StringSplitOptions.RemoveEmptyEntries);

  bool hasValidRole = false;

  foreach (var role in authorizedRoles)

  {

    if (context.HttpContext.User.IsInRole(role.Trim()))

    {

      hasValidRole = true;

      break;

    }

  }



  if (!hasValidRole)

  {

    context.Result = new HttpUnauthorizedResult();

    return;

  }

}

AuthorizeUser メソッドは、現在のユーザーのクレームをチェックします。セキュリティ トークンの顧客 ID と、URL で指定されている要求された顧客とが一致するかどうかが確認されます。次に、現在のユーザーがこのアプリケーションの実行に必要なロールの 1 つを持っているかどうかがチェックされます。

注意

これは、クレーム対応のアプリケーションなので、スタティック型が IPrincipal であっても、ユーザー オブジェクトは IClaimsPrincipal 型になります。ただし、この場合、実行時型変換は必要ありません。これは、コードがロール クレームだけをチェックし、前述の操作は IPrincipal インターフェイスを実装するインスタンスでも使用できるからです。
プリンシパルからその他のクレームを抽出する場合は、最初に User プロパティを IClaimsPrincipal にキャストする必要があります。これを次のコードに示します。
var claimsprincipal =
context.HttpContext.User as IClaimsPrincipal;

 

許可されたロール (AuthenticateAndAuthorizeAttribute クラスで定義されたロール) の 1 つに対応するクレームをユーザーが持っている場合、AuthorizeUser メソッドは、結果をコンテキストに設定することなく返されます。これにより、元のアクション要求メソッドを実行できます。

このシナリオでは、元のアクション メソッドは、ShipmentController クラスの Index メソッドです。次のコード例は、このメソッドの定義を示します。

[AuthenticateAndAuthorize(Roles = "Shipment Creator")]

public class ShipmentController : BaseController

{

   public ActionResult Index()

   {

     var repository = new ShipmentRepository();



     IEnumerable<Shipment> shipments;

     var organization = 

         ClaimHelper.GetCurrentUserClaim(                              

                         Fabrikam.ClaimTypes.Organization).Value;



     if (this.User.IsInRole(Fabrikam.Roles.ShipmentManager))

     {

       shipments = 

             repository.GetShipmentsByOrganization(organization);

     }

     else

     {

       var userName = this.User.Identity.Name;

       shipments = 

          repository.GetShipmentsByOrganizationAndUserName(

                                         organization, userName);    

     }



     var model = 

          new ShipmentListViewModel { Shipments = shipments };



     return View(model);

   }

 // ...

}

Index アクション ハンドラーは、アプリケーションのデータ ストアからの要求を満たすのに必要なデータを取得します。この動作は、現在のクレームのコンテキストから抽出されるユーザーのロールによって異なります。次に、リポジトリからの情報を HTML にレンダリングするために、コントローラーの View メソッドに制御を渡します。

セットアップと物理展開

フェデレーション ID を複数パートナーと使用する Fabrikam Shipping のようなアプリケーションは、自動プロビジョニングを利用して、顧客構成のクレームのマッピングを使用することがあります。Fabrikam Shipping の例では、自動プロビジョニングは実装されませんが、概念を実証するために Web インターフェイスのプロトタイプが含まれます。

注意

自動プロビジョニングは、パートナーの数が多い場合に必要になる可能性があります。

 

信頼関係の確立

自動プロビジョニングを実装する場合は、Web フォームを提供することによって、ADFS 2.0 のフェデレーション メタデータを含む XML ドキュメントの URI を顧客サイトの管理者が指定できるようにすることができます。または、管理者は必要なデータ要素を個別に提供することもできます。

アプリケーションの FP が ADFS 2.0 サーバーである場合、Windows PowerShell スクリプトを使用して、この構成手順を自動化できます。たとえば、ADFSRelyingParty コマンドを使用すると、特定のアプリケーションおよび FP にセキュリティ トークンを発行するように ADFS をプログラムで構成できます。PowerShell スクリプトで使用できる ADFS 2.0 のコマンドについては、MSDN® を参照してください。

注意

フェデレーション要求が処理されるとき、手動による手順 (契約締結の確認など) を含むワークフロー プロセスが開始されることがあります。手動による手順と自動化された手順のどちらも使用できますが、最初にプロビジョニングの要求を認証する必要があります。

 

フェデレーション メタデータ XML ファイルを使用してプロビジョニングを自動化する場合、このファイルは、顧客の発行者によって提供されます。次の例では、Adatum によって提供されるフェデレーション メタデータ ファイルを示します。このファイルには、Fabrikam Shipping がフェデレーション プロバイダーを構成および展開して Adatum 側発行者と通信するために必要なすべての情報が含まれます。以下に、このファイルの重要なセクションを示します。

組織セクション

組織セクションには、組織名が含まれます。

コピー

<Organization>

  <OrganizationDisplayName xml:lang="">

     Adatum

  </OrganizationDisplayName>

  <OrganizationName xml:lang="">Adatum</OrganizationName>

  <OrganizationURL xml:lang="">

     http://{adatum host}/Adatum.Portal/

  </OrganizationURL>

</Organization>

発行者セクション

発行者セクションには、発行者の URI が含まれます。

<fed:SecurityTokenServiceEndpoint>

    <EndpointReference 

        xmlns="http://www.w3.org/2005/08/addressing">

        <Address>

            https://{adatum host}/{issuer endpoint}/

        </Address>

    </EndpointReference>

</fed:SecurityTokenServiceEndpoint>

証明書セクション

証明書セクションには、発行者がトークンに署名するために使用する証明書 (base64 エンコード) が含まれます。

<RoleDescriptor ...>

    <KeyDescriptor use="signing">

        <KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">

            <X509Data>

               <X509Certificate>

                    MIIB5TCCAV ... Ukyey2pjD/R4LO2B3AO

                </X509Certificate>

            </X509Data>

        </KeyInfo>

    </KeyDescriptor>

</RoleDescriptor>

Adatum が Fabrikam Shipping の顧客として登録されたら、この顧客のシステム管理者は、Fabrikam の FP からの要求に応答するために、発行者も構成する必要があります。ADFS 2.0 では、このプロセスは、第 4 章「Web アプリケーション用のフェデレーション ID」で発行者 Litware が a-Order アプリケーション用にクレームの提供を開始したのと同じプロセスになります。

ユーザー構成のクレーム変換ルール

アプリケーションによっては、アプリケーションの FP によって使用されるクレームのマッピング ルールを顧客が構成することがあります。これは、アプリケーションの顧客が新しいクレーム タイプの生成を要求せず、既存の発行者を使用して、できるだけ簡単に構成できるようにする場合に行います。使用できるロールまたはグループ (Microsoft® Active Directory® からの) を顧客が既に持っている場合は、それらを再利用すると便利です。ただし、これらのロールは、アプリケーションが認識できるロールにマップする必要があります。

注意

多くのパートナーを持つアプリケーションでは、ユーザー構成のクレーム変換ルールが必要になる場合があります。

 

FP が ADFS 2.0 サーバーの場合は、PowerShell スクリプトを使用して、ロール マッピング ルールを設定できます。クレームのマッピング ルールは、顧客ごとに異なります。

前の章 | 次の章

ページのトップへ