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:

Client App hosted in localhost IIS with Service Reference to Service 1 - Impersonating WindowsIdentity (DOMAIN\UserName)
Service 1 - WCF Service hosted in localhost IIS with Service Reference to Service 2
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).

is it possible to show code or configuration relevant to how you have set up impersonation? — EdmundYeung99, Mar 19 '13 at 00:31
Hi Edmund. I've added the basic binding configuration. Specifically what else would you be interested in seeing? — chrisriesgo, Mar 19 '13 at 00:46

score 1 · Accepted Answer · edited May 23 '17 at 12:04

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.

edited May 23 '17 at 12:04

Community

1
1

answered Mar 19 '13 at 14:17

chrisriesgo

248
2
13

1

What this added to service 1 or service 2? – Cᴏʀʏ Sep 11 '13 at 20:10
Service 2 and 1 in my case. See my additional answer notes too. You may find yourself with a second issue. – chrisriesgo Sep 12 '13 at 00:18

WCF Double Hop Localhost Losing Impersonation on Second Hop

1 Answers1