So, my client application is running under my user account; the middle-tier service is on the same box running under the Network Service account and the back-end service is on another box running under a domain service account.

The client connects to the middle-tier using a netNamedPipe binding. The middle tier impersonates the caller and connects to the back-end service using a wsHttpBinding with message security (clientCredentialType=Windows).

The back-end service authenticates the caller as the impersonated user and executes without error. Is this the expected bahavior?

I see you posted this back in March 2006, has something changed since Indigo became WCF? I sure would like to understand this, so I don’t get bit later when some “small” change breaks my app.

– Alan

Here’s my story:

I am hosting a WCF service in a Windows Service, running under the local Network Service account. The WCF service exposes a single endpoint with a standard netNamedPipeBinding, no binding configuration added.

On the same box I have a unit test, running under my credentials that calls the netNamedPipe service endpoint.

The security negotiation results in a kerberos token in the service. The service is able to impersonate the caller and call a endpoing on another service with a netTcpBinding, again same machine.

In the second service, if I look at the claimset, I see that one of the claims is:
ClaimType: “http://schemas.xmlsoap.org/ws/2005/05/identity/claims/sid”
Resource: {S-1-5-2}
Right: “http://schemas.xmlsoap.org/ws/2005/05/identity/right/possessproperty”

From what you’re saying, seems like my results shouldn’t be possible. Do I misunderstand, what you’re saying here?

You could argue that we could have added a knob “bool AllowOffMachineAccess” which allowed the user to toggle our behavior, though it would also require an overhaul of our net.pipe addressing scheme.

I don’t understand your assertion that you cannot used named pipes with a domain account. Our named pipe tranpsort can be used by any account on the box. The restriction I am talking about is only in effect when using named pipes while running under an impersonated token.

First, it seems to me that under the tenets of SOA, the issue of which connections are acceptable is a matter for policy, not channel. I would expect that the default binding for the named pipe channel would have a policy restricting the other endpoint to one on the same box, because even though named pipes work across boxes, TCP is a more efficient choice in that scenario. However, I could see a situation in which it would make sense to override this policy. Imagine a Windows service that spawns numerous instances of executables to handle work (as IIS does) and uses web services to send messages for assigning work. The named pipe channel would make the most sense. But if on a farm, the services needed to occasionally communicate to coordinate load balancing, you might not want to create a separate binding or a separate service, depending on certain implementation details. In any case, I wouldn’t want the architecture to enforce that named pipes can only be used on-box.

Second, using SIDs to restrict endpoints seems to be a mismatch. I can see that named pipes don’t give you any other way to do it. However, I could see creating a custom security header in soap that would pass some information that could only be known by a client on the same box.

Third, based on your description above, I suspect that if I were running a process under a domain account rather than a local account, I would be unable to used the named pipes channel. This would completely screw me. For various reasons, it is often not an option for me to run a process under a local account, and I would not like it if that denied me the ability to use the named pipe channel.