The correct answer to Issue 10 was already mentioned by Andrew & Mario:
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;
return t1.HelloWorld();
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:
So why would one use it? I see two main drivers why people are using impersonation in the context of Web Services:
Suggested approach:
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…