パス ベースのルーティングを使用して、Open Auth ID .net Core 2 アプリケーションを Web アプリケーション ファイアウォールの背後にある App Service として構成する際に問題があります。
私のアプリケーションは myapp.azurewebsites.net で、ネットワーク制限によりパブリック インターネットからアクセスできません。同じ VNET に WAF をデプロイし、パス ベースのルート "/Admin*" を使用して WAF と App Service 間のトラフィックを許可しました。
その結果、 https ://myapp.azurewebsites.netはインターネットにアクセスできなくなりますが、https://myWAF/Adminはアクセス可能になり、アプリ サービスにマップされます。
このセットアップは正常に機能しますが、Open ID 認証を .net コア アプリケーションに導入すると、発信 Location ヘッダーに応答 URI として myapp.azurewebsites.net/signin-oidc が含まれます。
ホストがインターネットからアクセスできないため、これは機能しません。私はいくつかのアプローチを試みました。
- Azure App Registrations のアプリケーション登録 URL にWAF URL ( https://myWAF/Admin/signin-oidc ) を追加して、AAD が変更された URL を (正当なものとして) 受け入れられるようにしました。
- startup.cs に app.UseForwardedHeaders (すべての X-Forwarded ヘッダーの再利用を強制する) をコーディングしました。これは、App Service によって送信される Location ヘッダーに影響を与えないようです。WAF が X-Forwarded ヘッダーを送信していると思いますが、そうである場合、Open Auth ID スタックはそれらを使用していません。
- myapp.azurewebsites.net を WAF URL に置き換えるために、WAF でヘッダーの書き換えをコーディングしました。これにより、URL が正しく置き換えられ、コールバックが許可されますが、相関エラー (「ノンスが一致しない」ことを意味する一般的な Open ID スタック エラーのようです) で失敗します。ナンスが、呼び出されている URL に基づいている可能性があります。戻る - 私の場合は WAF リダイレクトにより変更されますが、それは推測です)。
アプリで X-Forwarded ヘッダーを使用して、WAF でヘッダーの再書き込みをコード化する必要性を回避できるように思えますが、これを使用して変更することに成功した例は見つかりません。 Open ID によって送信される応答 URI。
私の質問です。OAuth コンテキストでプロキシを処理するための正しいアプローチとして X-Forwarded ヘッダーを使用していますか、それとも WAF でのヘッダー書き換えが正しいアプローチですか?
設定しました