Q:

WCF Double Hop Localhost Losing Impersonation on Second Hop

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). 

A:

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.