Web サービス用のフェデレーション ID

  • [アーティクル]

第 4 章「Web アプリケーション用のフェデレーション ID」では、Adatum がパートナーの Litware に対して、a-Order アプリケーションを使用できるようにするプロセスを学びました。Litware のセールスマン Rick は、ローカルの資格情報を使用して、Adatum のドメインでホストされている a-Order Web サイトにログオンしました。

これを行うために Rick が必要としたのは、a-Order Web サイトにアクセスするブラウザーだけでした。しかし、要求が Web ブラウザー以外のアプリケーションから送られてくる場合は、どうなるでしょうか。a-Order によって提供される情報が Litware の社内アプリケーションに統合される場合はどうなるでしょうか。

アクティブな (「スマート」) クライアント アプリケーションのフェデレーション ID の動作は、Web ブラウザーのフェデレーション ID の動作とは異なります。ブラウザー ベースのシナリオでは、Web アプリケーションは、セキュリティ トークンを要求するとき、トークンを作成する発行者にユーザーのブラウザーをリダイレクトします。(このプロセスは、これまでのシナリオで説明しました。)リダイレクトを使用して、ブラウザーはユーザーの認証のほとんどを処理できます。アクティブ シナリオでは、クライアント アプリケーションは、信頼チェーン内のすべての発行者 (通常、IP と FP) にアクティブにアクセスし、必要なトークンを取得して変換します。

注意

アクティブ クライアントは HTTP リダイレクトを必要としません。

 

この章では、フェデレーション ID を使用するスマート クライアントの例について説明します。幸いなことに、Windows Communication Foundation (WCF) が Windows Identity Foundation (WIF) の標準機能としてサポートされています。WCF と WIF を使用すると、クレーム対応の Web サービスやクレーム対応のスマート クライアントを実装するのに必要な大量のコードを削減できます。

前提条件

Litware は、注文の状況を Adatum から直接読み取ることができるアプリケーションの作成を望んでいます。この要求を満たすために、Adatum は、Litware がインターネット上で呼び出すことができる、a-Order.OrderTracking という Web サービスを提供することに同意しました。

Adatum と Litware は、既にフェデレーション ID の確立に必要な作業か完了しており、いずれも、アクティブ クライアントとやり取りできる発行者を持っています。ファイアウォールやプロキシなど、必要な通信インフラストラクチャも配置されています。これらの要素については、第 4 章「Web アプリケーション用のフェデレーション ID」を参照してください。

注意

Ff359113.c80b8b93-e7aa-49ee-a040-c795505b219b(en-us,PandP.10).pngADFS 2.0 を使用している場合は、アクティブ クライアントのフェデレーション ID が標準機能としてサポートされています。

 

Adatum が行う必要があるのは、クレーム対応の Web サービスをインターネット上で公開することだけです。Litware は、Adatum の Web サービスを自身のクライアント アプリケーション内から呼び出します。クライアント アプリケーションは、Litware のセキュリティ領域内で実行されるため、Windows 認証を使用してユーザーの ID を作成した後、その ID を使用して、Adatum の FP に渡すことができるトークンを取得できます。

目標と要件

Litware と Adatum はどちらも、クレーム対応の Web サービスに基づいたコラボレーションの利点を理解しています。Litware は、Adatum の a-Order アプリケーションにプログラムからアクセスすることを望んでいます。Adatum は、別のセキュリティ領域に属する人やリソースの認証に関する責任を負いたくありません。たとえば、Adatum は Litware のユーザーのデータベースを保持したり管理することは望んでいません。

注意

アクティブ クライアントは、クレームを使用してリモート サービスにアクセスします。

 

Adatum と Litware はどちらも、既存のインフラストラクチャをできるだけ再利用したいと考えています。たとえば、Adatum は、Web サービスに対してアクセス許可を適用する際に、同社のブラウザー ベースの Web アプリケーションと同じ規則を使用したいと考えています。言い換えると、ブラウザー ベースのアプリケーションと Web サービスのどちらも、アクセス コントロールに対してロールを使用するということです。

ソリューションの概要

図 1 は、提案されたシステムの概要を示しています。

図 1

スマート クライアントのフェデレーション ID

この図は、さまざまなコンポーネント間の相互作用や関係の概要を示しています。HTTP リダイレクトが含まれない点以外は、前章の図と同じです。

Litware のクライアント アプリケーションは Windows Presentation Foundation (WPF) に基づいており、Litware 社員のデスクトップ上に展開されます。Litware のセールスマン Rick は、このアプリケーションを使用して Litware の注文情報を追跡します。

Adatum は、SOAP Web サービスをインターネットに公開します。この Web サービスは WCF を使用して実装され、標準の WCF バインドを使用します。WCF バインドにより、サービスは、認証と承認のための SAML (Security Assertion Markup Language) トークンを受け取ることができます。このサービスにアクセスするためには、クライアントは Adatum からのセキュリティ トークンを提示する必要があります。

図に示した一連の処理は、次の順番で実行されます。

  1. Litware の WPF アプリケーションが Rick の資格情報を使用して、Litware 側発行者にセキュリティ トークンを要求します。Litware 側発行者は Rick の認証を行います。認証が成功した場合、Rick は販売 (sales) 部門に属しているため、「Sales」の値を含む Group クレームを返します。
  2. 次に、WPF アプリケーションは、Litware 側発行者を信頼するように構成されている Adatum 側発行者に、このセキュリティ トークンを転送します。
  3. Adatum 側発行者は、フェデレーション プロバイダーとして動作し、クレーム Group:Sales を Role:Order Tracker に変換し、新しいクレーム Organization:Litware を追加します。変換後のクレームが、Adatum の Web サービス「a-Order.OrderTracking」が必要とするクレームです。以上は、ブラウザー ベースのシナリオで定義されているルールと同じです。
  4. 最後に、WPF アプリケーションが Web サービスに、注文情報を返すように求める要求を送信します。この要求には、前の手順で取得されたセキュリティ トークンが含まれます。

スマート クライアント アプリケーションはあらかじめ Web サービスの要件を認識しており、また、Web サービスの要件を満たすクレームを取得する方法もわかっているため、上記の一連の処理はブラウザー ベースの Web アプリケーションと若干異なります。クライアントは、最初に IP にアクセスし、次に FP、最後に Web サービスにアクセスします。スマート クライアント アプリケーションは、認証処理をアクティブに実行します。

実装の内部

クレーム ベースのスマート クライアント アプリケーションは、WCF の組み込み機能を使用して実装できます。または、WIF API を使用して下位レベルでコーディングすることもできます。a-Order.OrderTracking Web サービスは WCF 標準のバインドを使用します。

注意

a-Order.OrderTracking Web サービスは WCF 標準のバインドを使用します。

 

Web サービスを実装する

Web サービスの Web.config ファイルには、次の WCF サービス構成が含まれています。

<services>

<service 

      name="AOrder.OrderTracking.Services.OrderTrackingService" 

      behaviorConfiguration="serviceBehavior">

     <endpoint 

        address="" 

        binding="ws2007FederationHttpBinding" 

             

        bindingConfiguration=

              "WS2007FederationHttpBinding_IOrderTrackingService"  

        contract=

           "AOrder.OrderTracking.Contracts.IOrderTrackingService"

        />

     <endpoint address="mex" binding="mexHttpBinding" 

               contract="IMetadataExchange" />

   </service>

</services>

注意

サービスのエンドポイントが a-Order の追跡と同様にメタデータ交換をサポートしている場合、クライアントは Svcutil.exe などのツールを使用することで、簡単にサービスを見つけ、サービスにバインドできます。ただし、この例では、2 つの発行者 IP と FP が関係するため、ツールによって自動生成される構成を手動で編集する必要があります。発行者が 1 つだけの場合は、ツールによって生成される構成ファイルを編集する必要はありません。

 

Web.config ファイルには、クライアントのバインド情報と一致するバインド情報が含まれます。一致しない場合は、例外が発生します。

Web.config ファイルには、カスタマイズも含まれます。次の XML コードは、最初のカスタマイズを示しています。

<extensions>

   <behaviorExtensions>

      <add name="federatedServiceHostConfiguration" 

           type=

"Microsoft.IdentityModel.

   Configuration.ConfigureServiceHostBehaviorExtensionElement, 

 Microsoft.IdentityModel, ..." />

   </behaviorExtensions>

</extensions>

この動作拡張機能を追加すると、WCF パイプラインに WIF がアタッチされます。これにより、WIF は、公開キーとの間でセキュリティ トークンの整合性を確認できます。(WIF のアタッチを忘れると、サービス証明書が見つからないというメッセージが表示され、実行時例外が発生します。)

サービスの Web.config ファイルでは、<Microsoft.identityModel> 要素を使用して、WIF コンポーネントに必要な構成を指定します。これを次のコード例に示します。

<microsoft.identityModel>

  <service>

     <issuerNameRegistry 

        type=

          "Microsoft.IdentityModel.Tokens.

                ConfigurationBasedIssuerNameRegistry, 

                Microsoft.IdentityModel, Version=3.5.0.0,

             Culture=neutral,   

             PublicKeyToken=31bf3856ad364e35">

       <trustedIssuers>

         <add 

           thumbprint="f260042d59e14817984c6183fbc6bfc71baf5462"  

           name="adatum" />

       </trustedIssuers>

     </issuerNameRegistry>

     <audienceUris>

        <add value=

          "http://{adatum host}/a-Order.OrderTracking.Services/

                                        OrderTrackingService.svc"

        />

     </audienceUris>

...

Adatum 側発行者は、Web サービスの X.509 証明書を使用してセキュリティ トークンを暗号化するため、サービスの Web.config ファイルの <service> 要素にも、Web サービスの秘密キーに関する情報が含まれます。これを次の XML コードに示します。

<serviceCertificate>

   <certificateReference 

      findValue="CN=adatum" 

      storeLocation="LocalMachine" 

      storeName="My" 

      x509FindType="FindBySubjectDistinguishedName"/>

</serviceCertificate>

アクティブ クライアントを実装する

クライアント アプリケーションは、WCF プロキシとして動作し、相互作用を調整する役割を果たします。このことは、クライアントの App.config ファイルを調べると確認できます。次の XML コードは <system.serviceModel> セクションにあります。

<client>

  <endpoint 

     address=

       "http://{adatum host}/a-Order.OrderTracking.Services/

                                        OrderTrackingService.svc"

     binding="ws2007FederationHttpBinding" 

     bindingConfiguration=

              "WS2007FederationHttpBinding_IOrderTrackingService"

     contract="OrderTrackingService.IOrderTrackingService" 

     name="WS2007FederationHttpBinding_IOrderTrackingService">

     <identity>

        <dns value="adatum" />

     </identity>

   </endpoint>

</client>

address 属性は、注文追跡サービスの URI (Uniform Resource Indicator) を指定します。

binding 属性の ws2007FederationHttpBinding は、WCF が、a-Order 注文追跡サービスを呼び出すセキュリティ コンテキストを作成する際に WS-Trust プロトコルを使用することを示します。

<identity> セクションで指定されるドメイン ネーム システム (DNS) の値は、実行時にサービス証明書のサブジェクト名と比較して検証されます。

App.config ファイルの <bindings> サブセクションでは、入れ子になった 3 つのバインドが指定されています。次の XML コードは、そのうちの最初のバインドを示しています。

<ws2007FederationHttpBinding>

  <binding  

     name="WS2007FederationHttpBinding_IOrderTrackingService">

    <security mode="Message">

      <message>

        <issuer 

          address="https://{adatum host}/{issuer endpoint}"

          binding="customBinding"   

          bindingConfiguration="AdatumIssuerIssuedToken">

        </issuer>

      </message>

    </security>

  </binding>

</ws2007FederationHttpBinding>

注意

発行者のアドレスは、サンプルをどのように展開するかによって異なります。ローカル マシンで実行される発行者の場合、<issuer> 要素の address 属性は次のようになります。
https://localhost/Adatum.SimulatedIssuer/Scenario4/Issue.svc
ADFS 2.0 の場合、アドレスは次のようになります。
https://{adatum host}/Trust/13/IssuedTokenMixedSymmetricBasic256

 

このバインドは、スマート クライアント アプリケーションを a-Order.OrderTracking サービスに接続します。クレームを使用しない WCF バインドとは異なり、この特別なクレーム対応バインドには、Adatum 側発行者のアドレスとバインド構成を指定するメッセージ セキュリティ要素が含まれます。address 属性は、Adatum 側発行者のアクティブなエンドポイントを指定します。

注意

メッセージ セキュリティ要素は、発行者を識別します。

 

入れ子になったバインド構成には、AdatumIssuerIssuedToken のラベルが付けられます。入れ子の 2 番目のバインドは、次のようになります。

<customBinding>

  <binding name="AdatumIssuerIssuedToken">

    <security 

       authenticationMode="IssuedTokenOverTransport"

       messageSecurityVersion=

          "WSSecurity11WSTrust13WSSecureConversation13

                        WSSecurityPolicy12BasicSecurityProfile10"

    >

      <issuedTokenParameters>

        <issuer 

           address=

               "https://{litware host}/Trust/13/UsernameMixed"

           binding="ws2007HttpBinding" 

           bindingConfiguration="LitwareIssuerUsernameMixed">

        </issuer>

      </issuedTokenParameters>

    </security>

    <httpsTransport />

  </binding>

</customBinding>

注意

Ff359113.9813337c-0117-44a5-a7ac-f970934ed52a(en-us,PandP.10).png.NET Framework 3.5 のフェデレーション バインドでは、セキュリティで保護された通信をオフにする方法は提供されていません。(この機能は、バージョン 4.0 には用意されています。)ADFS 2.0 エンドポイントではセキュリティで保護された通信が無効になるため、この例では、カスタム バインドが必要です。

 

注意

発行者のアドレスは、サンプルをどのように展開するかによって異なります。ローカル マシンで実行される発行者の場合、<issuer> 要素の address 属性は次のようになります。
https://localhost/Litware.SimulatedIssuer/Scenario4/Issue.svc
ADFS 2.0 の場合、アドレスは次のようになります。
https://{litware host}/Trust/13/UsernameMixed

 

AdatumIssuerIssuedToken バインドは、このシナリオでは FP として動作する Adatum 側発行者への接続を構成します。

<security> 要素では、バインドが WS-Trust を使用することが指定されています。また、このバインドは、Litware 側発行者の URI も入れ子になっており、そのために「フェデレーション バインド」とも呼ばれます。バインドでは、LitwareIssuerUsernameMixed のラベルが付けられたバインド構成を、IP として動作する Litware 側発行者に対して使用することを指定します。次の XML コードは、この指定を示しています。

<ws2007HttpBinding>

  <binding name="LitwareIssuerUsernameMixed">

     <security mode="TransportWithMessageCredential">

       <message 

         clientCredentialType="UserName" 

         establishSecurityContext="false" 

       />

     </security>

  </binding>

</ws2007HttpBinding>

このバインドは、IP として動作する Litware 側発行者に接続します。これは、ユーザーの資格情報を Litware 側発行者に送信するので、標準の WCF HTTP バインドです。

注意

運用環境のシナリオでは、構成を clientCredentialType="Windows" に変更して、Windows 認証を使用するようにする必要があります。このサンプルでは、理解しやすくするために UserName 資格情報を使用しています。運用環境によっては、他のオプションの使用を検討することも考えられます。

 

アクティブ クライアントは、起動時に資格情報を提供しなければなりません。設定されている資格情報の種類が UserName の場合は、UserName プロパティを設定する必要があります。これを次のコードに示します。

private void ShowOrders()

{

  var client = 

          new OrderTrackingService.OrderTrackingServiceClient();

  

  client.ClientCredentials.UserName.UserName = "LITWARE\\rick";

  client.ClientCredentials.UserName.Password =  

                                      "thisPasswordIsNotChecked";



  var orders = client.GetOrdersFromMyOrganization();



  this.DisplayView(new OrderTrackingView()

                   {

                     DataContext = 

                         new OrderTrackingViewModel(orders)

                   });

}

アプリケーションが運用環境で展開されている場合、通常は Windows 認証が使用されるため、この手順は不要です。

注意

WCF フェデレーション バインドは、アクティブ クライアントと発行者の間のネゴシエーションをコードの追加なしで処理できます。WIF の WSTrustChannel クラスの呼び出しと同じ結果が得られます。

 

注意

Ff359113.b5333f58-f716-4e32-8ea2-545dd2f9d7c1(en-us,PandP.10).pngWIF の WSTrustChannel を使用すると、さらに細かく制御できますが、WS-Trust に関する十分な理解が要求されます。

 

承認戦略を実装する

Adatum の Web サービスは、承認戦略を SimpleClaimsAuthorizationManager クラスで実装します。サービスの Web.config ファイルには、<claimsAuthorizationManager> 要素にこのクラスへの参照が含まれています。

注意

クレーム承認マネージャーは、現在のユーザーがどのメソッドを呼び出すことができるかを決定します。

 

<claimsAuthorizationManager 

   type="AOrder.OrderTracking.Services.

                               SimpleClaimsAuthorizationManager,  

             AOrder.OrderTracking.Services" />

このサービス拡張を追加すると、WCF は、指定されたクラスの CheckAccess メソッドを承認のために呼び出します。これは、サービス操作が呼び出される前に発生します。

SimpleClaimsAuthorizationManager クラスの実装を次のコードに示します。

public class SimpleClaimsAuthorizationManager : 

                                       ClaimsAuthorizationManager

{

  public SimpleClaimsAuthorizationManager() { }



  public override bool CheckAccess(AuthorizationContext context)

  {

    return context.Principal.IsInRole(Adatum.Roles.OrderTracker);

  }

}

WIF では、基本クラス ClaimsAuthorizationManager が提供されています。アプリケーションは、このクラスから派生します。これは、認証されたユーザーが Web サービスのメソッドを呼び出すことができるかどうかをチェックする際に、アプリケーション独自の方法を指定できるようにするためです。

a-Order 注文追跡サービスの CheckAccess メソッドは、サービスのすべてのメソッドの呼び出し元に、Adatum.Roles.OrderTracker という値のロール クレームを持つよう要求します。この値は、Samples.Web.ClaimsUtilities プロジェクトの他の場所で文字列 "Order Tracker" として定義されています。

このシナリオでは、Litware 側発行者は IP として動作し、セールスマン Rick が Litware の販売部門に属している (値が Sales) と識別する Group クレームを発行します。Adatum 側発行者は、FP として動作し、Litware から受け取ったセキュリティ トークンを変換します。変換ルールの 1 つにより、Sales のグループ クレーム値を持つ Litware 社員にロール Order Tracker が追加されます。注文追跡サービスは、変換後のトークンを受け取り、サービスへのアクセス権を付与します。

アプリケーションをデバッグする

このサンプルのクライアントおよび Web サービスの構成ファイルには、メッセージのトレースとデバッグを有効にする設定が含まれています。トレースとデバッグは、既定では、有効にならないようにコメント アウトされています。

コメント アウトを外す場合は、<sharedListeners> セクションを更新して、わかりやすい場所、かつアプリケーションが書き込みのアクセス許可を持っている場所にログファイルが生成されるようにしてください。XML コードは次のようになります。

<sharedListeners>

  <add 

    initializeData="c:\temp\WCF-service.svclog"     

    type="System.Diagnostics.XmlWriterTraceListener"

    name="xml">

    <filter type="" />

  </add>

  <add 

    initializeData="c:\temp\wcf-service-msvg.svclog"      

    type="System.Diagnostics.XmlWriterTraceListener, System,

               Version=2.0.0.0, Culture=neutral, 

               PublicKeyToken=b77a5c561934e089"

    name="ServiceModelMessageLoggingListener" 

    traceOutputOptions="Timestamp">

    <filter type="" />

  </add>

</sharedListeners>

セットアップと物理展開

既定では、Web サービスはすべてのコンポーネントに関してローカルホストを使用します。運用環境では、クライアント、Web サービス、FP、IP にそれぞれ個別のコンピューターを使用する必要があります。

このアプリケーションを展開するには、モック発行者を置き換えて、アクティブ クライアントをサポートする ADFS 2.0 のような、運用レベルのコンポーネントにする必要があります。また、新しいサーバー名を反映するように Web.config と App.config の設定を調整する必要があります。

注意

展開時には、モック発行者を削除してください。

 

クライアントと Web サービスはどちらも、運用環境に展開するために再コンパイルする必要はありません。必要な変更はすべてそれぞれの .config ファイルに含まれています。

ADFS 2.0 を Web サービス用に構成する

ADFS 2.0 の場合は、Microsoft 管理コンソールを使用してエンドポイントを有効にします。

Litware からのトークンの取得には、UsernameMixed または WindowsMixed エンドポイントを使用できます。UsernameMixed の場合は、ユーザー名とパスワードを通信によって送信する必要があり、一方 WindowsMixed は Windows 資格情報を使用します。どちらのエンドポイントも SAML トークンを返します。

注意

"Mixed" サフィックスは、エンドポイントが整合性と機密性の保持のためにトランスポート セキュリティ (HTTPS ベース) とメッセージ セキュリティ (X.509 証明書ベース) を使用することを示します。

 

Adatum からのトークンを取得するために使用されるエンドポイントは、IssuedTokenMixedSymmetricBasic256 です。このエンドポイントは、入力として SAML トークンを受け付け、出力として SAML トークンを返します。また、トランスポート セキュリティとメッセージ セキュリティを使用します。

また、Litware と Adatum の両方が信頼関係を確立する必要があります。Litware は、Adatum ADFS を証明書利用者として構成し、LDAP (Lightweight Directory Access Protocol) Active Directory 属性に基づいてトークンを生成するルールを作成する必要があります。Adatum は Litware ADFS を ID プロバイダーとして構成し、グループ クレームをロール クレームに変換するルールを作成する必要があります。

最後に、Adatum は a-Order Web サービスを証明書利用者 (RP) として構成する必要があります。トークン暗号化を有効にし、ロール クレームと名前クレームを渡すルールを作成する必要があります。

前の章 | 次の章

ページのトップへ