私は単純なロード バランサーを実装しています。これは、ブラウザーからの着信要求を解析し、適切な ASP.NET アプリケーションにルーティングする http リスナーです。特定のポート (8801) でリッスンし、ルーティング時に元の URI を保持し、ポート番号のみを変更します。たとえば、 https ://machine.domain.com:8801/testsite/Default.aspx をhttps://machineにルーティングできます。 .domain.com:8811/testsite/Default.aspx
セキュリティ ルーティングがなくても問題なく動作します。ASP.NET アプリに WIF フェデレーションを適用しようとすると、問題が発生します。ADFS 2.0 を使用しています。私が試した2つのシナリオは次のとおりです。
シナリオ1
証明書利用者の WS-Federation パッシブ エンドポイントが ASP.NET アプリ URI に設定されている
ブラウザーからロード バランサー URI にアクセスすると、ロード バランサーが ASP.NET アプリにルーティングされ、ページが読み込まれます。ただし、STS からの RequestSecurityTokenResponse は (ロード バランサーではなく) ASP.NET アプリに直接リダイレクトされます。エンドポイントの設定。動作しますが、ASP.NET アプリへの通信全体をロード バランサー経由で処理したいので、このシナリオは私の要件を満たしていません。
シナリオ 2
証明書利用者の WS-Federation パッシブ エンドポイントがロード バランサー URI に設定されている
ロード バランサーの URI がブラウザーを介してアクセスされると、ロード バランサーは ASP.NET アプリにルーティングされ、Unauthorized 応答が返されます。ブラウザーは STS にリダイレクトされ、RequestSecurityTokenResponse はロード バランサーにリダイレクトされますが、さらに ASP.NET アプリにルーティングされると、I 401 の応答を取得 - 権限がありません: 資格情報が無効なため、アクセスが拒否されました。これは、ロード バランサー URI に対して saml トークンが発行されるため、URI の不一致によるものと思われます。オーディエンス URI とレルムのさまざまな組み合わせを試しましたが、成功しませんでした。
私の質問は、ASP.NET アプリはロード バランサーからしかアクセスできないため、ロード バランサーが必要なすべてのフェデレーション通信を処理できるようにする回避策があるかどうかです。
私の問題を十分に明確に説明したことを願っています。
どうもありがとうございました