Thread.CurrentPrincipal was useful - alternatives?

[Plasma]

Hey,

I realise ASP.NET Core has switched to a different identity model and Thread.CurrentPrincipal is obsolete. I’m otherwise an avid user of DI.

I’m finding the new system to be a bit cumbersome, here are some issues:

1. The controller User object is a ClaimsPrincipal, which has an Id claim to represent my user, but I’d like to automatically have a complex user object constructed from the database for callers to interact with.

I’ve achieved this by instead injecting IUserSession service I made that has a User property, and this interface uses HttpContextAccessor to grab the principal Id claim and load a User object from the database.

2. This feels a little awkward though, because most services and repositories want to know the user context, injecting it everywhere can bring some circular dependencies, as it depends on some of those same repositories to load itself.

3. I wish I could initialise the User object right after .Net Core has loaded the cookie and claims to inspect. This may help the circular dependency issue by making it a simple property I’m setting before the request is properly processed.

4. Temporarily impersonating another user within a method (not a full request) becomes more difficult, because temporarily changing the injected IUserSession.User property feels wrong, as it makes all code paths even outside of the current execution context that have injected this service see a different principal user temporarily, rather than just the code I’m about to invoke.

In the past, a temporary change in Thread.CurrentPrincipal would flow properly and feel very natural:

// this is an overly simple example

// operate as current user context
DoSomething();

// switch user context to otherUser
using(userService.Impersonate(otherUser))
    DoSomething();

// back to current user 
DoSomething();

// methods
void DoSomething()
{
    // code below checks security by inspecting current code user context using Thread.CurrentPrincipal
    _otherServiceThatChecksPrincipal.DoStuff();

}
‘’’

4. Is there any post-auth point I can set Thread.CurrentPrincipal to my hydrated User object? Or at least set IUserSession.User property. Just a place where the pipeline has loaded the .net core ClaimsPrincipal and is about to run controller actions but just before that, to initialise the IUserSession.User object (so it needs no dependencies to load it itself).

In legacy framework MVC both would be set in OnPostAuthenticateRequesr for example.

 .NET Core seems to be clearing Thread.CurrentPrincipal when I try and set it in the ValidatePrincipal
method in CookieAuthenticationEvents callback for example.

Thank you

[Ariansh]

as far as I understood, you dont want to use the default written package. so i skip this.
but to use an object globaly in your application and not injecting it multiple times, i suggest you use it in your MainLayout and pass it to its child components using CascadingParamenters.

[blowdart]

Thread.Current falls apart in multi-threading and async scenarios and history has shown relying on it has lead to security vulnerabilities. So, it's gone away and forcing you to flow a user provides a safer framework for user security.

Is there any post-auth point I can set Thread.CurrentPrincipal to my hydrated User object?

This seems to be your key problem. You can either enhance it during login, before its persisted, or, with utter sadness, you can do it on every request, which doesn't scale, because now you have database queries on every request.

How you enhance depends on how you're logging in. Identity you can do in code for the login (and then inside the cooke refresh) but claims transformation is probably the most portable.

Impersonation is a loaded term, and so it really depends on how you are using and sending identities off to other components or systems.

[kevinchalet]

FWIW, Thread.CurrentPrincipal is backed by an AsyncLocal<IPrincipal> instance on .NET Core, so it will work nicely with async/await and context switching: https://source.dot.net/#System.Private.CoreLib/Thread.cs,137

With that in mind, you can write a middleware registered after the authentication middleware that sets it for the rest of the request. You could also use ClaimsPrincipal.Current and set ClaimsPrincipal.ClaimsPrincipalSelector to resolve it from wherever you want.

Something like:

app.UseAuthentication();
app.UseAuthorization();

app.Use(next => async context =>
{
    var principal = Thread.CurrentPrincipal;

    // Use the principal resolved from the default authentication scheme handler.
    // You can also use context.AuthenticateAsync("scheme") to pick a different principal.
    Thread.CurrentPrincipal = context.User;

    try
    {
        await next(context);
    }
    finally
    {
        Thread.CurrentPrincipal = principal;
    }
});

[rajatchanana7]

Really thanks, context.user really help me to get value in my api what i set in Thread.CurrentPrincipal in other class library.