Identity Check Issues in IIS Hosted WCF Service

Question

I have a set of WCF Services Hosted in IIS7. I'm in the process of moving the services to a different folder in order to start specifying version and environment in the URL. For example:

http://myserver/MyServices/ServiceA.svc

Becomes:

http://myserver/MyServices/QA/1.1.0/ServiceA.svc

I configured the new folder to be an application in IIS, and set it up to run under the same service app pool we've been using. That has all worked fine, I am able to navigate to my .svc URL and view the WSDL or open up the endpoint in wcf test client. However, when trying to consume the service I am getting the following error:

The identity check failed for the outgoing message. The expected identity is 'identity(http://schemas.xmlsoap.org/ws/2005/05/identity/right/possessproperty: http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn )' for the 'http://myserver/MyServices/QA/1.1.0/ServiceA.svc' target endpoint.

When I check the WSDL output, I noticed that the identity section seemed to leave out the identity of the app pool, which it usually includes:

<Identity xmlns="http://schemas.xmlsoap.org/ws/2006/02/addressingidentity">
<Upn>myappuser@mydomain.local</Upn>
</Identity>

After trying to redeploy and reconfigure the app in IIS, I was able to get the identity to appear in the metadata for only some of the services. Other services still don't include it, which is even more strange than before. There are zero configuration differences between the original stack and the new stack in IIS as far as I can tell. What sorts of issues could I be running in to that would causes these types of identity issues?

Answer 1

The issue was caused by trying to nest the new service stack web application inside of the existing service stack web application. I think that may have caused some confusion for IIS when services in the sub-application were exposing endpoints to the same contracts that the root web application (although in theory this should work just fine). I simply had to move the new service stack into a separate folder structure. Once I did that, I had no problems getting the app pool identity to be exposed in the metadata.