CODEWITHSUNDEEP
asp.net-coreoauth-2.0azure-web-app-serviceazure-active-directory
joanlofe
joanlofe

Reputation: 3637

How to set redirect_uri protocol to HTTPS in Azure Web Apps

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

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

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.

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.

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

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.

UPDATE 1

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.

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

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.

UPDATE 2

The configuration of the Azure web app I used:

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" />

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

Everything else is configured using default settings.

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

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

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.

UPDATE 4

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.

Upvotes: 16

Views: 11014

Answers (8)

Sgedda
Sgedda

Reputation: 1531

I had the same problem in .NET 6, after solving the issue with http instead of https redirect like suggested above;

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

My application is hosted in azure through container registry. And I ran in to the problem of "redirect_uri_mismatch" even after this fix.

I got it solved it by setting ASPNETCORE_FORWARDEDHEADERS_ENABLED=true in application settings.

enter image description here

Also added in azure devops pipeline like:

- task: AzureAppServiceSettings@1
  inputs:
    azureSubscription: 'zzz'
    appName: 'xxx'
    resourceGroupName: 'yyy'
    appSettings: |
      [
          {
          "name": "ASPNETCORE_ENVIRONMENT",
          "value": "$(environment)",
          "slotSetting": false
          },
          {
          "name": "ASPNETCORE_FORWARDEDHEADERS_ENABLED",
          "value": "true",
          "slotSetting": false
          }
      ]

Upvotes: 3

mrmichaeldev
mrmichaeldev

Reputation: 329

Azure uses the incoming Request.Schema to build the reply URL even if you want it to be https. If you're using TLS termination anywhere it can cause the schema to be read as 'http'

I tried X-Forwarded with my Kubernetes cluster and couldn't get that configured correctly but it was much easier to just fix the outgoing response with a custom middleware.

app.Use(async (c, next) =>
{
    await next();

    if (c.Response.Headers.ContainsKey("Location"))
    {
        var location = c.Response.Headers["Location"];
        if (!location.Any(c => c.Contains("redirect_uri=https")))
        {
            var newLocation = location.Select(c => 
            c.Replace("redirect_uri=http", "redirect_uri=https"));
            c.Response.Headers["Location"] = new StringValues(newLocation.ToArray());
        }
    }
});

Upvotes: 0

Alex Klaus
Alex Klaus

Reputation: 8954

Here is a link to the recommended solution from Chris Ross (aka Tratcher), the ASP.NET Identity and IdentityServer guy.

The code you need is

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

It seems to be applicable to .NET Core v2.x only and is fixed in 3.0.

Upvotes: 3

AndrewG
AndrewG

Reputation: 186

Made it working by combination of the following ForwardedHeadersOptions configuration:

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

Upvotes: 0

FerronSW
FerronSW

Reputation: 535

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;

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
});

You only have to add this reference: 

using Microsoft.AspNetCore.HttpOverrides;

Upvotes: 17

Stef Heyenrath
Stef Heyenrath

Reputation: 9850

By consulting these links:

And applying 3 changes to the configuration, I got everything working on a Linux App Plan.

Step 1 : configure the 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();
});

Step 2 : UseForwardedHeaders in the public void Configure(IApplicationBuilder app, IHostingEnvironment env) method 

app.UseForwardedHeaders();

Step 3 : Only use UseHttpsRedirection for production

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

Upvotes: 5

Bart Calixto
Bart Calixto

Reputation: 19725

The way to fix the issue is exactly as follows:

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

    /***
        * Forwarded Headers were required for nginx at some point.
        * https://learn.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
    });

    // ...
}

unfortunately I went to look at the code on how I fixed it but I don't remember why was it that way :) (the comment I left isn't very helpful either)

hope it helps.

Upvotes: 0

Bruce Chen
Bruce Chen

Reputation: 18465

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.

Since you did not mention that how did you integrate the AAD authentication into your web application. Moreover, I have checked that when accessing your application via http://analytics.lantek360.com or https://analytics.lantek360.com, the redirect_uri query string would the same: http://analytics.lantek360.com/account/signin. You could provide more details (e.g how did you build the authorize request) for us to narrow this issue.

Since I have configured Azure to allow only HTTPS traffic

The HTTPS Only setting uses a URL Rewrite rule for you to redirect HTTP to HTTPS. Details, you could follow How to make an Azure App Service HTTPS only.

For your requirement, I assume that you could manually use the middileware Microsoft.AspNetCore.Authentication.OpenIdConnect to integrate Azure AD into your .Net Core web application. For this approach, you could follow the tutorials below:

Integrating Azure AD (v1.0 endpoint) into an ASP.NET Core web app

Integrating Azure AD (v2.0 endpoint) into an ASP.NET Core web app

Note:

The redirect_uri for OpenID Connect would look like http(s)://<your-appname>.azurewebsites.net/signin-oidc. Since you need to Https only, you just need to add the redirect URI (https://{your-appname}.azurewebsites.net/signin-oidc) for your AAD app.

Moreover, you could also leverage App Service Authentication / Authorization for enable AAD authentication without changing code in your web application. Details, you could follow Configure your App Service app to use Azure Active Directory login in Azure Portal.

Upvotes: 0

Related Questions