如何在Azure Web Apps中将redirect_uri协议设置为HTTPS [英] How to set redirect_uri protocol to HTTPS in Azure Web Apps

问题描述

我正面临以下问题.我有一个要部署到Azure的ASP Net Core 2 Web应用程序.应用程序身份验证与Azure Active Directory集成在一起，因此，当我尝试登录时，会发生以下请求:

I am facing the following problem. I have an ASP Net Core 2 web app that I want to deploy to Azure. The app authentication is integrated with the Azure Active Directory, so when I try to login the following requests happen:

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 Active Directory登录请求. 请注意，redirect_uri参数的协议为http .

The first GET is the normal Azure Active Directory login request. Notice the redirect_uri parameter has protocol http.

第二个请求是重定向到redirect_uri，这是带有某些参数的POST.由于我已将Azure配置为仅允许HTTPS通信，因此IIS使用HTTPS重定向到相同的URL.这是第三个请求.请注意，这第三个请求是GET请求，因为 HTTP重定向始终是GET请求 POST请求的所有参数均丢失，并且身份验证失败，从而在后端给出HTTP 500错误.

The second request is the redirection to the redirect_uri, a POST with some parameters. Since I have configured Azure to allow only HTTPS traffic, then IIS redirects to the same URL with HTTPS. That's the third request. Notice this third request is a GET request, since HTTP redirection is always a GET request all the paremeters of the POST request are lost, and the authentication fails giving a HTTP 500 error in the backend.

我尝试将redirect_uri参数中的协议手动更改为HTTPS，并且它可以正常运行.因此，我唯一需要做的就是让ASP Net Core知道该协议是HTTPS .

I have tried to manually change the protocol in the redirect_uri parameter manually to HTTPS, and it works as expected. So, the only thing I need is to make ASP Net Core aware that the protocol is HTTPS.

那怎么办?我在Internet上搜索了成千上万的网页，但没有明确的答案.

How can that be done? I've searched tons of pages in the Internet without a clear answer.

注意:redirect_uri由Kestrel设置.由于Azure应用服务将IIS放在我的Kestrel前面并在那里进行SSL终止，因此Kestrel和我的应用不知道该协议是HTTPS，因此在重定向uri中使用HTTP.

Note: the redirect_uri is set by Kestrel. Since Azure App Service puts an IIS in front of my Kestrel and does the SSL termination there, Kestrel and my app do not know the protocol is HTTPS, and therefore use HTTP in the redirect uri.

更新1

按照 @Bruce 的建议，我尝试了示例

Following the advice of @Bruce I've tried the example here, cloning the repository and configuring the application and the AD as stated there, and I am able to reproduce the error.

重定向URI继续使用http协议.如果仅在AD应用程序配置中添加https终结点作为回复URL，则会收到错误The reply address 'http://testloginad.azurewebsites.net/signin-oidc' does not match the reply addresses configured for the application.如果将http协议端点添加为回复URL，则会收到HTTP 500错误，如下所示:

The redirect URI continues to be with http protocol. If I only add in the AD app configuration the https endpoint as reply URL, I get the error The reply address 'http://testloginad.azurewebsites.net/signin-oidc' does not match the reply addresses configured for the application. If I add the http protocol endpoint as reply URL, then I get an HTTP 500 error like the following:

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()

我仍在思考问题与Kestrel有关，因为它不知道通过HTTPS正在建立连接，但是我不知道如何将信息传递给它.

I am still thinking the problem is related to Kestrel not knowing the connection is being done through HTTPS, but I do not know how to convey that information to it.

更新2

我使用的Azure Web应用程序的配置:

The configuration of the Azure web app I used:

• Wep应用程序类型:Linux
• 应用程序设置:
  • 堆栈:.NET Core 2.0
  • 启动文件:dotnet ./WebApp-OpenIDConnect-DotNet.dll
  • WEBSITE_HTTPLOGGING_RETENTION_DAYS:5
  • ASPNETCORE_ENVIRONMENT:开发
  • 始终打开:打开
  • ARR相似性:开启
  • Wep App Type: Linux
  • Application Settings:
    • Stack: .NET Core 2.0
    • Startup file: dotnet ./WebApp-OpenIDConnect-DotNet.dll
    • WEBSITE_HTTPLOGGING_RETENTION_DAYS: 5
    • ASPNETCORE_ENVIRONMENT: Development
    • Always ON: On
    • ARR Affinity: On
    • 仅HTTPS:打开
    • Docker容器日志记录:文件系统
    • 配额(MB):35
    • 保留期(天):5

    在web.config文件中，我将以下行修改为:

    In the web.config file I modified the following line to read like this:

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

    基本上，我使用斜杠而不是反斜杠来避免Linux路径出现问题.

    Basically I put forward slashes instead of back slashes to avoid problems with Linux paths.

    其他所有设置都使用默认设置.

    Everything else is configured using default settings.

    更新3 根据 @Tratcher 的要求，我在此处添加服务器响应的标头(为简洁起见，我仅包含标头我认为是相关的，如果您想看到其他任何内容，请随时要求我添加):

    UPDATE 3 As requested by @Tratcher, I add here the headers of the server reponses (for the sake of brevity I include only the headers I consider relevant, if you want to see any other one, feel free to ask me to add it):

    • 第一个请求(GET https://login.microsoftonline.com/ecf...):
      • 服务器:Microsoft-IIS/10.0
      • Set-Cookie:ESTSAUTHPERSISTENT=AQAFCCEADDB…sts; path=/; secure; HttpOnly
      • 严格的运输安全性:max-age=31536000; includeSubDomains
      • First request (GET https://login.microsoftonline.com/ecf...):
        • Server: Microsoft-IIS/10.0
        • Set-Cookie: ESTSAUTHPERSISTENT=AQAFCCEADDB…sts; path=/; secure; HttpOnly
        • Strict-Transport-Security: max-age=31536000; includeSubDomains
        • 位置:https://testloginad.azurewebsites.net/signin-oidc
        • 服务器:Microsoft-IIS/10.0
        • Location: https://testloginad.azurewebsites.net/signin-oidc
        • Server: Microsoft-IIS/10.0
        • 服务器:Kestrel

        任何请求中都没有x-forwarded-proto标头.

        No x-forwarded-proto header appears in any of the requests.

        请注意，问题的根源可能在于第二个请求的重定向，即将HTTP POST重定向到HTTPS GET.该重定向不应该发生，因为POST应该首先通过HTTPS请求，但是由于第一个请求的redirect_uri中的HTTP协议错误，因此没有发生.

        Note that one the root of the problem may be in the redirect of the second request, that is redirecting the HTTP POST to an HTTPS GET. That redirect should not happen since the POST should have been requested through HTTPS in the first place, but that did not happen because of the wrong http protocol in the redirect_uri of the first request.

        更新4

        我已经确认只有在选择的服务计划是Linux时，才会发生此问题.如果服务计划是Windows计划(使用与UPDATE 1示例完全相同的代码和配置)，则根本不会发生此问题.这可能是解决该问题的方法，但不是解决方案. Linux应用程序服务似乎存在缺陷.

        I have confirmed this issue only happens if the chosen service plan is a Linux one. The issue does not happen at all if the service plan is a Windows one (using exactly the same code and configuration from the example of UPDATE 1). This may be a workaround, but not a solution, to the problem. The Linux app service seem to be flawed.

        推荐答案

        我自己遇到了问题.我深入研究了Microsoft的Microsoft.AspNetCore.Authentication，并了解了他们如何构造重定向网址:

        I had the problem myself. I took a deep dive into Microsoft's Microsoft.AspNetCore.Authentication and found out how they constructed the redirect url:

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

        因为Web应用程序已经强制执行HTTPS，可以使用Startup.cs中的以下代码解决此问题

        Because the Web App already forces HTTPS this can be solved with the following code in the Startup.cs

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

        您只需添加以下参考:

        using Microsoft.AspNetCore.HttpOverrides;
        

        这篇关于如何在Azure Web Apps中将redirect_uri协议设置为HTTPS的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！