ASP.Net WCF service's Thread.CurrentPrincipal is being thrown away by some interceptor in a Federated (WIF) environment

Question

I have a per-call WCF service that's being hosted in IIS (.svc). In the service's constructor, I set Thread.CurrentPrincipal = HttpContext.Current.User as per this article. In this case HttpContext.Current.User is of type Microsoft.IdentityModel.Claims.ClaimsPrincipal and has the claims that were sent back from my custom passive STS.

However, as soon as I step into my service operation and examine Thread.CurrentPrincipal, while this object is still of type Microsoft.IdentityModel.Claims.ClaimsIdentity, the object itself is no longer the same as HttpContext.Current.User (IsAuthenticated = false, AuthenticationType = "" and Name is null on Thread.CurrentPrincipal.Identity), whereas these values are all still filled in correctly on HttpContext.Current.User. This tells me that something is intercepting the call to the operation and incorrectly changing the current principal to some generic, empty, unauthenticated claims principal.

I checked the thread ID in the constructor as well as in the operation and it's the same in both places, and evaluating Thread.CurrentPrincipal in the immediate window after assigning from HttpContext.Current.User shows that the thread identity is being set correctly in the constructor, so something is definitely executing in between the constructor and the method, and that something is changing my Thread.CurrentPrincipal.

Does anybody have any idea what is doing this, and how I can go about preventing / fixing this behaviour?

Answer 1

I just ran into a similar problem. I set my custom principal in the constructor of my WCF service. When I left the constructor, and entered the method I called, the thread.currentprincipal was overridden by an empty one. I solved this by adding the following behavior:

<serviceAuthorization principalPermissionMode="None"></serviceAuthorization>

This worked fine for me.