[Bug] Blazor VS template fails on ARC for App Services as the redirect URI is http not https

[snapfisher]

Microsoft.Identity.Web Library

Microsoft.Identity.Web

Microsoft.Identity.Web version

1.25.1

Web app

Sign-in users

Web API

Not Applicable

Token cache serialization

In-memory caches

Description

I have a Blazor server app, created with the Visual Studio template (recent -- about 30 - 45 days ago), and it authenticates to AAD.

This works fine when deployed to a Windows Azure App Service, .Net 6 This works fine when deployed to a Linux Azure App Service, .Net 6

Both of the above with identical code.

When deploying to an app service created on the Azure Arc preview, the redirect URI is http not https, so login fails.

Reproduction steps

1. the CallbackPath appsetting in the app is "/signin-oidc".
2. the authentication part of ConfigureServices is:

var initialScopes = Configuration.GetValue<string>("DownstreamApi:Scopes")?.Split(' ');

services.AddAuthentication(OpenIdConnectDefaults.AuthenticationScheme)
    .AddMicrosoftIdentityWebApp(Configuration.GetSection("AzureAd"))
        .EnableTokenAcquisitionToCallDownstreamApi(initialScopes)
            .AddMicrosoftGraph(Configuration.GetSection("DownstreamApi"))
            .AddInMemoryTokenCaches();
services.AddControllersWithViews()
    .AddMicrosoftIdentityUI();

I have been changing the redirect URI in the azure portal for the correct domain name. I tried modifying the manifest to force the configured URIs to http, but I received a security error, so that is no longer allowed.

Error message

AADSTS50011: The redirect URI 'http://xxx.eastus.k4apps.io/signin-oidc' specified in the request does not match the redirect URIs configured for the application

Id Web logs

No response

Relevant code snippets

See reproduction steps

Regression

No response

Expected behavior

I should be able to log in with the same code as I do for the actual app service (windows and linux).

[jmprieur]

@snapfisher : did you see https://github.com/AzureAD/microsoft-identity-web/wiki/Deploying-Web-apps-to-App-services-as-Linux-containers ?

[snapfisher]

@jmprieur : I did not, but looking at it now. I was not using containers, but -- is ARC for App Services creating a container automagically in ARC when publishing directly from Visual Studio? I have no idea. If I can get this working with these instructions, I think I'm going to file a ticket with them, that they are not consistent, i.e. apps should deploy identical to ARC as they do to the app service, and this deploys to a Linux App Service with no issues. If I can't get it to work, then I don't really know. Trying now....

[snapfisher]

@jmprieur : That has no effect, which makes sense since the write up seems to imply, "fixed in .net Core 3.0". The only oddity I see, is that when I create the publishing profile in Visual Studio, for my linux app service it says that the site is "https://xxx", which for the ARC linux app service it says that the site is "http://xxx", even though the app service is set to https only. I can manually change the xml of the publishing profile, but that has no effect. So....I'm not sure. Do you think this bug would be better to be resubmitted to https://github.com/dotnet/aspnetcore?

[jmprieur]

Thanks for investigating, @snapfisher @Tratcher what would you recommend?

[Tratcher]

Try setting the environment variable ASPNETCORE_FORWARDEDHEADERS_ENABLED=true on your service. This is something we do by default in the Asp.Net Core container image, but it might not be happening in the ARC containers.

More background: https://docs.microsoft.com/en-us/aspnet/core/host-and-deploy/proxy-load-balancer?view=aspnetcore-6.0#forward-the-scheme-for-linux-and-non-iis-reverse-proxies

[snapfisher]

That has no effect.

Just so you can double check me....

       public void ConfigureServices(IServiceCollection services)
       {
           var initialScopes = Configuration.GetValue<string>("DownstreamApi:Scopes")?.Split(' ');

           services.AddAuthentication(OpenIdConnectDefaults.AuthenticationScheme)
               .AddMicrosoftIdentityWebApp(Configuration.GetSection("AzureAd"))
                   .EnableTokenAcquisitionToCallDownstreamApi(initialScopes)
                       .AddMicrosoftGraph(Configuration.GetSection("DownstreamApi"))
                       .AddInMemoryTokenCaches();
           services.AddControllersWithViews()
               .AddMicrosoftIdentityUI();

           services.AddAuthorization(options =>
           {
               // By default, all incoming requests will be authorized according to the default policy
               options.FallbackPolicy = options.DefaultPolicy;
           });

           services.AddRazorPages();

           Environment.SetEnvironmentVariable("ASPNETCORE_FORWARDEDHEADERS_ENABLED", "true");

           services.Configure<ForwardedHeadersOptions>(options =>
           {
               options.ForwardedHeaders =
                   ForwardedHeaders.XForwardedFor | ForwardedHeaders.XForwardedProto;
               options.KnownNetworks.Clear();
               options.KnownProxies.Clear();
           });

          //other stuff follows

       }

       public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
       {
           app.UseForwardedHeaders();

          //other stuff follows
         

[snapfisher]

I also tried it only setting the environment variable, but making no other changes. That had no effect, either.

[Tratcher]

That variable would need to get set at the start of Program.Main before creating the host.

Try the troubleshooting steps at the bottom: https://docs.microsoft.com/en-us/aspnet/core/host-and-deploy/proxy-load-balancer?view=aspnetcore-6.0#troubleshoot

[snapfisher]

When I do this -- and I put the env variable set as the very first thing in main, there is no change. I did get logging working. I never see an X-Forwarded-Proto header, and the X-Original-Proto header is always "http". I do see the X-Forwarded-For header, but not the proto header.

If I understood the documentation correctly, I should see an X-Forwarded-Proto header that says "https", which then gets copied to the X-Original-Proto header, yes?

[Tratcher]

Interesting, it sounds like the middleware is running and getting you those x-original-* headers. Disable the middleware and confirm you get x-forwarded-proto: http. This might be an ARC infrastructure issue.

[snapfisher]

I can't seem to get the x-forward-proto header to display, so I went back to the actual linux app service, which runs correctly and don't see it there either. I don't know why I can't see it, but the second one is working, with the middleware off, as it was originally. The really interesting thing is that it also has X-Original-Proto: http. So, I'm back to...it's just broke, as from the logs there is no difference between the two.

[snapfisher]

Could it be looking for a different environment variable?