ClaimsPrincipal.Current does not return the ClaimsPrincipal of the caller.

[brentschmaltz]

In previous runtimes ClaimsPrincipal.Current returned the ClaimsPrincipal that was created by the authentication layer. This provided a consistent programming model.

[kevinchalet]

/cc @davidfowl, as we chatted about this specific feature on JabbR.

[vibronet]

This is a key feature. Developers should be able to find the identity of the caller in the same property regardless of host type and past/present/future Dev stack. The manipulation of claims should not be coupled to how the claims themselves were obtained, which is the promise that .net made from 4.5 onward.

[davidfowl]

@vibronet Totally agree its just the implementation in .NET 4.5 doesn't have everything required to make this work properly.

[leastprivilege]

Really? Are we reviving that?

I thought you gonna deprecate global mutable statics in favour of modern techniques like DI and better testability.

Are you also planning to bring HttpContext.Current back? :p

[davidfowl]

This is about compatibility on .NET 4.x. It's also not going to work on .NET core AFAIK. I generally hate the statics but its the pattern the identity team has been pushing. There's actually a problem with the implementation in NET 4.x that makes it hard to implement this properly thats why it's not working right now.

HttpContext.Current isn't coming back as a static 😄

[leastprivilege]

Right - as you are saying -

• it does not work reliably right now.
• It won't go forward in .NET Core.
• It is bad style

So why care at all in ASP.NET 5?

[brentschmaltz]

@leastprivilege can you be specific as to what doesn't work reliably right now?
@davidfowl there is a solution that would work in most scenarios
Let's separate this into parts:

• ClaimsPrincipal.Current
  • The Identity Team is encouraging ClaimsPrincipal.Current which worked fine with previous runtimes.
• Implementation
  • The Identity Team is not pushing statics or any other implementation.
    Currently HttpContext.User returns the Identity that the AuthenticationLayer and runtime have created. It is possible that ClaimsPrincipal.Current could return the same value.
• Going forward
  • We are going to suggest changes in .Net to improve the feature.

[leastprivilege]

Thread.CurrentPrincipal (and thus ClaimsPrincipal.Current) comes from a time where

• people did not care about unit tests and global static mutables
• where the mental model was that a principal is assigned/attached to one thread of execution

Both has clearly changed.

There have been a couple of of inconsistencies with using Thread.CurrentPrincipal and async/await in the past - e.g. with russian doll style pipelines (e.g. Web API and I guess Katana and ASP.NET 5 have the same issue).

When e.g. one piece in the pipeline sets Thread.CurrentPrincipal on the way in - on the way out plumbing that runs "later" then the code that set the principal in the first place does not see the right principal due to async/await cleaning up the call stack. This happened in Web API with a message handler that set the principal on the way in - but the media type formatter ran much later on the way out.

I do remember other inconsistencies with Web API and the Katana self host where after creating a bunch of threads the current principal was not in sync anymore with the Web API request context. Generally using the request context in Web API was the "officially" recommended way of accessing the current principal.

Syncing and propagating the principal to new threads seems complex and error prone. That combined with statics makes this approach a thing of the past. ASP.NET 5 is a thing of the future.

my 2c.

[damianh]

Mutable static state 🔫

Sure, may as well bring in CommonServiceLocator while we're at it.

Sorry for the sarcastic tone but I strongly feel this is a Bad Idea.

[brentschmaltz]

@leastprivilege Interesting observations, I agree with most of them.
@damianh The identity of the caller is fixed one authentication is complete w.r.t. a call.

Some history.
Back in 2010 when we started the move of putting ClaimsPrincipal in .Net 4.5. I argued that Thread.CurrentPrincipal was not the right model. So I invented ClaimsPrincipal.Current that contains a settable delegate, ClaimsPrincipalSelector, that will return the CurrentPrincipal. ClaimsPrincipal.Current -> ClaimsPrincipalSelector -> CP. I was trying to prepare for a world post Thread.CurrentPrincipal, which seemed too Windowish.

Since at the time the runtimes of interest were WCF and Asp.Net, returning Thread.CurrentPrincipal seemed the right default. It is and was my belief that the runtime that is responsible for creating the ClaimsPrincipal should be responsible for crafting the ClaimsPrincipalSelector.

So conceptually, I think we are on the same page. In multi-threaded, async, apppool, queued apps, there has to be a deterministic model for mapping back to context that the call arrived. Cannot ClaimsPrincipalSelector map back to the correct CP.

@lodejard suggested perhaps we are missing the API: CurrentPrincipal {set;}

Any ideas you have to arrive at the correct API are welcome.

[leastprivilege]

ASP.NET 5 is DI enabled all over - the current principal should be injectable.

[ThatRendle]

Is it even possible to create a static ClaimsPrincipalSelector which is able to extract the "current" ClaimsPrincipal from the active HttpContext, given that there is no HttpContext.Current.

Consistent programming models are all very well and good when they make sense in all the contexts across which they are consistent, but to expect all models to be applicable across all the contexts in which C# and .NET can be used is unrealistic.

[HaoK]

Well the IHttpContextAccessor service already basically provides this via context.User

[brentschmaltz]

@HaoK the idea was to create a selector the mimic'd IHttpContextAccessor.
@markrendle there has to be a way to get to the 'context' that represents the associated inbound message. Otherwise how would IsInRole("admin") work?