Why isn't my IAuthorizationPolicy setting the Thread.CurrentPrincipal with my CustomPrincipal?

For my WCF services I've implemented an IAuthorizationPolicy and hooked it up (and can confirm that it's being used).

In the Evaluate() method I am setting a custom principal like so:

evaluationContext.Properties["Principal"] = myCustomPrincipal;

However, when the service is invoked, Thread.CurrentPrincipal is a GenericPrincipal!

My service behavior is configure开发者_运维百科d as follows:

<serviceAuthorization principalPermissionMode="Custom">
    <authorizationPolicies>
        <add policyType="MyNamespace.MyPrincipalAuthorizationPolicy, MyProject, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
    </authorizationPolicies>
</serviceAuthorization>

I tried to use reflector to see what was going on but didn't see anything useful.

Am I doing it wrong? Is there some configuration I'm missing?

I'm not surprised there were tumbleweeds rolling around this question. There is nothing wrong with the approach I detailed in the question.

It turns out the problem was that I was using a custom IInstanceProvider (I didn't even think to include that information). If I stop using the custom instance provider everything works fine. But that's no good as I still want to use it.

So I found the only solution was to manually set the thread's current principal inside the instance provider.

The trick was getting hold of the principal I had set in the IAuthorizationPolicy - I managed to find it in the end using a rather cumbersome call via the static OperationContext.Current.

public object GetInstance(InstanceContext instanceContext, Message message)
{
    var principal =
        OperationContext.Current.ServiceSecurityContext.AuthorizationContext.Properties["Principal"] 
            as MyPrincipal;
    if (principal != null)
        Thread.CurrentPrincipal = principal;
    return ObjectFactory.GetInstance(_serviceType);
}

Of course, I'd be interested to know if there is a more elegant solution.