Authentication.AzureAD.UI: Incorrectly uses http instead of https in redirect URI

[SeanKilleen]

Describe the bug

I believe this issue is similar to AzureAD/microsoft-identity-web#115 and the fixes/workarounds may also be the same.

When deploying in a Linux container, the URI for redirects utilizes http even when my site is hosted via https. This prevents me from being able to utilize Azure AD's redirect, which requires https, and thus does not allow logging in from my application. Instead I receive:

AADSTS50011: The reply URL specified in the request does not match the reply URLs configured for the application

I've tried the workaround of adding an AzureAd__RedirectUri app setting, but this does not appear to have any effect and I believe it may apply only to Microsoft.Identity.Web and not this project (unsure exactly how those are related)

To Reproduce

Repo with this issue: https://github.com/excellalabs/konmaripo

• Create a .NET Core 3.1 MVC web app in Visual Studio, enabling Azure AD auth for a single org and Docker support for Linux containers.
• Deploy to an Azure Web App for Containers (hosted over https)
• Add the URL (with an https) to your redirect URI list.

Expected behavior: When accessing the site, I am redirected to Azure with a redirect URI of https (which is allowed), and thus logged in and redirect back to my app.

Actual behavior: I am taken to the Azure login, but with a redirect URL of http instead of https, leading me to receive an error of:

AADSTS50011: The reply URL specified in the request does not match the reply URLs configured for the application

Exceptions (if any)

Further technical details

• ASP.NET Core version 3.1
• Library: Microsoft.AspNetCore.Authentication.AzureAD.UI
• Library Version: 3.1.4
• IDE: Not applicable, as it is a linux container running in Azure that has the issue

[blowdart]

Have you configured the header forwarding middleware?

Inside the container it's likely that your app is listening on HTTP, and Azure is terminating the HTTPS at the load balancer before forwarding the requests onward.

[SeanKilleen]

@blowdart thanks for jumping in!

I took a stab at doing that here: https://github.com/excellalabs/konmaripo/pull/11/files

Was not successful but willing to bet that it's because I'm getting something wrong. Continuing to research ways to approach it.

[SeanKilleen]

@blowdart just to confirm -- there is no RedirectUri config setting within this library that will be respected, as in the case of Microsoft.Identity.Web I've linked above, correct? Not a problem either way, I just want to make sure that workaround isn't available before I go this route.

[blowdart]

We try to autodetect the protocol, and honestly because the protocol can affect other things like cookie settings it's better to get the header forwarding working.

I'd suggest creating a page that dumps all the inbound headers on a request and making sure that the expected X-Forward-* headers are there. I haven't used Azure's containers myself, but I'd bet that instead of one proxy host as you'd see in a web application there is in fact two, the ARR level that sits in front of everything, and then the container host, so you'd need to adjust the middleware to trust two proxies, rather than the default one, and potentially add a known proxy address, something like

services.Configure<ForwardedHeadersOptions>(options =>
{
    options.ForwardLimit = 2;
    options.KnownProxies.Add(IPAddress.Parse("127.0.10.1"));
});

If you can share the X-Forwarded headers then one of the middleware folks should be able to give advice when they wake up :)

[SeanKilleen]

The header forwarding may have indeed resolved it; turns out it helps if you actually call app.UseForwardedHeaders(); 😆

I'll report back either way and will include the additional info if we need to go that route.

@blowdart this seems like it's worth raising an issue to the VS templating team about because this is my out of the box experience specifically when checking the boxes for Azure AD and docker support. Do you see any reason why I shouldn't raise that issue?

[blowdart]

Oh yes, definitely, if there's a docker template and checkboxes the template should wire it up.

Glad you got it working, I was desperately trying to figure out docker over my first morning coffee and it wasn't going well.

[SeanKilleen]

Update: it definitely did resolve things. I also had to disable the auth from within the Azure AD portal since we were wiring it up directly (I'd enabled it during troubleshooting.)

I was desperately trying to figure out docker over my first morning coffee and it wasn't going well.

Thar be dragons. :)

Thanks again for the help! I'll see if I can find a place to raise the follow-up issue, but for now, we can consider this closed.