I have two WCF services (A and B) with Digest Authentication, and service A call an operation from Service B.
When I call Service A, the client provide the credentials and I can call my method without problems. The same credentials access the Service B.
But when inside Service A, in the moment I need to call Service B, is there a way to forward the credentials supplied from A to B?
Am I clear enough?
You can't forward the credentials but there might be a way to achieve what you want depending on whether you are in a domain. The digest authentication protocol is defined in RFC 2069 and RFC 2617. There is an easier to understand overview on Wikipedia. The original basic protocol was the client tried to connect to the server unauthenticated, the server then responds with a 401 unauthorized response and provides an authentication challenge in the WWW-Authenticate header. In this header there is a nonce value and realm which the client needs to use to generate an Authorization header. The Authorization header has a value calculated as follows:
HA1=MD5(username:realm:password)
HA2=MD5(method:digestURI)
response=MD5(HA1:nonce:HA2)
For a given username and password, the authorization value will be unique for each request URI, realm and nonce combination. The client has no control over the nonce value. In order to be able to use the exact same authorization response value, Service B would need to provide the exact same nonce value as Service A provided to the original client, and you would need to use a modified implementation of the digest algorithm on the http client which exists on Service A and on Service B to allow digest authentication to succeed with the same URI as existed on Service A. In other words, the authentication provided to Service A was against http://serviceA/endpointA and the serivce running on http://serviceB/endpointB would need to accept the authentication performed with the first URI. Another key point of digest authentication is the client never provides the username and password to the server, it only proves to the server that it knows them. The server must already know them to verify the client knows them.
If you are running in a domain environment, you can use impersonation instead. This is a mechanism whereby the domain controller is configured to trust the service to assume the identity of any domain users which authenticate and will provide a valid client authentication token to the service on the users behalf. This can then be used to authenticate to other services. More information about this can be found on msdn.
