問題タブ [ws-trust]

SAP Netweaver と ADFS (STS として機能) の間に SSO セットアップがあります。そのため、一部のユーザーはカスタム ASP.Net アプリケーションにログインし、このアプリケーションは ADFS から SAML アサーションを要求して SAP システムにアクセスします。

問題は、SAP のドキュメントによると、SAP システムの証明書利用者識別子は URL ではなく (単なる名前)、その方法は ADFS で指定されている (例: SAPSYSTEMRPID) ということです。

AppliesTo フィールドに Uri が必要な場合に、WS-TRUST (ADFS が提供するもの) を使用して発行されたトークンを取得するにはどうすればよいでしょうか? デフォルトのスキーム、何らかの規則はありますか?

私は何日もテーブルに頭をぶつけてきましたが、明らかに何かが欠けています

私の理解では、クレームは WS-trust 標準に基づく STS のものであり、SAML2 標準とは何の関係もありません。WS-trust STS トークンは、SAML を使用してその形式でクレームを送信できます。私は正しいですか？

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 でも有効なのかどうか疑問に思い始めています。

Windows Identity Foundation は、WSO2 の WS-Trust から要求された SAML2 トークンを受け入れることができません (例外を参照)。トークンを変更することは可能ですか、またはこの問題に対する既知の解決策はありますか?

WS-Trust を使用する .NET WCF サービスと通信する Java クライアントを構築しようとしています。

私の .net STS は、http エンドポイントでホストされる WS2007Http バインディングと UserNameToken ベースの認証を使用します。

設定 NegotiateServiceCredential は false に設定され、Apache CXF でサポートされていない SslContextToken の使用を抑制します。

私のJavaクライアントコードは次のとおりです。

結果は例外です。

暗号オブジェクトがコードで設定されているため、これは完全に間違っているようです。.properties ファイルを使用して jaxws:client 構成を使用して暗号化を構成することと、コードで設定することの両方を試みました。

CXF STS での作業 - STS クライアントの例https://web-gmazza.rhcloud.com/blog/entry/cxf-sts-tutorialの例に従い、私のサンプル コードはhttps://github.com/sampleref/にあります。参照用のCXFSecurity。デバッグ時に、STS プロバイダーで以下のようなエラーが見つかりました

いくつかの入力を提供してください。これは私にとって本当に重要です。CXF STS client throws Request does not contain Security header/Response message does not contain WS-Addressing propertiesで STS クライアントからのより詳細なエラーを投稿しました

WIF 4.5 と WS-Trust を使用して ADFS から SAML アサーションを取得しようとしています。これにより、そのアサーションをサービス プロバイダーに送信して OAuth チケットを取得できます。

実際、SAML アサーションを取得できましたが、SubjectConfirmationData の Recipient 属性が受信されないため、有効なものではありません。そして、それは必須のデータムです。

コンソール アプリケーションでテストを行っています (したがって、Fiddler を使用して確認したように、認証情報を使用して実行され、アサーションを受け取る前に Kerberos ネゴシエーションを実行します)。そうすることでトークンを取得しています ( Windows 資格情報と .net 4.5 WIF を使用した RequestSecurityTokenに基づく):

このコードでは、送信されるリクエストは次のとおりです。

受信したアサーションは有効なようですが、SubjectConfirmationData に受信者が含まれていないため、そのアサーションをサービス プロバイダーに送信すると、認証に失敗します。

サーバーにa を送信する Web IdP Initiated Login を使用し、samlp:AuthnRequestその場合に ADFS が発行する取得済みの SAML アサーションを (再び Fiddler を使用して) デコードすると、受信者属性が受信され、SSO が機能します。アサーションを取得するために使用される方法が異なることがわかります (この場合は Web-SSO が使用されます) が、どちらの場合も依拠当事者は同じであるため、発行されるアサーションは類似しているはずです。

ADFS から WS-Trust を使用してトークンを取得するときに、適切な受信者を受け取る方法はありますか?