WCF AuthorizationPolicy: Impersonation Problem

I have the following situation (outline):

Authorization Webservice

This service gets called and verifies (by executing the given business logic) whether a user is valid or not.

Custom Business Webservice

This is some webservice created for a business app, that internally calls the "Authorization Webservice" in order to verify the account which called the business webservice.

I realized this logic by making use of WCF service authorization in my "Custom Business Webservice". Basically I configured

<serviceAuthorization principalPermissionMode="Custom">
    <authorizationPolicies>
        <add policyType="MyCompany.Authorization.WCF.AuthorizationPolicy, MyCompany.AuthorizationDll"/>
    </authorizationPolicies>
</serviceAuthorization>

The AuthorizationPolicy internally invokes the "Authorization Webservice".

The Problem

The problem is that I need to impersonate the caller of my "Custom Business Webservice". The client identity is the correct one, however the WindowsIdentity is that of the application pool user.

Note, impersonation works within the service itself if I use [OperationBehavior(Impersonation = ImpersonationOption.Required)] but it does not within the AuthorizationPolicy's Evaluate(...) method.

(I use Transport level security using windows authentication credentials, obviously)

Anyone has any hints on how I can impersonate the caller prior to entering the IAut开发者_JS百科horizationPolicy.Evaluate(...) method??

---

It always again feels a bit strange, answering to my own questions, but for the sake of sharing what I got with others I'm going to post the "solution" here.

I'll try to make it short:

1. Impersonating in the IAuthorizationPolicy.Evaluate(...) is not possible. (S4U2Self may work, didn't test that since I didn't have that option)

As I already mentioned, impersonating the caller within the webservice operation worked by placing the [OperationBehavior(Impersonation = ImpersonationOption.Required)]. So calling my custom webservice for retrieving the principal as the first statement in my service operation would always work. I didn't like that approach however.
As an alternative I tried to find the latest possible point in the call chain of a WCF service operation where the impersonation finally worked. This is where I found the OperationInvoker.

The following diagram illustrates the sequence of dispatchings that are done before the call arrives at the actual operation (taken from here):

Parameter Inspection was too early, impersonation didn't yet work, but it luckily worked in the Operation Invoker. So by writing a custom operation invoker and wrapping everything into a custom operation behavior attribute I was able to elegantly solve the problem.

More info on an according blog post I wrote.