[Bug] Redirect URI is set to http instead of https when deploying to Azure App Service for Docker container (Linux)

[mochr]

Which Version of Microsoft Identity Web are you using ?
Microsoft Identity Web 1.0.0-preview

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;
Probably valid for most cases.

Is this a new or existing app?

This is an experiment to test an app with Microsoft.Identity.Web deployed to Azure App Service for Docker Containers.

Repro

1. Open example 1-2-AnyOrg
2. Add Docker support in Visual Studio (create standard Dockerfile)
3. Build image
4. Publish to container registry
5. Create a new App Service using the container image
6. Add configuration
7. Browse new web app, and you will be redirected to login.microsoftonline.com as expected, but with redirect_uri=http%3A%2F%2F<your app service name>.azurewebsites.net%2Fsignin-oidc instead of redirect_uri=https%3A%2F%2F<your app service name>.azurewebsites.net%2Fsignin-oidc .
8. Manually changing the redirect URI to HTTPS will enable authentication and the app will work as expected.

Expected behavior
Expected to be redirected to the HTTPS-page.

Actual behavior
Error AADSTS50011 is shown in the browser, as there is a mismatch between registered redirect-URIs.

Possible Solution
Maybe there is a way to configure the App Service to avoid this issue? Or is there a way to configure Microsoft.Identity.Web to use HTTPS in the redirect URI?

Additional context/ Logs / Screenshots
The application log shows the following:
Microsoft.AspNetCore.HttpsPolicy.HttpsRedirectionMiddleware[3]: Failed to determine the https port for redirect.

There is a hint here that SSL should not be enabled in the web app, but how is it possible to not have SSL enabled in the web app, but still have HTTPS in the redirect URI?

[BurritoSmith]

I'm seeing the same behavior using example 1-1, deployed to a regular Azure App Service (not docker). Reply urls in azure are set to https, "domain" in the appsettings.json is set to https, but when I try to use the login mechanism, it's passing http as my reply url. Works fine in localhost while debugging.

[jmprieur]

@BurritoSmith : did you add the right redirect URIs (with https:) in the app registration for your application?

[jmprieur]

Spec

(updated on 07/05/2020)

Why?

In order to avoid customers to have to update the redirect URI in the code when they deploy their Web apps, the redirect URI is computed automatically by ASP.NET Core (part of the auth code flow), and also by Microsoft.Identity.Web (in TokenAcquisition.BuildConfidentialClientApplicationAsync).

Note that this does not prevent developers to add redirect URI in the app registration portal, but this allow them to have the same code for debugging locally and for deployed applications if they wish to.

The MSAL.NET part is here:

microsoft-identity-web/src/Microsoft.Identity.Web/TokenAcquisition.cs

Lines 334 to 338 in c2f81fd

	string currentUri = UriHelper.BuildAbsolute(
	request.Scheme,
	request.Host,
	request.PathBase,
	_microsoftIdentityOptions.CallbackPath.Value ?? string.Empty);

Although this solves many cases, there are cases (like working in containers, or with reverse proxys), where this is not flexible enough

The openIDConnect redirect URI is computed by ASP.NET Core, but can be overriden by subscribing to the OpenIdConnect OnRedirectToIdentityProvider event and by setting the context.ProtocolMessage.RedirectUri property to the desired redirect URI.

Same problem for the post logout redirect URI used in global sign-out. It needs to be overridable, and that can be done but subscribing to the OnRedirectToIdentityProviderForSignOut openIdConnect event and setting the context.ProtocolMessage.PostLogoutRedirectUri property.

What?

Given the following config

  "CallbackPath": "/signin-oidc",
   "SignedOutCallbackPath ": "/signout-callback-oidc",

The proposal is to add new properties in MicrosoftIdentityOptions to override the redirect URI and the post logout redirect URI:

• Add RedirectUri in MicrosoftIdentityOptions
• Add PostLogoutRedirectUri in MicrosoftIdentityOptions

Given the following config

//  "CallbackPath": "/signin-oidc",
//   "SignedOutCallbackPath ": "/signout-callback-oidc",
  "RedirectUri ": "http://mywebapp.mycompany.com/signin-oidc",
   "PostLogoutRedirectUri": "http://mywebapp.mycompany.com/signout-callback-oidc",

• Use these properties in the AddSignIn method:

microsoft-identity-web/src/Microsoft.Identity.Web/WebAppAuthenticationBuilderExtensions.cs

Lines 62 to 68 in 2739123

	public static AuthenticationBuilder AddSignIn(
	this AuthenticationBuilder builder,
	Action<OpenIdConnectOptions> configureOpenIdConnectOptions,
	Action<MicrosoftIdentityOptions> configureMicrosoftIdentityOptions,
	string openIdConnectScheme = OpenIdConnectDefaults.AuthenticationScheme,
	string cookieScheme = CookieAuthenticationDefaults.AuthenticationScheme,
	bool subscribeToOpenIdConnectMiddlewareDiagnosticsEvents = false)

In the builder.AddOpenIdConnect(openIdConnectScheme, options => { bloc:

            var redirectToIdpHandler = options.Events.OnRedirectToIdentityProvider;
            options.Events.OnRedirectToIdentityProvider = async context =>
            {
                // Call what Microsoft.Identity.Web is doing
                await redirectToIdpHandler(context);
                // Override the redirect URI to be what you want
                if(microsoftIdentityOptions.RedirectUri != null)
                {
                    context.ProtocolMessage.RedirectUri = (microsoftIdentityOptions.RedirectUri;
                }
            };
            var redirectToIdpForSignOutHandler = options.Events.OnRedirectToIdentityProviderForSignOut;
            options.Events.OnRedirectToIdentityProviderForSignOut = async context =>
            {
                // Call what Microsoft.Identity.Web is doing
                await redirectToIdpForSignOutHandler(context);
                // Override the redirect URI to be what you want
                if (microsoftIdentityOptions.PostLogoutRedirectUri )
                {
                    context.ProtocolMessage.PostLogoutRedirectUri = microsoftIdentityOptions.PostLogoutRedirectUri;
                }
            };
        });

__
@jennyf19 @pmaytak @bgavrilMS @henrik-me : what do you think?

[BurritoSmith]

@jmprieur yes, the redirect URIs in the app registration are set to https. I actually mis-informed you yesterday when I said my app was hosted on azure (it was late in the day and I was tired and confused about which particular one this was....). This particular app is an internal one that is hosted behind a load balancer. The nodes host the application on http using ports to separate each application in IIS but the load balancer accepts https traffic then forwards that on to the nodes over http. So in this model the nodes seem to be checking themselves and determining that they are being hosted over http and therefore changing the reply url that gets passed up accordingly. I haven't sniffed the traffic out, but it's possible that in the flow, they're actually passing the machine name that's hosting them rather than the host.domain name we're using to reach our LB. IE http://mymachinename:44200 instead of https://myhost.mydomain.com. I have seen a few different errors from the MS login about mismatched reply URLs when the machine names are not included.

In any case, being able to override the behavior you described above would be a must for our situation. We can not rely on our machines accurately obtaining a computed return URL. I assumed that it was using the "domain" property in the JSON config as the reply url. To me, you could use that in conjuction with the signin-oidc, or just add another property in the json config for us to manipulate what the reply url should be.

[jmprieur]

Thanks for the explanation @BurritoSmith .
and for confirming that the spec above would work for you!

yes, we would use the CallbackPath JSON property:

microsoft-identity-web/tests/WebAppCallsWebApiCallsGraph/Client/appsettings.json

Line 7 in 813844b

"CallbackPath": "/signin-oidc",

[mochr]

So am I understanding it correct that the property will be set to the following?

"CallbackPath": "https://<app_name>.azurewebsites.net/signin-oidc"

That would be perfect for me, and also having the possibility to not specify the full path for local development.

[BurritoSmith]

I had a little bit of time this morning to play around with trying to manually add the return URI into the process. I was working with the file you mention above @jmprieur (microsoft-identity-web/src/Microsoft.Identity.Web/TokenAcquisition.cs) and wasn't able to get it to inject my return URI into the MS Login GET request with the querystring parameter set to my manual override. There is obviously something else going on deeper in the plumbing that I didn't dig into. Just for the heck of it, I also tried updating the CallbackPath property now to an absolute URI and that did not work (as I wouldn't expect it to since this hasn't been implemented in my current version) but it did throw an exception as it was not able to be parsed.

Please let us know when you've implemented your suggested changes so I can come back to this in my project. For now, I've had to roll back to an older version of our OpenID authentication process.

thanks so much.

[jmprieur]

@BurritoSmith, we have prioritized fixing this issue (cc: @jennyf19)
Meanwhile, do you want to try the following (in your startup.cs) ?

 public void ConfigureServices(IServiceCollection services)
 {
  services.AddSignIn(Configuration);
  services.Configure<OpenIdConnectOptions>(OpenIdConnectDefaults.AuthenticationScheme, 
                                         options => {
 
     var redirectToIdpHandler = options.Events.OnRedirectToIdentityProvider;
     options.Events.OnRedirectToIdentityProvider = async context =>
     {
      // Call what Microsoft.Identity.Web is doing
      await redirectToIdpHandler(context);

     // Override the redirect URI to be what you want
     context.ProtocolMessage.RedirectUri = "your redirect URI";
    };
   });

 // More code here ...
}

[mochr]

I tested this solution, and it works for sign-in 👍 The sign-out redirect URI (post_logout_redirect_uri) is still http though. You can test the app at https://demoopenid.azurewebsites.net/.