OperationContext.Current.ClaimsPrincipal vs. Thread.CurrentPrincipal

Question

Hi,

Currently, I’m playing around with WIF 4.5 and WCF 4.5 RC and I’m wondering, why I have to use OperationContext.Current.ClaimsPrincipal instead of Thread.CurrentPrincipal within the service to get access to the user’s claims. The first one is the WIF-based Token, the second one (Thread.CurrentPrincipal) is always an “empty” windows token.

Is this a issue in the current RC or is this by design?

Wishes,

Manfred

Answer 1

It's by design as I think the idea was that its possible for things to occur across threads, so calling into Thread.CurrentPrincipal could be potentially the wrong principal.

---

Developer Security MVP | www.syfuhs.net

Answer 2

Nope. T.cp is propagated correctly.

It's Wcf default behavior. Setting the principal permission mode on the service authz behavior to always "fixes" it.

---

Dominick Baier | thinktecture | http://www.leastprivilege.com

Answer 3

Hi Dominick,

thx for this info. The Service-Behavior

   <serviceAuthorization principalPermissionMode="Always"  />

solves this, so that I can also use Thread.CurrentPrincipal.

Wishes,

Manfred

Answer 4

Hmm, weird.

Any idea why it doesn't set it until the mode is set then? Just usual WCF weirdness or is it actually a threading thing?

---

Developer Security MVP | www.syfuhs.net

Answer 5

WCF did never set T.CP principal consistently. Only if you told it to do so (principalPermissionMode).

The original WCF design was around ClaimSet - which is deprecated when using WIF. So we are back at IPrincipal ;)

So telling WCF to explicitly set a ClaimsPrincipal is just consistent and backwards compat. 

T.CP and threading works fine. http://leastprivilege.com/2012/06/25/thread-currentprincipal-and-propagation-to-new-threads/

---

Dominick Baier | thinktecture | http://www.leastprivilege.com