2

許可された対象者を具体的にリストし、トークンがそれらの対象者のいずれかからのものであるかどうかを確認し、X509 証明書の拇印と発行者も確認するカスタム Secure Token Service がある場合、WSFederation は必要ですか?

私の STS は、トークンが特定のアプリケーションから既に取得され、ACS を介してルーティングされていることを確認しているため、必要なすべてのことを確認していませんか? アプリケーション A が ACS にリクエストを送信し、ACS がアプリケーション B にリクエストをすべてカスタム STS から送信したことはわかっています。

わかりやすくするために編集します。

申し訳ありませんが、元の投稿で少し不明確でした。セキュリティトークンハンドラーの代わりにSTSを使用したため、混乱が生じたと思います（別の方法で、タイプミスです）。アプリケーション A は、ユーザーのログイン オプション (google/facebook/yahoo/etc) を表示するカスタム ログイン サービスです。これらのサービスを介してログインすると、ACS からトークンが取得され、証明書利用者であるアプリケーション B に返されます。この RP には、トークンを受け入れるカスタム セキュリティ トークン ハンドラがあり、アプリケーション A と一致するオーディエンス URI があることを検証します。また、発行者が ACS であり、拇印が、 ACS。

これは、アプリケーション B が、アプリケーション A がログインに使用されたこと (その AudienceURI から来たため) と、ACS がトークンを送信したこと (発行者であり、拇印が一致したため) を理論的に認識していることを意味します。私が求めているのは、フェデレーション ID がアプリケーション B に必要かどうかです。トークンがどこから来たのかをすでに証明している場合、それを使用することで正確に何を得ることができますか?

4

1 に答える 1

2

あなたの質問はいくつかの説明が必要かもしれません。

まず、アプリケーションAとアプリケーションBの意味、およびSTSがこのシナリオにどのように適合するかを具体的に説明することをお勧めします。通常、アプリケーションはトークンを発行せず、STSのみが発行します。この意味で、ACSはアプリケーションを相互に接続せず、証明書利用者のアプリケーションをサードパーティのIDプロバイダーに接続します。

次に、Webを介した認証について話していて、ACSのトークンを発行するカスタムIDプロバイダーSTSがある場合は、おそらくすでにWS-Federationを使用しています。ただし、トークンの取得がブラウザーベースではなく、ACSへのバックエンドHTTP呼び出しを行っている場合、WS-Federationはシナリオに関連していません。

第3に、STSの観点から、許可されたオーディエンスのセットはトークン発行者に関するものではなく、そのSTSによって発行されたトークンを消費するエンティティを指します。つまり、STSがトークンを発行するのは一連のサブジェクトです。これは、アプリケーション自体、またはフェデレーションチェーンに沿った他の中間STSである可能性があります。（たとえば、ACSはそのような仲介者として機能します）

第4に、着信トークンで発行者の証明書を検証するときは、指紋を比較する以上のことを行う必要があります。指紋はトークンの暗号証明の一部ではありません。トークンの発行者が証明書の秘密鍵を所有していることを確認するには、トークンのデジタル署名を検証する必要があります。

これで問題が解決することを願っていますが、質問に答えられない場合はお知らせください。

于 2012-03-06T22:30:37.970 に答える