Thread.CurrentPrincipal is not persisted in .Net Core 3.1

[andreyciocan]

Hello!

I am having an issue with Thread.CurrentPrincipal after migrating from .Net Core 2.2 to .Net Core 3.1

I am setting my Thread.CurrentPrincipal in a Custom Authorization Handler like this:
`
var claims = new List {
new Claim("CustomIdClaim", <user_id>),
new Claim(ClaimTypes.Name, <user_name>)
};

        Thread.CurrentPrincipal = new ClaimsPrincipal(new ClaimsIdentity(claims)); 

`
and then I am trying to get Thread.CurrentPrincipal in a static method initialized in Startup class like this:

var principal = (ClaimsPrincipal)Thread.CurrentPrincipal;
.

The problem is that in the static method, Thread.CurrentPrincipal is always null. I must mention that my custom authorization handler is called before the static method on every request.

This worked just fine with .Net Core 2.2.

Thanks in advance!

[jkotas]

This should be fixed by #32104 for .NET Core 3.1.3 update. Could you please try to update to .NET Core 3.1.3 and see whether the problem is fixed?

[jkotas]

https://dotnet.microsoft.com/download/dotnet-core/3.1

[andreyciocan]

Hi! Unfortunately it is not fixed for me. I was already using .NET core 3.1.3 SDK

I tried also to set the sdk version in a global.json to make sure that the correct sdk is used. Same result...

[andreyciocan]

Found this Guide on oficial Microsoft documentation: https://docs.microsoft.com/en-us/aspnet/core/migration/claimsprincipal-current?view=aspnetcore-3.1
The workaround worked just fine for me.

But how come that my old aproach worked on .net Core 2.2 and is not working anymore on 3.1.3? Maybe there is a bug after all?

[jkotas]

#28365 made the current principal flow with async operations for better compatibility with .NET Framework. It is likely why you see the behavior change. The place where you are setting the principal and where you are reading the principal are likely running in different execution contexts. We would need to see the full repro to tell for sure - the details matter when it comes to flowing execution contexts.

[andreyciocan]

My project is huge, so I can't post a repo here. But I am sure that I am using a single thread for setting and readint the Thread.CurrentPrincipal. As I said, everything was fine before updating to .Net Core 3.1.

[jkotas]

The execution contexts can switch on a single thread. You can be on a single thread and still run in different execution contexts at different points.

Here is an example:

using System;
using System.Security.Principal;
using System.Threading;

class MyPrincipal : IPrincipal
{
    public IIdentity Identity => throw new NotImplementedException();
    public bool IsInRole(string role) => throw new NotImplementedException();
}

class Program
{
    static void Log() =>
        Console.WriteLine($"Thread {Thread.CurrentThread.ManagedThreadId} CurrentPrincipal {Thread.CurrentPrincipal}");

    static void Main(string[] args)
    {
        Thread.CurrentPrincipal = null;
        Log();

        ExecutionContext capturedContext = ExecutionContext.Capture();

        Thread.CurrentPrincipal = new MyPrincipal();
        Log();

        ExecutionContext.Run(capturedContext, (o) => Log(), null);
    }
}

On .NET Core 2.1, this program prints:

Thread 1 CurrentPrincipal
Thread 1 CurrentPrincipal MyPrincipal
Thread 1 CurrentPrincipal MyPrincipal

On .NET Core 3.x, for better compatibility with .NET Framework, this program prints :

Thread 1 CurrentPrincipal
Thread 1 CurrentPrincipal MyPrincipal
Thread 1 CurrentPrincipal

There is something similar probably happening in your app. The execution context is likely switched by ASP.NET, not directly by your app.

These sort of issues are the reason why ASP.NET Core guidelines discourage use CurrentPrincipal:

https://docs.microsoft.com/en-us/aspnet/core/migration/claimsprincipal-current?view=aspnetcore-3.1
aspnet/Security#322

[andreyciocan]

You are right. It was not the cleaner approach to use CurrentPrincipal at all. Injecting IHttpContextAccessor looks like a cleaner way to pass information to a static method.

I think we can close this issue.

Thank you for your support!