トークンがそれらのオーディエンスから来ているかどうかを確認し、X509証明書の拇印と発行者をチェックするカスタムのセキュアトークンサービスがあれば、WSFederationが必要ですか?カスタムSTSがある場合、フェデレーション認証が必要ですか?もしそうなら、なぜですか?
私のSTSは、特定のアプリケーションからトークンがすでに届いていて、ACS経由でルーティングされていることを確認しているため、必要なものをすべて確認していませんか?私は、アプリケーションAがカスタムSTSからアプリケーションBに要求を送信した要求をACSに送信したことを知っています。明確にするため
編集:私はのorignalポスト内のビットは不明であった
申し訳ありません。私は、セキュリティトークンハンドラの代わりにSTSを使用したので混乱が起こったと思います(異なる方法、ちょうどタイプミス)。 アプリケーションAはカスタムログインサービスで、ユーザー、google/facebook/yahoo/etcのログインオプションを表示します。これらのサービスを介してログインすると、ACSからトークンが取得され、アプリケーションB、依拠当事者に返されます。このRPにはカスタムトークンハンドラがあり、トークンを受け取り、トークンがアプリケーションAと一致するオーディエンスURIを持つことを検証します。また、発行者がACSであり、拇印がトークンの署名に使用された証明書ACS。
これは、理論的にアプリケーションBが、アプリケーションAが(そのオーディエンスURIから来るように)ログインに使用され、ACSがトークンを送信したことを知っていることを意味します(発行者と拇印一致)。私が願っているのは、アプリケーションBに連合アイデンティティーが必要かどうかです。トークンの出所をすでに証明していれば、それを使って正確に何を得ることができますか?
4点目として、ここではBertocciの例を使用していました。 blogs.msdn.com/b/vbertocci/archive/2008/11/26/an-identity-provider-and-its-sts-writing-a -custom-sts-the-october-beta-of-the-geneva-フレームワーク。aspx あなたがする必要があるように見えるのは、拇印と発行者を確認することです。 –
Ah。この記事は少し古いもので、Vittorio自身が投稿したように、この例はデモンストレーションのためだけであり、生産準備ができていないことに注意してください。 WIFは独自のカスタムセキュリティトークンハンドラを必要としないため、大したことではありません。WIFは現在、X509証明書署名検証を実行するセキュリティトークンハンドラをいくつか提供しています。 –
"WIFは今日、あなたに適切なX509証明書署名検証を実行する組み込みのセキュリティトークンハンドラを提供しています" そうかもしれないが、私はサイト固有のweb.configで設定したくない。そのため、オーディエンスURIタグを削除するには、デフォルトのセキュリティトークンハンドラをオーバーライドする必要がありました。私はあなたのアドバイスを取って、他の場所で適切な検証を探して、それを私のコードに追加しました。私はまだフェデレーションされたアイデンティティが必要かどうかについてアドバイスを使うことができました。 –