Current setup for docker-compose does not function correctly with AzureAd turned on

[agileramblings]

Describe the bug

When enabling AzureAd and filling in the required configuration values, External Login goes to AAD login pages, completes authentication, then when returning to complete logging into the STS app, the page simply goes to the login page again. (https://sts.skoruba.local/Account/Login) The AAD cookie is present so clicking on the OpenIdConnect button over and over causes the app to continuously return to the https://sts.skoruba.local/Account/Login page without requiring further AAD authentication steps.

Local logins work as expected.

To Reproduce

1. Get latest template - dotnet new -i Skoruba.IdentityServer4.Admin.Templates::2.0.1
2. Create solution using latest template - dotnet new skoruba.is4admin --name MyProject --title MyProject --adminemail "[email protected]" --adminpassword "Pa$$word123" --adminrole MyRole --adminclientid MyClientId --adminclientsecret MyClientSecret --dockersupport true
3. Make certs as per https://github.com/skoruba/IdentityServer4.Admin#mkcert
4. Create DNS entries (hosts file or PiHole)
5. Configure AAD in appsettings.json as per https://github.com/skoruba/IdentityServer4.Admin#how-to-configure-an-external-provider-in-sts
6. Run docker-compose as per https://github.com/skoruba/IdentityServer4.Admin#run-docker-compose
7. Browse to https://sts.skoruba.local and login via OpenIdConnect option
8. Complete AAD login to return to STS page.

Relevant parts of the log file

Watching log file, there are no errors/warnings. Setting a break-point at ~ln 384 of AccountController.cs shows that var info = await _signInManager.GetExternalLoginInfoAsync(); returns null for an unknown reason.

[agileramblings]

Looking in Fiddler at a version of Skoruba that works (pre-v1 instance)

and the v2 instance

I don't understand why the cookies are different. Both are pointing at the same AAD instance.

These are the URLs in Fiddler back-to-back

[agileramblings]

I've made this work, but I suspect there is a better way.

I noticed that the fist call after Account/ExternalLogin? was different between the two sites. The current v2 of Skoruba called:

but the previous version called...

Switching off "UseAzureAdProvider": false, and inserting

            var authenticationBuilder = services.AddAuthentication()
                .AddOpenIdConnect("OpenIdConnect", "Login with Azure AD (O365)", options =>
            {
                options.Authority = $"https://login.microsoftonline.com/common";
                options.TokenValidationParameters =
                    new TokenValidationParameters { ValidateIssuer = false };
                options.ClientId = "<snipped>";
                options.ClientSecret = "<snipped>";
                options.CallbackPath = "/signin-oidc";
                options.Scope.Add("user:email");
            });

Resolved the problem with being unable to log into the STS.

[ielcoro]

I solved by following the advice from Microsoft Identity Web library, with the latest version to make Identity with AzureAAD or any other Microsoft Identity protected auth system, you need to set cookieScheme parameter to null:

if (externalProviderConfiguration.UseAzureAdProvider)
            {
                authenticationBuilder.AddMicrosoftIdentityWebApp(options =>
                {
                    options.ClientSecret = externalProviderConfiguration.AzureAdSecret;
                    options.ClientId = externalProviderConfiguration.AzureAdClientId;
                    options.TenantId = externalProviderConfiguration.AzureAdTenantId;
                    options.Instance = externalProviderConfiguration.AzureInstance;
                    options.Domain = externalProviderConfiguration.AzureDomain;
                    options.CallbackPath = externalProviderConfiguration.AzureAdCallbackPath;
                },  cookieScheme: null);
            }

[skoruba]

Thanks for reporting this and for PR as well. 👍