WCF Double Hop Localhost Losing Impersonation on Second Hop

Question

I've seen a lot of posts about the WCF double-hop issue with impersonation, but none of them have specifically helped me resolve my problem.

What am I missing? What else do I need to do in order to retain my Impersonated User (DOMAIN\UserName) over on Service 2? I'm looking at ServiceSecurityContext.Current.WindowsIdentity.Name to confirm - maybe that's wrong.

The Setup:

1. Client App hosted in localhost IIS with Service Reference to Service 1 - Impersonating WindowsIdentity (DOMAIN\UserName)
2. Service 1 - WCF Service hosted in localhost IIS with Service Reference to Service 2
3. Service 2 - WCF Service hosted in localhost IIS

I'm using ALL basicHttpBindings to keep things simple. I've set up SPNs on both service endpoints.

• I can successfully MAKE the double-hop and the code executes just fine
• In Service 1 (hop 1) my ServiceSecurityContext.Current.WindowsIdentity is the person that I impersonated (DOMAIN\UserName)
• In Service 2 (hop 2), my ServiceSecurityContext.Current.WindowsIdentity is the IIS App Pool user
• ImpersonationLevel = "Delegation"
• Both WCF Services have Windows Authentication Enabled and Anonymous Disabled

** Note: I'm running this all locally on my dev box. Even so, I've had my delegation level set to allow delegation from myself to myself. Maybe overkill.

Binding (similar for both services):

<binding name="...">
    <security mode="TransportCredentialOnly">
         <transport clientCredentialType="Windows" />
    </security>
</binding>

I've set the impersonationLevel = "Delegation" on both the WCF service client and the service endpoint behavior configuration. My service methods are specifically decorated with impersonationOption="Allowed" (hop 1) and impersonationOption"Required" (hop 2).

Answer 1

As it turns out, the critical piece in my case was ensuring the following behavior attribute was set:

<serviceAuthorization impersonateCallerForAllOperations="true" />

Previously, when I set this value, I was receiving errors in Entity Framework, so I undid the setting. It appears that somewhere along the line of aligning my setup to the standard implementation (as described in other varios posts) that I was able to eventually set this attribute and have it work as expected.

Edit: If this all works locally, but doesn't work in a distributed environment, check out this post: How can I fix the Kerberos double-hop issue?. You probably need to set the machines to trust delegation between each other.