Is Thread.CurrentPrincipal reliable using OWIN authentication and Web API?

Question

Prior to MVC5 I've heard of / been able to reproduce an issue in the past where the Thread.CurrentPrincipal is not always set correctly when using async operations. Here's one blog post that discusses the issue: http://www.hanselman.com/blog/SystemThreadingThreadCurrentPrincipalVsSystemWebHttpContextCurrentUserOrWhyFormsAuthenticationCanBeSubtle.aspx

Now I've set up authentication in a new Web API project using OWIN middleware on .NET 4.5.2 (using a token auth provider). The Web API's controllers are made up of mostly async operations which call into another business layer assembly. I would like to use the ClaimsPrincipalPermission attributes to secure invocation into this assembly's methods. This attribute works with a ClaimsAuthorizationManager which checks access. I assume under the covers this uses Thread.CurrentPrincipal, and so I'm skeptical as to whether or not I'm going to run into the same issue where the Thread.CurrentPrincipal does not match that of the original Web API's caller.

Am I likely to experience this same issue? So far I have not reproduced it, but I am not convinced the problem is actually solved. I think it is more likely I have just not yet been able to reproduce a problem that is still there.

References:

https://msdn.microsoft.com/en-us/library/system.identitymodel.services.claimsprincipalpermissionattribute(v=vs.110).aspx

http://dotnetcodr.com/2013/02/21/introduction-to-claims-based-security-in-net4-5-with-c-part-4-authorisation-with-claims/

Answer 1

not sure if you ever solved this but i just ran into this very issue at the tale end of a reasonably large project.

The only reason i found this was happening was due to a coding error i had on my front end which caused an async ajax call to my API to be sent twice.

Part of the process of handling the call was to add claims to my owinContext claimsPrinicple. I would have assumed that the calls would be thread safe (or per-request) but i found that the claims principle on the second call contained the claims from the first call. My solution was this.

When setting the claims, retrieve the claimsPrinciple from RequestContext.Principal.Identity NOT owinContext

You can then read the claims later in your business layer, or what have you, from owinContext.

I'm not clear on why, maybe someone can elaborate, but it seems to have fixed the issue.