2

WIF を使用して構築されたカスタム STS の証明書利用者である WCF サービスがあります。私の STS は、私のクライアント アプリケーションにホルダー オブ キー トークンを発行します。既存の「フロントエンド」サービスから呼び出す必要がある新しい「バックエンド」WCF サービスを作成しました。 STS から新しいトークンを取得せずに、フロントエンド サービスで着信セキュア トークンを使用してバックエンド サービスを呼び出すにはどうすればよいですか?

ここに画像の説明を入力

これまでのところ、私のフロントエンド サービスでは、カスタム Saml11SecurityTokenHandler を使用して着信 SamlSecurityToken に問題なくアクセスできます。

その後、アウト オブ バンド トークンをターゲット バックエンド サービスのサービス呼び出しにアタッチする 2 つの異なる方法を試しました。

  1. カスタム IssuedSecurityTokenProvider を作成する
  2. ChannelFactoryOperations.CreateChannelWithIssuedToken を使用する

ただし、これらの試みはどちらもエラーになります。私が知る限り、それは同じ行き止まりのようです - 彼らは署名された SamlSecurityToken を受け入れません。これらのメソッドはどちらも基本の SecurityToken クラスを受け入れますが、両方とも、SamlSecurityToken ではなく GenericXmlSecurityToken インスタンスが与えられた場合にのみ機能するようです。

更新: これは、箇条書き 1のコード サンプルと例外の詳細です。

更新 2: さらに調査を行った結果、私が見つけた最も近いものは、基本的に ActAs トークンのみを使用する WIF/ADFS のID 委任の使用に関する記事でした。この記事では、フロント エンド サービスがトークンを使用して STS に要求を発行します。クライアント アプリケーションから受け取ります。これには、カスタム STS の更新が必要になりますが、現時点では更新しないことを望んでいます。私の図に示したアプローチが、WIF や WS-Trust でも有効なのかどうか疑問に思い始めています。

4

1 に答える 1

1

結局のところ、フロントエンド サービスによって発行されたトークンを再利用してバックエンド サービスを呼び出すという概念は、WS-Trust プロトコルの範囲内で有効です。ただし、大部分のシナリオでは、これは適切な方法とは見なされません。これは、セキュリティと拡張性の問題によるものです。セキュリティ的には、これを行うと、両方の依存者が同じトークン暗号化アルゴリズム/キーを使用することを余儀なくされ、SAML トークンの対象者制限を認証する能力も低下します。これがまさに、ONBEHALFOF と ACTAS トークンの両方で ID 委任をサポートするように WS-Trust が更新された理由です。これらのいずれかを利用すると、この正確なシナリオをより安全かつ堅牢な方法で処理するのに役立ちます. WIF の API の設計は、この考え方に従っているようです。これが理由を説明しています。フロントエンド サービスが受信した署名済みの所有者トークンを再利用してバックエンド サービスを呼び出すための直接的な API はありません。

結論として、この質問に対する答えは 2 つあります。

A. 独自のカスタム ビルド STS の所有者である場合は、次の手順に従って、既定の WIF/WCF パイプラインの外部でこのシナリオを実現できます。

  1. クライアント リクエスター アプリケーションで、WSTrustChannel または IssuedSecurityTokenProvider を使用して、STS から手動でトークンを取得します。トークン タイプは GenericXmlSecurityToken、またはその派生型になることに注意してください。
  2. 帯域外でトークンをフロント エンド サービスに送信します。帯域外とは、追加のコントラクト フィールドとして、メッセージ ヘッダーで、またはその他の方法で送信することを意味します。
  3. フロント エンド サービス内では、ChannelFactory.CreateChannelWithIssuedToken() を使用するか、カスタムの IssuedSecurityTokenProvider を作成することにより、アウト オブ バンド トークンを使用してバックエンド サービスを簡単に呼び出すことができます。WIF は常に SamlSecurityToken などの特定の種類のブートストラップ トークンを作成するため、受信ブートストラップ トークンを使用する場合、これは不可能です。ChannelFactory と IssueSecurityTokenProvider はどちらも、GenericXmlSecurityToken でのみ機能します。

B. すぐに使用できる STS かカスタム STS のどちらを使用していても、ActAs または OnBehalfOf をサポートしている限り、適切な ID 委任を使用できます。

私の結論は主に以下の情報源に基づいています。これが、同様の要件を持つ他の誰かを助けることになることを願っています.

http://www.cloudidentity.com/blog/2008/09/07/delegation-or-traversing-multilayer-architectures/ (ACTAS/ONBEHALFOF とトークンの再利用の素晴らしい説明)

http://msdn.microsoft.com/en-us/library/ee748487.aspx (下にスクロールして、ACTAS と BEHALFOF の比較を見つけます)

http://docs.oasis-open.org/ws-sx/ws-trust/v1.4/errata01/os/ws-trust-1.4-errata01-os-complete.html (もちろん wstrust プロトコル)

于 2014-05-29T16:14:00.390 に答える