0

IP-STSを信頼する紺碧のACSサービスがあります。
アクティブなシナリオでは、最初にユーザー名とパスワードのクレデンシャルを使用してIP-STSからJWTトークンを取得します。Oauth2エンドポイントがあり、すべてが非常にうまく機能します。このIP-STSトークンをAzureACSによって発行されたJWTトークンと「交換」することは可能ですか？もしそうなら、これを行うコードの例はありますか？（さらに悪いことに、私のコードはすべてJavaScript（実際にはTypeScript）ですが、それは実際には問題ではありません）。

更新：ACSOAuth2ドラフト13エンドポイントでヒントに取り組んでいます。
次のように進めます。カスタムSTS（ThinkTecture STS）に、「ACSOAuth2ドラフト13エンドポイント」レルムのJWTトークンを提供するように依頼します。これには、TT STSでグローバルなoAuthクライアントIDとシークレットが必要であり、これらは無関係であると思います。TT STS管理では、このレルム用に構成された対称鍵：key1があります。3部構成のJWTトークンを受け取ります。トークンの署名は確かにkey1で作成されています。次に、このトークンを、指定されたサービスIDとパラメーターからのクライアントIDとシークレットを使用してACSに渡します。

var form = new FormUrlEncodedContent(new Dictionary<string, string>
{
  { "grant_type", "http://oauth.net/grant_type/jwt/1.0/bearer" },
  { "assertion", rawtoken (the header dot body dot signature form TT STS },
  { "scope", "http://localhost"}
});

残念ながら、{"error"： "invalid_client"、 "error_description"： "ACS50027：JWTトークンが無効です。\ r \ nトレースID：b107cda5-393b-4b50-b14a-ebaa0ac41913 \ r \ nタイムスタンプ：2012-12-05 08：58：10Z "}

JWTはベータ版であるため、ACS50027はまだ文書化されていないことを理解しています。難しいのは、これをデバッグする既知の方法がないことです。いや助けてくれてありがとう。

4

3 に答える 3

2

これは間違いなく可能ですが、既存のACSサンプルのいずれもそれを行っていないので、未知の領域にわずかにいます。

私がお勧めするアプローチは、ACS OAuth2ドラフト13エンドポイントを使用することです（このサンプルのように、SAMLの代わりにJWT、サービスIDの代わりにIdP）。リクエストは次のようになります。

grant_type = http：//oauth.net/grant_type/jwt/1.0/bearer&assertion=（JWT）＆scope =（RPレルム）。

JWTの発行者は、登録済みのIDプロバイダーと一致する必要があります。また、関連する署名キーに加えて、必要に応じてクレームを通過または変更するためのルールと、トークンタイプがJWTであるRPが必要です。

于 2012-12-03T22:54:59.780 に答える
0

さて、私はついにこれを行う方法を見つけました。あなたのヒントは成功のために重要でした。（非常に）注意が必要なのは、IP-STSが対称鍵を使用してJWTトークンに署名することです。プログラムで（odata apiを使用して）このキーをIDプロバイダーの下のACSバックオフィスに挿入する必要がありました。（管理コンソールにはこのキーはどこにも表示されません）すべてがほぼ正常です。唯一の問題は、ACSが元のトークンからオーディエンス（「aud」）をコピーするのに対し、別のオーディエンス（「スコープ」）のトークンを要求することです。そこに何かアイデアはありますか？

于 2013-02-28T08:51:10.387 に答える
-1

いいえ、ACSでトークンを交換することはできません。これを行うための唯一の実行可能な方法は、ACSでIP-STSをIdPとして登録できるかどうかです（IP-STSがWS-TRUSTプロトコルをサポートしている場合は登録できます）。これにより、パッシブシナリオが発生します。

考えられる唯一のアクティブなシナリオの方法は、サービスIDを使用したユーザー名/パスワード認証を使用してACSから直接JWTトークンを取得することです。ACSでサービスIDを適切に管理することは、ASP.NETメンバーシッププロバイダーを管理することではありませんが、管理APIを備えています。

サービスIDを使用して認証するための可能な方法は、パスワード、対称鍵、X.509証明書です。したがって、元のIP-STSを十分にひねって、JWTトークンのクレームとして対称鍵を提供すると、その対称鍵で認証されたサービスIDを使用してACSからJWTトークンを取得できるようになります。

しかし、すでにJWTトークンを持っている場合、ACSから別のトークンが必要なのはなぜですか？

アップデート

クレーム変換は、「パッシブ」モードでの唯一のオプションです。アクティブモードの場合、（私が知っている）唯一の方法はサービスIDを使用することであり、したがってクレーム変換はありません。

Passiveの問題は、セキュリティ上の理由から、ACSが非表示のPOSTフォームを作成して、変換されたトークンをRelying Party Application（RP）にPOST送信することです。したがって、受動的行動を積極的に得る方法はありません。試用のためだけにできること、そして非表示の形式のパッシブPOSTが原因で失敗することは、次のとおりです。実験する意思がある場合（テストしておらず、結果にまったく気づいていません）、wsignin1.0元のJWTトークンを提供するアクションのシミュレーションを試みる場合があります。サインインリクエストの作成方法については、WS-Federationパッシブリクエスタープロファイルのセクション3.1をご覧ください。Fiddlerを使用して、イベントのパッシブシナリオチェーンを完全に追跡することもできます。あなたが再構築しようとするのはwsignin1.0登録されたIdPからACSに戻るリクエスト。

ある時点で、FORM要素を含む結果のHTMLが作成されます。そのフォームには2つの非表示フィールドがあります-waの値とwsignin1.0URLwresultエンコードされたURLが含まれます<t:RequestSecurityTokenResponse xmlns:t="http://schemas.xmlsoap.org/ws/2005/02/trust">....これはあなたが望むものです。

IdPからACSへの元のサインインリクエストの再作成に成功した場合、これは機能します。

于 2012-12-03T06:57:13.967 に答える