WSTrustChannelFactory および WSTrustChannel

  • [アーティクル]

Windows Communication Foundation (WCF) に既に精通している方は、WCF クライアントが既にフェデレーションに対応していることをご存知でしょう。 WSFederationHttpBinding または同様のカスタム バインディングを使用して WCF クライアントを構成することで、サービスに対するフェデレーション認証を有効にできます。

WCF は、バックグラウンドでセキュリティ トークン サービス (STS) から発行されたトークンを取得し、このトークンを使用して、サービスに対して認証を行います。 このアプローチの主な制限は、クライアント側のサーバーとの通信を制御できないことです。WCF では、バインディングの発行済みトークンのパラメーターに基づいて、STS へのセキュリティ トークンの要求 (RST) が自動的に生成されます。 したがって、クライアントは、要求ごとに RST のパラメーターを変更すること、セキュリティ トークンの要求に対する応答 (RSTR) を調査して表示要求などの情報を取得すること、または後で使用するためにトークンをキャッシュすることはできません。

現時点では、WCF クライアントは基本的なフェデレーション シナリオに適しています。 ただし、Windows® Identity Foundation (WIF) でサポートされている主要なシナリオの 1 つでは、WCF では簡単に許可できないレベルで RST を制御する必要があります。 そのため、WIF では、STS との通信を細かく制御できるようにする機能が追加されます。

WIF では、次のフェデレーション シナリオがサポートされます。

  1. WIF の依存関係を持たない WCF クライアントを使用して、フェデレーション サービスに対して認証を行う。

  2. WCF クライアントで WIF を有効にして、ActAs 要素または OnBehalfOf 要素を STS への RST に挿入する。

  3. WIF を単独で使用して、STS からトークンを取得し、WCF クライアントがこのトークンを使用して認証できるようにする。

最初のシナリオは読んだとおりです。既存の WCF クライアントは引き続き、WIF の証明書利用者および STS と共に動作します。 このトピックでは、残りの 2 つのシナリオについて説明します。

ActAs または OnBehalfOf を使用した既存の WCF クライアントの拡張

一般的な ID 委任のシナリオでは、クライアントが中間層サービスを呼び出すことで、バックエンド サービスが呼び出されます。 中間層サービスは、クライアントとして、またはクライアントの代理として機能します (詳細については、「よく寄せられる質問」の「ActAs と OnBehalfOf」セクションを参照してください)。 この情報は、RST の ActAs トークン要素または OnBehalfOf トークン要素を使用して、WS-Trust 発行者に渡されます。

WCF では、任意の XML 要素を RST に追加できるようにするバインディングの拡張ポイントが公開されます。 ただし、拡張ポイントはバインディングに関連付けられているため、呼び出しごとに RST の内容を変更する必要があるシナリオでは、呼び出しごとにクライアントを再作成する必要があり、パフォーマンスが低下します。WIF では、ChannelFactory クラスの拡張メソッドを使用することで、帯域外で取得した任意のトークンを開発者が RST に添付できるようにします。 次のコード例では、クライアントを表すトークン (X.509、ユーザー名、SAML (Security Assertion Markup Language) トークンなど) を取得し、それを発行者に送信する RST に添付する方法を示します。

IHelloService serviceChannel = channelFactory.CreateChannelActingAs<IHelloService>( clientSamlToken ); serviceChannel.Hello(“Hi!”);

WIF には、次の利点があります。

  • RST をチャネルごとに変更できる。そのため、中間層サービスはクライアントごとにチャネル ファクトリを再作成する必要がないので、パフォーマンスが向上します。

  • 既存の WCF クライアントに対して動作する。そのため、ID 委任形式を有効にする必要がある既存の WCF 中間層サービスを簡単にアップグレードできます。

ただし、それでもクライアント側の STS との通信を制御することはできません。 その点については 3 番目のシナリオで説明します。

発行者との直接通信および発行されたトークンを使用した認証

一部の高度なシナリオは、WCF クライアントの拡張だけでは対応できません。 通常、WCF のみを使用している開発者は、Message In/Message Out コントラクトを使用し、発行者の応答のクライアント側の解析を手動で処理します。

WIF には、クライアントが WS-Trust 発行者と直接通信できるように、WSTrustChannelFactory クラスおよび WSTrustChannel クラスが導入されました。 次のコード例に示すように、WSTrustChannelFactory クラスおよび WSTrustChannel クラスを使用すると、クライアントと発行者との間で、型が厳密に指定された RST オブジェクトと RSTR オブジェクトを送受信できます。

WSTrustChannelFactory trustChannelFactory = new WSTrustChannelFactory( stsBinding, stsAddress ); WSTrustChannel channel = (WSTrustChannel) trustChannelFactory.CreateChannel(); RequestSecurityToken rst = new RequestSecurityToken(RequestTypes.Issue); rst.AppliesTo = new EndpointAddress(serviceAddress); RequestSecurityTokenResponse rstr = null; SecurityToken token = channel.Issue(rst, out rstr);

Issue メソッドで out パラメーターを使用して、クライアント側での検査のために、RSTR へのアクセスを許可しています。

ここまでは、トークンを取得する方法について説明しました。 WSTrustChannel オブジェクトから返されるトークンは、証明書利用者への認証に必要なすべての情報を格納している GenericXmlSecurityToken です。 次のコード例では、このトークンを使用する方法を示します。

IHelloService serviceChannel = channelFactory.CreateChannelWithIssuedToken<IHelloService>( token ); serviceChannel.Hello(“Hi!”);

ChannelFactory オブジェクトの CreateChannelWithIssuedToken 拡張メソッドは、帯域外でトークンを取得したこと、および発行者に対する通常の WCF 呼び出しを停止し、代わりに、取得したトークンを使用して証明書利用者に対して認証を行う必要があることを WIF に示しています。 これには、次の利点があります。

  • トークンの発行処理を完全に制御できる。

  • 出力方向の RST のこれらのプロパティを直接設定することで、ActAs と OnBehalfOf のシナリオがサポートされる。

  • RSTR の内容に基づいて、クライアント側の信頼の決定を動的に行うことができる。

  • Issue メソッドから返されたトークンをキャッシュし、再利用できる。

  • WSTrustChannelFactory および WSTrustChannel を使用することで、WCF のベスト プラクティスに従い、チャネル キャッシュ、エラー、および回復形式を制御できる。

詳細については、WIF をインストールした場所にある Extensibility/WSTrustChannel サンプルを参照してください。