Undocumented breaking change 2.2 -> 3.1? How to get Windows user name in 3.1 (AuthorizationHandler)?

[lesscodetxm]

We're migrating some 2.2 APIs to 3.1. We have an external service that provides user role information, and we're calling it from a custom AuthorizationHandler, passing in the name of the Windows domain user, eg:

protected override Task HandleRequirementAsync(AuthorizationHandlerContext context, ClientRoleRequirement requirement) {
    var roles = _roleServer.GetRoles(context.User.Identity.Name);
    ...
}

In 2.2, context.User.Identity is a System.Security.Principal.WindowsIdentity, with a Name for the user.
In 3.1 context.User.Identity is a System.Security.Claims.ClaimsIdentity, and its Name is null.

What did we screw up in the migration?

[lesscodetxm]

Never mind. The behavior change appears to be affected by launchSettings.json:

"anonymousAuthentication": false,

We've had this set to true in 2.2 with no ill effects. I had to force it to false to get access to the Windows identity inside the AuthorizationHandler.

[lesscodetxm]

It turns out that this is not the full answer, since it also obviously prevents [AllowAnonymous] endpoints from working.

[lesscodetxm]

Looking into this further, our API has both authenticated and anonymous endpoints. We apply [Authorize] attributes where (Windows) authentication is requred, and [AllowAnonymous] where auth is not required. In launch settings we set both anonymousAuthentication and windowsAuthentication to true. This has been working fine in 2.2

In 3.1 it seems that if anonymousAuthentication is true, no claims are being passed through into the context for any request (not just the ones marked [AllowAnonymous]).

Did this behavior change deliberately? Is there a workaround?

[lesscodetxm]

I was able to confirm the different behaviour in a pair of brand new projects, one for 2.2 and one for 3.1

Interestingly, I can replicate the 3.1 behaviour (no WindowsIdentity in the AuthorizationHandlerContext) in the 2.2 project by making the following change in ConfigureServices:

services.AddMvc();

becomes:

services.AddMvc().SetCompatibilityVersion(CompatibilityVersion.Version_2_2); // Latest also breaks it

I tried calling SetCompatibilityVersion in the 3.1 project and no option gives me a WindowsIdentity in the AuthorizationHandlerContext.

[Tratcher]

https://docs.microsoft.com/en-us/aspnet/core/security/authentication/windowsauth?view=aspnetcore-3.1&tabs=visual-studio#iisiis-express

services.AddAuthentication(IISDefaults.AuthenticationScheme);

In 2.2 were you using IIS in-proc or out-of-proc?
#7750

[lesscodetxm]

We have the AddAuthentication call you mention. We are not specifying a hosting model in the project file (in-proc is the default?)

[Tratcher]

Out-of-proc was the default in 2.2, in proc is the default in 3.x, which probably has a lot to do with the change of the behavior.

[lesscodetxm]

So, I tried making the 2.2 project InProcess, and it still works.
I tried making the 3.1 project OutOfProcess, and it still fails.

[lesscodetxm]

I attached the two repro projects below, BTW. If you can point out what we should do in 3.1 to get back to the 2.2 behaviour, I'd appreciate it.

[lesscodetxm]

repro.zip

[Tratcher]

Neither your 2.2 or 3.1 example work for me unless I comment out the line [Authorize(Policy = "Client", Roles = "God")].

[Tratcher]

@HaoK any thoughts on the "Client" authz policy in these repro apps?

[lesscodetxm]

@Tratcher the AuthorizationHandler is probably assuming you're in an AD domain - there's logic to split off the domain part. That may be why it's failing for you. Commenting out the policy will bypass the custom handler completely.

[lesscodetxm]

To clarify, the key to this issue is that the custom authorization handler does not receive a WindowsIdentity in the context in 3.1, where it did in 2.2.

[lesscodetxm]

The only way I've been able to work around this is by implementing custom middleware to issue a Windows auth challenge explicitly if the route hit is not marked [AllowAnonymous].

It's based on Alexei's answer here:

https://stackoverflow.com/questions/44778600/enable-both-windows-authentication-and-anonymous-authentication-in-an-asp-net-co

But it involves basically enumerating all of the [AllowAnonymous] routes and then manually trying to match them on every request, so it's horribly inefficient.

[lesscodetxm]

@Tratcher @HaoK Anything else I'm missing here? This is the last thing holding up our migration to 3.1
Any insights or advice appreciated.

[HaoK]

We took a look and we didn't see any behavior differences in 2.2 or 3.1, but we needed to add a fast fail for when the request wasn't authenticated at the top of the authorization handler:

            if (!context.User.Identity.IsAuthenticated)
            {
                context.Fail();
                return Task.CompletedTask;
            }

That made things work as we expected

[lesscodetxm]

[In other words, we must have never been seeing the first (anonymous) call before]

[Tratcher]

Your repro doesn't reflect that, we see the same issue in the 2.2 version. How does your repro differ from your old app?

[lesscodetxm]

Hmm. I just ran my 2.2 app again and I'm still seeing the WindowsIdentity on the first call. Let me take another look at what I sent you.

[lesscodetxm]

The difference may be here:

            services.AddMvc().SetCompatibilityVersion(CompatibilityVersion.Latest);

When I comment out the SetCompatibilityVersion() call I don't get the first (unauthenticated) call in 2.2. I do in 3.1.

[Tratcher]

@HaoK is there something quirked in the 2.2 MVC auth filters?