Service T1 will deny access, and therefore return a HTTP status 401 error: “Access Denied”
If we want to allow the called services to impersonate the caller’s identity, we have to explicitly pass on its credentials. In the default scenario, no credentials are transmitted and therefore the called service must be enabled for “Anonymous access”. In this case, the service call executes in the context of the account that has been specified for anonymous access. However, if we want to impersonate the caller we have to disable anonymous access and enable “Integrated Windows Security”. In addition to that, we have to make sure that the proxy transmits the right credentials. We can specify this by setting the proxy’s Credential property:
t1.T1 t1 = new OrderSrv.t1.T1();
t1.Credentials = CredentialCache.DefaultCredentials;
By setting the Credentials to the DefaultCredentials the client negotiates with the server to do Kerberos and/or NTLM authentication depending on how the server is configured.
As Mario stated, there are major issues if you want to leverage impersonations in the context of web services:
- The service must be able to authenticate the client credentials and must therefore be in a trust relationship with the client or its KDC
- Integrated Windows authentication does not work across proxy servers or other firewall applications
- Authentication is handled on the transport and not on the message level
- This approach is not suitable for interoperability scenarios
So why would one use it? I see two main drivers why people are using impersonation in the context of Web Services:
- They have to authorize sensitive resource access (e.g. file system or DB).
- It simplifies the effort to get authentication for web service calls.
Allow “Anonymous access” but use WS-Security to authenticate Web Service calls. If the consumer and the service are within different trust-scopes, WS-Trust can be used to issue tokens.
WSE is your friend…