web-dev-qa-db-ja.com

Azure WebAppsでredirect_uriプロトコルをHTTPSに設定する方法

私は次の問題に直面しています。 AzureにデプロイしたいASP Net Core 2Webアプリがあります。アプリ認証はAzureActive Directoryと統合されているため、ログインしようとすると次のリクエストが発生します。

_GET https://login.microsoftonline.com/ecf3f643-27e5-4aa7-9d56-fd350e1e9c37/oauth2/authorize?client_id=20a2bcb5-0433-4bb4-bba3-d7dc4c533e85&redirect_uri=http://myapplication.mydomain.com/account/signin [...]  200 OK
POST http://myapplication.mydomain.com/account/signin 301 Redirect --> https://myapplication.mydomain.com/account/signin
GET https://myapplication.mydomain.com/account/signin 500 Internal Server Error
_

最初のGETは、通常のAzure ActiveDirectoryログイン要求です。 _redirect_uri_パラメーターにプロトコルhttpがあることに注意してください。

2番目の要求は、_redirect_uri_、いくつかのパラメーターを含むPOSTへのリダイレクトです。 HTTPSトラフィックのみを許可するようにAzureを構成したため、IISはHTTPSを使用して同じURLにリダイレクトします。それが3番目のリクエストです。 HTTPリダイレクトは常にGETリクエストです POSTリクエストのすべてのパラメータが失われ、認証が失敗してHTTP 500エラーが発生するため、この3番目のリクエストはGETリクエストであることに注意してください。バックエンド。

_redirect_uri_パラメーターのプロトコルを手動でHTTPSに変更しようとしましたが、期待どおりに機能します。したがって、必要なのは、プロトコルがHTTPSであることをASP NetCoreに認識させることだけです。

どうすればそれができますか？私は明確な答えなしにインターネットでたくさんのページを検索しました。

注：_redirect_uri_はKestrelによって設定されます。 Azure AppServiceはKestrelの前にIISを配置し、そこでSSL終了を行うため、KestrelとアプリはプロトコルがHTTPSであることを認識しないため、リダイレクトURIでHTTPを使用します。

更新1

@ Bruce のアドバイスに従って、例 here を試し、リポジトリのクローンを作成し、そこに記載されているようにアプリケーションとADを構成すると、エラーを再現できます。 。

リダイレクトURIは引き続きhttpプロトコルを使用します。 ADアプリ構成に応答URLとしてhttpsエンドポイントのみを追加すると、エラー_The reply address 'http://testloginad.azurewebsites.net/signin-oidc' does not match the reply addresses configured for the application_が発生します。 httpプロトコルエンドポイントを応答URLとして追加すると、次のようなHTTP500エラーが発生します。

_System.Exception: Correlation failed.
   at Microsoft.AspNetCore.Authentication.RemoteAuthenticationHandler`1.<HandleRequestAsync>d__12.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter`1.GetResult()
   at Microsoft.AspNetCore.Authentication.AuthenticationMiddleware.<Invoke>d__6.MoveNext()
_

私はまだ考えています問題は接続がHTTPSを介して行われていることを知らないケストレルに関連していますが、その情報をそれに伝える方法がわかりません。

UPDATE 2

使用したAzureWebアプリの構成：

  • Wepアプリの種類：Linux
  • アプリケーションの設定：
    • スタック：.NET Core 2.0
    • スタートアップファイル：dotnet ./WebApp-OpenIDConnect-DotNet.dll
    • WEBSITE_HTTPLOGGING_RETENTION_DAYS：5
    • ASPNETCORE_ENVIRONMENT：開発
    • 常にオン：オン
    • ARRアフィニティ：オン
  • カスタムドメイン：
    • HTTPSのみ：オン
  • 診断ログ：
    • Dockerコンテナログ：ファイルシステム
    • クォータ（MB）：35
    • 保持期間（日）：5

_web.config_ファイルで、次の行を次のように変更しました。

_<aspNetCore processPath="dotnet" arguments="./WebApp-OpenIDConnect-DotNet.dll" stdoutLogEnabled="false" stdoutLogFile="./stdout.log" />
_

基本的に、Linuxパスの問題を回避するために、バックスラッシュではなくスラッシュを使用します。

その他はすべて、デフォルト設定を使用して構成されます。

UPDATE 3@ Tratcher の要求に応じて、サーバー応答のヘッダーをここに追加します（簡潔にするために含めます）。私が関連すると思うヘッダーだけです。他のヘッダーを見たい場合は、遠慮なく追加してください）：

  • 最初のリクエスト（_GET https://login.microsoftonline.com/ecf..._）：
    • サーバー：_Microsoft-IIS/10.0_
    • セットCookie：_ESTSAUTHPERSISTENT=AQAFCCEADDB…sts; path=/; secure; HttpOnly_
    • Strict-Transport-Security：_max-age=31536000; includeSubDomains_
  • 2番目のリクエスト（_POST http://testloginad.azurewebsites.net/signin-oidc_）：
    • 場所：_https://testloginad.azurewebsites.net/signin-oidc_
    • サーバー：_Microsoft-IIS/10.0_
  • 3番目のリクエスト（_GET https://testloginad.azurewebsites.net/signin-oidc_）：
    • サーバー：Kestrel

_x-forwarded-proto_ヘッダーはどのリクエストにも表示されません。

問題の原因の1つは、2番目のリクエストのリダイレクトにある可能性があることに注意してください。つまり、HTTP POSTをHTTPSGETにリダイレクトします。 POSTは最初にHTTPSを介して要求されるべきだったので、そのリダイレクトは発生しないはずですが、最初の要求のredirect_uriのhttpプロトコルが間違っていたために発生しませんでした。

UPDATE 4

この問題は、選択したサービスプランがLinuxの場合にのみ発生することを確認しました。サービスプランがWindowsの場合（UPDATE 1の例とまったく同じコードと構成を使用）、この問題はまったく発生しません。これは回避策かもしれませんが、問題の解決策ではありません。 Linuxアプリサービスに欠陥があるようです。

asp.net-coreoauth-2.0azure-web-sitesazure-active-directory
12
joanlofe

私は自分で問題を抱えていました。私はMicrosoftのMicrosoft.AspNetCore.Authenticationを深く掘り下げて、リダイレクトURLをどのように構築したかを調べました。

protected string BuildRedirectUri(string targetPath)
        => Request.Scheme + "://" + Request.Host + OriginalPathBase + targetPath;

WebアプリはすでにHTTPSを強制しているため、これはStartup.csの次のコードで解決できます。

app.UseForwardedHeaders(new ForwardedHeadersOptions
{
      ForwardedHeaders = ForwardedHeaders.XForwardedProto
});

この参照を追加するだけです。

using Microsoft.AspNetCore.HttpOverrides;
6
FerronSW

これらのリンクを参照することにより：

そして、構成に3つの変更を適用すると、Linuxアプリプランですべてが機能するようになりました。

ステップ1：ForwardedHeadersOptionsを構成します

_services.Configure<ForwardedHeadersOptions>(options =>
{
    options.RequireHeaderSymmetry = false;
    options.ForwardedHeaders = ForwardedHeaders.XForwardedFor | ForwardedHeaders.XForwardedProto;

    // TODO : it's a bit unsafe to allow all Networks and Proxies...
    options.KnownNetworks.Clear();
    options.KnownProxies.Clear();
});
_

ステップ2：public void Configure(IApplicationBuilder app, IHostingEnvironment env)メソッドでUseForwardedHeaders

_app.UseForwardedHeaders();
_

ステップ3：本番環境ではUseHttpsRedirectionのみを使用します

_if (env.IsDevelopment())
{
    app.UseDeveloperExceptionPage();

    // Forward http to https (only needed for local development because the Azure Linux App Service already enforces https)
    app.UseHttpsRedirection();
}
else
{
    app.UseExceptionHandler("/Error");
    app.UseHsts();
}
_
1
Stef Heyenrath

次のForwardedHeadersOptions構成の組み合わせによって機能するようになりました。

Options.ForwardedHeaders = ForwardedHeaders.All;
Options.ForwardLimit = null;
Options.KnownNetworks.Add(new IPNetwork(IPAddress.Parse("10.0.0.0"), 8));
Options.KnownNetworks.Add(new IPNetwork(IPAddress.Parse("172.16.0.0"), 12));
Options.KnownNetworks.Add(new IPNetwork(IPAddress.Parse("192.168.0.0"), 16));
0
AndrewG

この問題を修正する方法は、次のとおりです。

public void Configure(IApplicationBuilder app, IHostingEnvironment env)
{
    // ...

    /***
        * Forwarded Headers were required for nginx at some point.
        * https://docs.Microsoft.com/en-us/aspnet/core/Host-and-deploy/proxy-load-balancer?view=aspnetcore-2.1#nginx-configuration
    ***/
    app.UseForwardedHeaders(new ForwardedHeadersOptions
    {
        RequireHeaderSymmetry = false,
        ForwardedHeaders = ForwardedHeaders.XForwardedProto | ForwardedHeaders.XForwardedFor
    });

    // ...
}

残念ながら、私はそれをどのように修正したかについてコードを見に行きましたが、なぜそれがそのようだったのか覚えていません：）（私が残したコメントもあまり役に立ちません）

それが役に立てば幸い。

0
Bart Calixto

これが 推奨ソリューションへのリンク fromChris Ross（akaTratcher）、ASP.NETIdentityおよびIdentityServerの人。

必要なコードは

services.Configure<ForwardedHeadersOptions>(options =>
{
   options.ForwardedHeaders = ForwardedHeaders.XForwardedFor | ForwardedHeaders.XForwardedProto;
   // Only loopback proxies are allowed by default. Clear that restriction because forwarders are
   // being enabled by explicit configuration.
   options.KnownNetworks.Clear();
   options.KnownProxies.Clear();
});

app.UseForwardedHeaders();

.NET Core v2.xにのみ適用できるようで、3.0で修正されています。

0
Alex Klaus

私は次の問題に直面しています。 AzureにデプロイするASP Net Core 2Webアプリがあります。アプリ認証はAzureActiveDirectoryと統合されています。

あなたはAAD認証をどのようにWebアプリケーションに統合したかについて言及しなかったので。さらに、_http://analytics.lantek360.com_または_https://analytics.lantek360.com_を介してアプリケーションにアクセスする場合、_redirect_uri_クエリ文字列は同じになることを確認しました：_http://analytics.lantek360.com/account/signin_。この問題を絞り込むために、詳細（承認リクエストをどのように作成したかなど）を提供していただけます。

HTTPSトラフィックのみを許可するようにAzureを構成したので

HTTPSのみの設定では、URL書き換えルールを使用してHTTPをHTTPSにリダイレクトします。詳細は、次のとおりです Azure App ServiceをHTTPSのみにする方法 。

要件については、middileware Microsoft.AspNetCore.Authentication.OpenIdConnect を手動で使用して、AzureADを.NetCoreWebアプリケーションに統合できると想定しています。このアプローチでは、以下のチュートリアルに従うことができます。

Azure AD（v1.0エンドポイント）をASP.NET Core Webアプリに統合する

Azure AD（v2.0エンドポイント）をASP.NET Core Webアプリに統合する

注：

OpenID Connectの_redirect_uri_はhttp(s)://<your-appname>.azurewebsites.net/signin-oidcのようになります。 Httpsのみが必要なため、AADアプリのリダイレクトURI（_https://{your-appname}.azurewebsites.net/signin-oidc_）を追加するだけです。

さらに、 App Service Authentication/Authorization を利用して、Webアプリケーションのコードを変更せずにAAD認証を有効にすることもできます。詳細については、Azure Portalで Azure Active Directoryログインを使用するようにAppServiceアプリを構成する に従うことができます。

0
Bruce Chen