Making HttpContext.User available to 3rd party code without Microsoft.AspNetCore.Http dependency

Background and Motivation

On AspNetCore, when you need to access the HttpContext in a "service" class, you use an IHttpContextAccessor to get the thread-safe instance of the HttpContext used by the current thread, thanks to its internal use of AsyncLocal.

However, if you need to be able to access the HttpContext.User, AND the service class is in another assembly, you can no longer rely on ClaimsPrincipal.Current or Thread.CurrentPrincipal to get you that information. If you control the external assembly, you're now dependent on Microsoft.AspNetCore.Http in all of your libraries, which is unnecessary.

Proposed API

The proposal is a stand-alone class that does not affect the behavior or functionality of any existing APIs, which should make it quick to approve and get into the current release, even given the current timeframe for .NET 6's release.

The solution is to implement an identical pattern to IHttpContextAccessor for IPrincipal. This will require an Interface to be added to System.Security, and an HttpContextPrincipalAccessor in Microsoft.AspNetCore.Http.

namespace Microsoft.AspNetCore.Authentication
{
    public class AuthenticationOptions
    {
+       bool EnableThreadCurrentPrincipal { get; set; }
    }
}

Because the shipped implementation takes an IHttpContextAccessor in the constructor, it will pull in the thread's HttpContext to correctly pull the user from.

Usage Examples

public class Startup
{
    public void ConfigureServices(IServiceCollection services)
    {
        services
            .AddAuthentication(options => 
             {
                  options.EnableThreadCurrentPrincipal = true;
                  options.DefaultScheme = "Cookies";
             });
    }
}

Alternative Designs

I considered making everything a ClaimsPrincipal, as that is the proper way to do things, but I considered that it could be a WindowsPrincipal instead, so IPrincipal is probably a better approach.
The implementation would probably do a TryAddService() on IHttpContextAccessor, just in case the user forgot to add one.

Risks

AFAIK there are no risks to the added API itself, just the timing.
The IPrincipalAccessor API would need to get in the .NET Core Libraries, which risks the team not wanting to add it at this stage of the game.
The AspNetCore team may decide not to add the HttpContextPrincipalAccessor at this stage of the game, even if the .NET Core team is cool with it.

I have the requisite pull requests ready to submit if the team is OK with this.

dotnet / aspnetcore