[Bug] Unable to authenticate using Azure front door and AAD

[TaylorTheDeveloper]

Which version of Microsoft Identity Web are you using?
Microsoft.Identity.Web 1.8.1

Where is the issue?

• Web app
  • [x ] Sign-in users
  • Sign-in users and call web APIs
• Web API
  • Protected web APIs (validating tokens)
  • Protected web APIs (validating scopes)
  • Protected web APIs call downstream web APIs
• Token cache serialization
  • In-memory caches
  • Session caches
  • Distributed caches
• Other (please describe)

Is this a new or an existing app?
This is a new app that requires authentication + azure front door.

Repro
I'm trying to simply place my authenticated web app behind Azure Front door.

I have an Azure front door with a single front end host. This maps to a single web app on the back end right now. The back end is configured as follows:

The rules are configured as follows:

 services.AddAuthentication(OpenIdConnectDefaults.AuthenticationScheme)
                .AddMicrosoftIdentityWebApp(Configuration.GetSection("AzureAd"));

 "AzureAd": {
    "Instance": "https://login.microsoftonline.com/",
    "Domain": "<removed>",
    "ClientId": "<removed>",
    "TenantId": "organizations",
    "CallbackPath": "/signin-oidc",
  },

Expected behavior
When the user hits the frontdoor endpoint their request is forwarded to origin to login. The logged in user is never redirected away from the front door end point and only ever sees the front door endpoint.

Actual behavior
When the user hits the frontdoor endpoint they're redirected to the login page. Once logged in via the login ui, they are redirected back to the app service endpoint and not the front door endpoint.

Possible solution

I did find a similar bug (#115), and conceptually I think a similar issue is happening but did not have success with implementing this. Futhermore looking for guidance in general. Essentially, I think the cdn makes a request to origin and origin only knows to reply with it's own hostname so when we hit the login page, origin has already said 'redirect to origin'. How can I reliably make this redirect back to the front door?.

Additional context / logs / screenshots
Add any other context about the problem here, such as logs and screenshots.

[jmprieur]

@TaylorTheDeveloper : would this article help you? Deploy to App Services Linux containers or with proxies

[TaylorTheDeveloper]

Thanks for sharing that- I did check that out and had gone down a similar path but did not have success using forwarded headers.

It's worth noting that I am using windows app service, not linux app services. I'm also using .Net Core 3.1.

From that article:

This means that when a user browses to the web app, they will be redirected to login.microsoftonline.com as expected, but with redirect_uri=http://.azurewebsites.net/signin-oidc instead of redirect_uri=https://.azurewebsites.net/signin-oidc.

If I update the last line to highlight the difference:

but with redirect_uri=https://.azurewebsites.net/signin-oidc instead of redirect_uri=https://.azurefd.net/signin-oidc.

[jmprieur]

@Tratcher can you please help for this case?

[Tratcher]

Start with the troubleshooting instructions at https://docs.microsoft.com/en-us/aspnet/core/host-and-deploy/proxy-load-balancer?view=aspnetcore-5.0#troubleshoot to capture the incoming headers.

Please share your forwarded headers middleware settings along with the troubleshooting output.

[TaylorTheDeveloper]

Thanks @Tratcher for pointing me in this direction- Going through this more in depth and adding logging around the scenario I finally figure out what's going on. The middleware doesn't seem to be doing that update as the documentation seems to indicate it would. I was able to update the request host to be the correct endpoint manually using the X-Forwarded-Host header (see below)

according to the documentation:

The Forwarded Headers Middleware (ForwardedHeadersMiddleware), reads these headers and fills in the associated fields on HttpContext.

The middleware updates:

HttpContext.Connection.RemoteIpAddress: Set using the X-Forwarded-For header value. Additional settings influence how the middleware sets RemoteIpAddress. For details, see the Forwarded Headers Middleware options.
HttpContext.Request.Scheme: Set using the X-Forwarded-Proto header value.
HttpContext.Request.Host: Set using the X-Forwarded-Host header value.

My forwarded header configuration in ConfigureServices:

services.Configure<ForwardedHeadersOptions>(options =>
            {
                options.ForwardedHeaders = ForwardedHeaders.All;
            });

Simply called in Configure:
app.UseForwardedHeaders();

Here's what I observed logging the headers (minified):
(from my azure front door endpoint)

Start Request Host: [Host] mysite-ppe.azurewebsites.net 
Header: X-Forwarded-Proto:https
Header: X-Forwarded-TlsVersion:1.2
Header: X-Forwarded-Host: mysite-ppe.azurefd.net
Header: ...*other headers*...
End Request Host: [Host] mysite-ppe.azurewebsites.net

I inspected further and found that my context.Request.Host was not being updated to the X-Forwarded-Host value. I updated my middleware to update that for each request after checking that the header has been set. From the docs, I'd think the middleware would handle it for me. Is this expected that I still have to update the request host? I do see the correct behavior now on my site with below changes, and I can log in at the front door endpoint.

if (context.Request.Headers.ContainsKey("X-Forwarded-Host"))
{
    context.Request.Host = new HostString(context.Request.Headers["X-Forwarded-Host"][0]);
}

Here's what the flow looks like after making this update:
(from my azure front door endpoint)

Start Request Host: [Host] mysite-ppe.azurewebsites.net 
Header: X-Forwarded-Proto:https
Header: X-Forwarded-TlsVersion:1.2
Header: X-Forwarded-Host: mysite-ppe.azurefd.net
Header: ...*other headers*...
Found X-Forwarded-Host: Request Host: [Host] mysite-ppe.azurefd.net
End Request Host: [Host] mysite-ppe.azurefd.net 

[TaylorTheDeveloper]

Just wanted to follow up... Is this expected that I still have to update the request host? Or is this a bug?

[Tratcher]

Do your requests have x-forwarded-for headers? A lot of the processing is tied to those. You can try disabling that with:
options.ForwardedHeaders = ForwardedHeaders.XForwardedHost | ForwardedHeaders.XForwardedProto;

[TaylorTheDeveloper]

Ahh, that was it. I did have x-forwarded-for headers as well. Opting for just XForwardedHost + XForwardedProto did the trick without requiring me to override anything. Thanks!