次の方法で共有

ID ソリューションでの AD FS 2.0

  • [アーティクル]

ID ソリューションで Active Directory フェデレーション サービス 2.0 を使用する

Zulfiqar Ahmed

サンプル コードのダウンロード

開発者なら、Windows Identity Foundation (WIF: 旧称 "Geneva Framework") についてある程度はご存知でしょう。WIF は、アプリケーションをクレーム対応にし、セキュリティ トークン向けのカスタム サービスを作成するための優れた API を提供します。Active Directory フェデレーション サービス 2.0 (AD FS 2.0: コードネーム "Geneva server") についてはあまり耳にしたことがないかもしれません。AD FS 2.0 は、エンタープライズ対応のフェデレーションおよびシングル サインオン (SSO) ソリューションです。AD FS 2.0 は AD FS 1.0 を発展させたもので、アクティブ (WS-Trust) およびパッシブ (WS-Federation と SAML 2.0) の両シナリオをサポートします。

この記事では、AD FS 2.0 の概要について説明してから、開発者が ID ソリューションで AD FS 2.0 を使用する方法について説明します。特に、Beta 2 リリースを基に、AD FS 2.0 のトークン発行機能に重点を置いて説明します。図 1 からもわかるように、このトークンの発行は AD FS 2.0 のほんの一部でしかありませんが、フェデレーション ID への移行を検討している .NET 開発者にとっては特に興味深いものでしょう。AD FS 2.0 はアーキテクチャ上、WIF と Windows Communication Foundation (WCF) の上位に構築されているため、こうしたテクノロジに精通していれば、AD FS 2.0 の扱いにも苦労することはありません。


図 1 AD FS 2.0 のアーキテクチャ

AD FS 2.0 の概要

大まかに言うと、AD FS 2.0 は図 2 に示すサービスの集まりです。

AD FS 2.0 の中核となるのがセキュリティ トークン サービス (STS) です。STS は、ID ストアに Active Directory を、アクセス プロトコルにライトウェイト ディレクトリ アクセス プロトコル (LDAP) を、属性ストアに SQL ストアやカスタム ストアを使用します。AD FS 2.0 の STS は、WS-Trust、WS-Federation、SAML (Security Assertion Markup Language) 2.0 などのさまざまなプロトコルを使用して、呼び出し元にセキュリティ トークンを発行します。トークン形式としては、SAML 1.1 と SAML 2.0 の両方をサポートします。

AD FS 2.0 の設計では、ワイヤ プロトコルとトークン発行の内部メカニズムが明確に分離されています。さまざまなワイヤ プロトコルは、システムの入り口で標準化されたオブジェクト モデルに変換されるため、AD FS 2.0 内部ではすべてのプロトコルに同じオブジェクト モデルが使用されます。このような分離により、さまざまなワイヤ プロトコルの複雑性に左右されない、明確な拡張性モデルが提供されます。AD FS 2.0 の拡張性の詳細については、製品版のリリース前には AD FS 2.0 SDK に公開される予定です。


図 2 AD FS 2.0 のコンポーネント

ID プロバイダーとしての AD FS 2.0

AD FS 2.0 は、いくつかの一般的なシナリオに使用できます。最も単純でよく目にするシナリオとしては、AD FS 2.0 を ID プロバイダーとして使用して、管理対象の ID 向けに SAML トークンを発行するシナリオです。この場合は、新しい証明書利用者を作成する必要があります。AD FS 2.0 での証明書利用者とは、アプリケーション (Web サイトや Web サービス) を表し、セキュリティ関連のすべての情報 (暗号化証明書、クレームの変換ルールなど) を保持します。

証明書利用者を設定する

新しい証明書利用者は、AD FS 2.0 経由で簡単に設定できます。AD FS 2.0 の管理コンソールの [Policy] (ポリシー) ノードから、Add Relying Party (証明書利用者の追加) ウィザードにアクセスできます。このウィザードでは、システム管理者が、[Select Data Source] (データ ソースの選択) ページで、適切なデータ ソースを指定する必要があります (図 3 参照)。


図 3 Add Relying Party (証明書利用者の追加) ウィザードの [Select Data Source] (データ ソースの選択) ページ

最初の 2 つのオプションでは、フェデレーションのメタデータを使用して、証明書利用者を自動的に構成できます。ネットワーク上やローカル ファイル内にある証明書利用者のフェデレーション メタデータにアクセスできる場合は、これらの 2 つのオプションのいずれかを選択してください。これらのオプションは、間違いが少なく、プロセス全体が自動化され、将来証明書利用者の詳細が変更される場合でも自動的に更新されます。このオプションは、こういった自動処理が提供されなかった AD FS 1.0 に比べれば大きな機能強化と言えます。

3 つ目のオプションでは、すべての構成の詳細を手動で入力しなければばりません。フェデレーション メタデータにアクセスできない場合や、証明書利用者の構成を細かく制御する必要がある場合のみ、このオプションを使用してください。

[Enter relying party configuration manually] (証明書利用者の構成を手動で入力する) オプションに実行してみて、新しい証明書利用者の設定に必要なすべての手順を理解しておくと役に立ちます。ウィザードの次の数ページでは、プロファイルの選択、証明書の構成、および証明書利用者 ID の構成を行います。プロファイルの選択では、ブラウザーベースと WCF ベースの両方のクライアントをサポートする必要がある場合は [AD FS 2.0 Profile] (AD FS 2.0 プロファイル) を選択し、AD FS 1.x との相互運用性のみが必要でアクティブ (WCF、CardSpace) クライアントをサポートする必要がない場合は [AD FS 1.x Profile] (AD FS 1.x プロファイル) を選択します。証明書の構成では、トークンを暗号化し、対応する秘密キーを持つ証明書利用者のみが暗号を解除し、発行されたトークンを使用できるようにします。証明書利用者 ID の構成では、すべてのトークン発行要求でこの証明書利用者を識別するための ID を構成します。

Add Relying Party (証明書利用者の追加) ウィザードが完了すると、Rules Editor (ルール エディター) ツールが開きます。このツールでは、クレームの発行と変換のルールを構成します。図 4 は、Rules Editor (ルール エディター) ツールを示しています。ここでは、1 つのクレームを含み、値をメインの属性ストアから取得するトークンを発行するように構成しています。この図からは、displayName 属性が Given Name クレームにマップされていることがわかります。AD FS 2.0 では、テキスト形式のドメイン固有の新しい言語が導入されています。この言語を使用すると、クレームの発行と変換のプロセスを導き出すための単純なルールを定義できます。各ルールは条件と操作から構成され、"[c] => a;" のように、セミコロンで終わります。変換ロジックは、トークンの発行プロセス中に順番に実行される一連のルールです。図 4 の [Simple View] (簡易表示) タブに、このようなルールを定義するためのユーザー インターフェイスが用意されています。[Advanced View] (詳細表示) タブでは、ドメイン固有の言語を使用して、ルールを直接作成できます。


図 4 Rules Editor (ルール エディター) ツール

この例は、AD FS 2.0 では信頼できる証明書利用者をいかに簡単に構成できるかを示しています。この時点で、AD FS 2.0 がトークンの発行要求を受け取ると、ワイヤ プロトコルから ID (WS-Trust の appliesTo 要素など) が抽出され、この ID を使用して対象の証明書利用者が検索されます。証明書利用者が見つかると、ウィザードで指定された設定を使用してトークンの発行ロジックが導き出されます。

それでは、WCF を使用して、AD FS 2.0 からこの証明書利用者のトークンを要求する方法について見ていきましょう。

WCF を使用してトークンを要求する

WCF を使用して AD FS 2.0 STS とやり取りするオプションには、次の 2 つがあります。

  • トークンの動作を WS-Trust クライアントとして明示的に取得する
  • インフラストラクチャがトークンを呼び出しの一部として暗黙のうちに取得するように、WCF クライアントを構成する

明示的に取得するオプションでは、次のように、WS-Trust プロトコルを使用して STS からトークンを要求するための単純で直接的な API が、WSTrustClient クラスで提供されます。

string baseUri = "https://bccoss.com/";

WindowsWSTrustBinding binding = new WindowsWSTrustBinding(SecurityMode.Transport);

WSTrustClient tokenClient = new WSTrustClient(binding,
    new EndpointAddress(baseUri + "Trust/2005/WindowsTransport/"),
    TrustVersion.WSTrustFeb2005,
    new ClientCredentials());

//create a token issuance request
RequestSecurityToken rst =
    new RequestSecurityToken(WSTrustFeb2005Constants.RequestTypes.Issue);
//Relying Party’s identifier
rst.AppliesTo = new EndpointAddress("http://local.zamd.net/");
//call ADFS STS
SecurityToken token = tokenClient.Issue(rst);

このコードでは、Windows 認証とトランスポート セキュリティを使用して、トークンを要求しています。ご覧のように、明示的モードでは、トークンそのものにアクセスします。このトークンを使用して、後からサービスを呼び出すことができます。たとえば、スマート クライアント アプリケーションでは、アプリケーションの起動時やログイン時にさまざまなサービスのトークンを取得し、トークン キャッシュに保存してから、アプリケーションの有効期間中にこれらのトークンを使用して、さまざまなバックエンド サービスを呼び出すことができます。また、同一の証明書を共有する、論理的には同じセキュリティ境界内に多数のサービスが存在しているシナリオでは、明示的モードを使用して 1 つのトークンを取得し、このトークンを使用して、それらすべてのサービスを呼び出すこともできます。

通常、証明書利用者の秘密キーにアクセスできるテスト環境では、次のコードを使用して、返されたトークンから SAML アサーションを抽出できます。

//Private Key certificate of RP (local.zamd.net)
X509Certificate2 rpCertificate = new X509Certificate2("zamd.net.pfx", "pwd");
string assertion = Util.ExtractSAMLAssertion(token, rpCertificate);

<saml:Attribute AttributeName="givenname" AttributeNamespace="https://schemas.xmlsoap.org/ws/2005/05/identity/claims">
    <saml:AttributeValue>Zulfiqar Ahmed</saml:AttributeValue>
</saml:Attribute>

SAML トークンには、この特定の証明書利用者用に構成されたクレームのみが含まれます。もう 1 度図 4 を見てみると、この証明書利用者の出力トークンが、1 つの属性を返すように構成されていることがわかります。多くのクレームを出力に含めるように証明書利用者の構成を編集すると、すべてのクレームがここで反映されるのを確認できます。また、クレームのポリシー言語を直接使用して、多様な変換ロジックやフィルター処理ロジックを定義することもできます。

WSTrustClient API と新しい WSTrust バインディングはどちらも WIF に含まれているため、上記のコードが動作するには、WIF がクライアントにインストールされている必要があります。WCF API を直接使用してトークンを明示的に取得することもできますが、WIF で提供される簡潔さと使いやすさは、実行すべき作業のリストから作業を 1 つ減らすことを可能にします。

図 5 のコードでは、IssuedSecurityTokenProvider が WCF 版の WSTrustClient に相当し、通常、ユーザーの代わりにトークンを要求する際に、wsFederationBinding によって使用されます。これはパブリック API であるため、トークンそのものへのアクセスが必要なコードで自由に使用できます。CustomBinding は WindowsWSTrustBinding に相当します。

図 5 トークンそのものにアクセスするための IssuedSecurityTokenProvider の使用

sstring baseUri = "https://bccoss.com/";

//Limited edition of WSTrustClient:)
IssuedSecurityTokenProvider provider = new IssuedSecurityTokenProvider();
provider.SecurityTokenSerializer = new WSSecurityTokenSerializer();

//Relying Party's identifier
provider.TargetAddress = new EndpointAddress(new Uri("http://local.zamd.net"));
provider.IssuerAddress = new EndpointAddress(new Uri(baseUri + "Trust/2005/WindowsTransport/"));

provider.SecurityAlgorithmSuite = SecurityAlgorithmSuite.Basic256;
provider.MessageSecurityVersion = MessageSecurityVersion.
WSSecurity10WSTrustFebruary2005WSSecureConversationFebruary2005WSSecurityPolicy11BasicSecurityProfile10;

HttpsTransportBindingElement tbe = new HttpsTransportBindingElement();
tbe.AuthenticationScheme = AuthenticationSchemes.Negotiate;
CustomBinding stsBinding = new CustomBinding(tbe);

provider.IssuerBinding = stsBinding;
provider.Open();
//Request a token from ADFS STS
SecurityToken issuedToken = provider.GetToken(TimeSpan.FromSeconds(30));

暗黙のうちに取得するオプションでは、標準の wsFederationHttpBinding を使用できます。この場合は、WCF インフラストラクチャがトークンを透過的に取得し、このトークンを呼び出しの一部としてサービスに送信します。新しい WCF プロキシを作成および使用してサービスを呼び出すときに、インフラストラクチャは毎回新しいトークンを取得します。明らかに、シナリオによっては負荷が高くなります。図 6 のコードでは、架空の EmployeeService を構成して、AD FS 2.0 からトークンを要求しています。

図 6 トークンを暗黙のうちに取得するための wsFederationHttpBinding の使用

<system.serviceModel>
  <services>
    <service name="EmployeeService.EmployeeService">
      <endpoint address="http://localhost:9990/ES"
        binding="ws2007FederationHttpBinding"
        contract="EmployeeServiceContract.IEmployeeService"
        bindingConfiguration="adfsFed"/>
    </service>
  </services>
  <bindings>
    <ws2007FederationHttpBinding>
      <binding name="adfsFed">
        <security mode="Message">
          <message negotiateServiceCredential="false" >
            <issuer address="https://bccoss.com/Trust13/KerberosMixed"
               binding="customBinding" bindingConfiguration="MixedKerberos"/>
          </message>
        </security>
      </binding>
     </ws2007FederationHttpBinding>
     <customBinding>
       <binding name="MixedKerberos">
         <security authenticationMode="KerberosOverTransport"/>
         <httpsTransport/>
       </binding>
     </customBinding>
   </bindings>
</system.serviceModel>
AD FS 2.0 の概念を WCF に対応付ける

AD FS 2.0 の主な機能は、認証済みのユーザーにトークンを発行することです。ユーザーは、Windows 認証などのさまざまな認証メカニズムを使用して認証されます。管理コンソールの [Endpoints] (エンドポイント) ノードを選択すると、サポートされているすべての認証メカニズムが表示されます。

[Endpoints] (エンドポイント) ノード内には、よく目にする WCF の 2 つのセキュリティ概念が、列見出しとして表示されていることがわかります。

  • AD FS 2.0 の Authentication Type (認証の種類) は、WCF の clientCredentialType に相当します。
  • Security Mode (セキュリティ モード) の選択肢は、Transport (トランスポート)、Message (メッセージ)、Mixed (混在) です。AD FS 2.0 の Mixed (混在) は、WCF の TransportWithMessageCredentials に相当します。

これらの 2 つの値のさまざまな組み合わせがそれぞれ異なるエンドポイントを使用して公開されるため、認証のニーズに基づいて特定のエンドポイントを選択します。たとえば、"Username/Password" (ユーザー名とパスワード) を使用した認証が必要であれば、Clear Password (明確なパスワード) という認証エンドポイントを選択します。

AD FS 2.0 の STS の概念を WCF のアドレス、バインディング、およびコントラクト (ABC) に対応付けると、次のようになります。

  • アドレス = AD FS 2.0 ベース アドレス + エンドポイントの URL パス
  • バインディング = エンドポイントのセキュリティ モード + 認証の種類
  • コントラクト = WS-Trust の標準プロトコル

AD FS 2.0 を別の STS と連合する

証明書利用者を作成するだけでなく、AD FS 2.0 とカスタム STS、または別の AD FS 2.0 との間で信頼関係を確立することも可能です。たとえば、ユーザーを認証してトークンを発行する STS が既に存在している場合は、単純に、この STS を AD FS 2.0 内部で信頼できる ID プロバイダーとして追加します。これにより、この STS から発行されるトークンを受け取れます。

ID プロバイダーを設定する

AD FS 2.0 での信頼できる新しい ID プロバイダーの設定は、新しい証明書利用者を設定と同様です。Add Identity Provider (ID プロバイダーの追加) ウィザードの外観と動作は、Add Relying Party (証明書利用者の追加) ウィザードとほぼ同じです (図 3 参照)。

[Configure Identifier] (識別子の構成) ページに移動するには、(図 3 で行ったように) 手動の構成オプションを再度選択して、[Choose Profile] (プロファイルの選択) ページで [AD FS 2.0 Profile] (AD FS 2.0 プロファイル) を選択します。[Configure URL] (URL の構成) ページの既定の設定はそのまま使用します。その後、ID プロバイダーの ID と公開キー証明書を選択して、ウィザードを終了し、新しい ID プロバイダーを登録します。

WCF を使用してトークンを要求する

AD FS 2.0 に追加の ID プロバイダーを登録すると、論理アーキテクチャは、図 7 のような構成になります。


図 7 ID プロバイダーを追加登録した AD FS 2.0 のアーキテクチャ

図 8 のコードでは、トークンを明示的に取得して、そのトークンをローカルにキャッシュすることにより、必要に応じてキャッシュしたトークンをサービスに送信する柔軟性が得られます。

図 8 トークンを明示的に取得するための IssuedTokenWSTrustBinding の使用

string adfsStsUri = "http://bccoss.com/Trust/2005/IssuedTokenAsymmetricBasic256";

//binding for local STS(IP-STS)
WSHttpBinding localStsBinding = new WSHttpBinding(SecurityMode.Message);

localStsBinding.Security.Message.ClientCredentialType = MessageCredentialType.None;
localStsBinding.Security.Message.EstablishSecurityContext = false;
localStsBinding.Security.Message.NegotiateServiceCredential = false;

EndpointAddress localStsEpr = new EndpointAddress(
   new Uri("http://localhost:9000/STS/"),
   new X509CertificateEndpointIdentity(new X509Certificate2(@"MyCustomSTSPublicKey.cer")));

//This binding will transparently acquire all the intermediate tokens as part of the call. (R-STS)
IssuedTokenWSTrustBinding fedBinding = new IssuedTokenWSTrustBinding(localStsBinding, localStsEpr);
fedBinding.TrustVersion = TrustVersion.WSTrustFeb2005;

EndpointAddress adfsStsEpr = new EndpointAddress(
    new Uri(adfsStsUri),
    new X509CertificateEndpointIdentity(new X509Certificate2("AdfsStsPubicKeyOnly.cer")));

WSTrustClient trustClient = new WSTrustClient(fedBinding, adfsStsEpr, TrustVersion.WSTrustFeb2005,
null);

//Create a security token request
RequestSecurityToken rst = new RequestSecurityToken(RequestTypeConstants.Issue);
//Set Relying Party's identifier accordingly
rst.AppliesTo = new EndpointAddress("http://local.zamd.net");

SecurityToken finalToken = trustClient.Issue(rst);

IssuedTokenWSTrustBinding と wsFederationHttpBinding とがよく似ている点は、中間トークンを取得するための IP-STS とのやり取りを開発者やユーザーが意識する必要をなくし、中間トークンの複雑性をすべて覆い隠していることです。こうした中間トークンが後に認証トークンとして R-STS に送信されます。

図 9 のコードでは、WCF クライアントから wsFederationHttpBinding を使用して、トークンをサービス呼び出しの一部として暗黙のうちに取得しています。

/IssuedTokenMixedSymmetricBasic256 エンドポイントと通信する際に、customBinding を使用していることに注意してください。標準の wsFederationHttpBinding では、AD FS 2.0 のこのエンドポイントと互換性がない、セキュリティが確保されるセッションの確立を試みるため、ここではうまく機能しません。WCF クライアントと AD FS 2.0 とを連合するには、customBinding か、WIF に付属している新しい WS-Trust ベースのバインディングの 1 つを使用する必要があります。

図 9 トークンを暗黙のうちに取得するための wsFederationHttpBinding の使用

<system.serivceModel>
   <bindings>
      <wsFederationHttpBinding>
         <binding name="R-STS">
            <security mode="Message">
               <message>
                  <issuer address="https://bccoss.com/Trust/2005/IssuedTokenMixedSymmetricBasic256" binding="customBinding" bindingConfiguration="IP-STS"/>
               </message>
            </security>
         </binding>
      </wsFederationHttpBinding>

      <customBinding>
         <binding name="IP-STS">
            <security authenticationMode="IssuedTokenOverTransport">
               <issuedTokenParameters>
                  <issuer address="http://localhost:9000/CustomSTS" binding="wsHttpBinding"/>
               </issuedTokenParameters>
            </security>
            <httpsTransport/>
         </binding>
      </customBinding>
   </bindings>

   <client>
      <endpoint address="http://localhost:9990/ES" binding="wsFederationHttpBinding" bindingConfiguration="R-STS"
contract="ServiceReference1.IEmployeeService" name="WSFederationHttpBinding_IEmployeeService"/>
      </client>
</system.serviceModel>

AD FS 2.0 とブラウザー クライアント

AD FS 2.0 には、Web シングル サインオン (WebSSO) と、WS-Federation プロトコルと SAML 2.0 プロトコルを両方を使用するフェデレーションに対する優れたサポートが含まれています。

概念上、ワイヤ表現は異なっていますが、WS-Federation と SAML のプロトコルはよく似ています。WS-Federation のワイヤ形式は、WS-Trust プロトコルと密接に関連しているため、アクティブ クライアントと (ブラウザー ベースの) パッシブ クライアントの両方を扱う場合は、WS-Federation を選択するのが論理的です。SAML プロトコルは、さまざまなベンダーと適切に相互運用されます。AD FS 2.0 は、これら両方のプロトコルをネイティブにサポートします。セキュリティ境界の内側では 1 つのプロトコル (WS-Federation など) に限定して使用し、SSO の送受信のプロトコル ブローカー ハブとして AD FS 2.0 を使用することをお勧めします。

例を見てみましょう。認証済みのユーザーのみに機能を提供する簡単な ASP.NET アプリケーションがあるとします。認証ロジックは、スタンドアロン アプリケーションの一部として実装されます。このアプリケーションとのやり取りは図 10 の手順で行います。


図 10 簡単な ASP.NET アプリケーションでの直接認証

ここでは、フォーム認証など、ASP.NET の通常の認証メカニズムが実装されます。この記事の目的は、このアプリケーションから認証機能を取り出し、代わりに AD FS 2.0 を使用することです。

AD FS 2.0 の設定 (図 11 参照) では、アプリケーションは AD FS 2.0 内部に登録される信頼できる証明書利用者になり、AD FS 2.0 によって発行されるトークンを信頼します。アプリケーションは、トークンの解析やクレームの抽出といった負荷の高い処理をすべて WIF を使用して実行します。標準の IIdentity/IPrincipal の抽象化を使用して、ID 情報がアプリケーションに提供されます。

AD FS 2.0 での分散認証は、直接認証よりもはるかに柔軟性が高く、次のように大きなメリットがあります。

  • 認証機能をアプリケーション外部に取り出しているため、アプリケーションに影響することなく、認証メカニズムを (たとえば、ユーザー名から Kerberos に) 変更できます。
  • アプリケーション自体が別のソースから必要な情報を取得するのではなく、すべての必要な情報を (トークンの一部として) 直接アプリケーションに提供できる、クレームベースのモデルの柔軟性が得られます。

WIF の Beta 2 リリースでは、認証ロジックをアプリケーション外部に取り出し、STS に委任できる、新しいプロジェクト テンプレートが導入されます。この記事の執筆時点では、これらのテンプレートは C# でのみ利用可能です。


図 11 AD FS 2.0 での分散認証

認証ロジックを外部に取り出す

アプリケーションから認証ロジックを外部に取り出すには、Microsoft Visual Studio のの [新しい Web サイト] ダイアログ ボックスを使用します。"Claims-aware Web Site" (クレーム対応 Web サイト) テンプレートを選択して、WIF を使用して事前に構成される標準の ASP.NET Web サイトを作成します。

Federation Utility (フェデレーション ユーティリティ) ウィザード (図 12 参照) を起動するには、ソリューション エクスプローラーで [Web サイト] ノードを右クリックして、メニューから [Modify STS Reference] (STS 参照の変更) をクリックします。


図 12 フェデレーション ユーティリティ

この例では、[Use an existing STS] (既存の STS を使用する) オプションを選択して、AD FS 2.0 を STS に指定します。ウィザードでは、必要な構成をすべて自動的に行うために、メタデータ ドキュメントの URL を必要とします。このメタデータ ドキュメントの URL は、AD FS 2.0 内部のエンドポイントとして利用できます。

フェデレーション メタデータには、STS の署名証明書、提供されたクレーム、トークン発行の URL などの、重要な情報が含まれます。この情報に標準の形式があると、ツールにより、STS と証明書利用者間の信頼関係を自動的に確立できます。

ウィザードの [Summary] (概要) ページに、web.config ファイル内に加えられた変更がまとめて表示されます。

Federation Utility (フェデレーション ユーティリティ) ウィザードは、Web サイトの WIF を構成し、次の機能を提供します。

  • 認証されていないすべての要求を AD FS 2.0 にリダイレクトする。
  • 有効なトークンを含むすべての要求を処理し、ID 情報を ClaimsIdentity/ClaimsPrincipal の形式でアプリケーションに提示する （アプリケーションは情報のソースに関係なく、標準の IPrincipal/IIdentity の抽象化を使用して、ID 情報にアクセスします)。

アプリケーションをテストする前に、最後に 1 つ構成の変更を AD FS 2.0 に加える必要があります。つまり、ブラウザー クライアントの証明書利用者に新たなエンドポイントを追加する必要があります。AD FS 2.0 がトークン発行要求を処理した後、トークンをブラウザーに送信する前に、次の 2 つの情報が必要になるため、このエンドポイントが必要になります。

  • トークンの送信先アドレス
  • トークンの送信に使用するプロトコル (SAML または WS-Federation)

[Test RP Properties] (Test RP のプロパティ) ダイアログ ボックスの [Endpoints] (エンドポイント) タブで、証明書利用者にパッシブ エンドポイントを追加できます。たとえば、エンドポイントの種類に WS-Federation を選択すると、AD FS 2.0 は WS-Federation プロトコルを使用して、トークンを証明書利用者に送信します。証明書利用者内部では、WS-Federation プロトコルをネイティブに認識する WIF がこれらのトークンを処理します。

これで、アプリケーションを参照しようとすると、認証のために AD FS 2.0 に自動的にリダイレクトされるようになります。ここでは、Windows 統合認証、証明書認証、またはユーザー名/パスワードの形式から認証方式を選択できます。

認証が成功したら、AD FS 2.0 によって発行されたトークンと共に、ユーザーがアプリケーションにリダイレクトされます。WIF はこのトークンを処理し、標準の ASP.NET メカニズム (Page.User など) を使用して、アプリケーションで最終的な ID を (クレームの形式で) 使用できるようにします。

ブラウザー ベースのフェデレーション

信頼できる ID プロバイダーをさらに追加することによって、基本的な外部認証のシナリオをフェデレーションのシナリオに拡張できます。ID プロバイダーのオプションは、認証プロセス中に表示されます。

AD FS 2.0 や別の信頼できる ID プロバイダーを使用して認証することが可能です。異なる ID プロバイダーを選択した場合は、その ID プロバイダーにリダイレクトされ、認証が成功するとすぐ、AD FS 2.0 にリダイレクトされます。AD FS 2.0 は、その後、信頼できる ID プロバイダーによって発行されたトークンに基づいて認証を行います。

強力な組み合わせ

ここで説明したように、AD FS 2.0 の STS により、WDF サービスやブラウザーベースのアプリケーションをクレーム対応にする、簡単ですぐに使用できるソリューションが提供されます。STS 自体は AD FS 2.0 の一部にすぎません。AD FS 2.0 には CardSpace のプロビジョニング システム、ルールベースの変換エンジン、信頼関係を自動的に管理するインフラストラクチャ、管理サービスと構成サービス、および関連ツールが含まれています。AD FS 2.0 を WIF と併用すると、Windows プラットフォーム上で ID ソリューションのプログラムを作成するための強力な組み合わせになります。

Zulfiqar Ahmed は、英国のアプリケーション開発コンサルティング (ADC) チームのシニア コンサルタントです。連絡先は http://zamd.net (英語) です。