WCF - Forward authentification Digest de service A à B

Question

J'ai deux services WCF (A et B) avec l'authentification Digest, et le service Un appel d'une opération de service B.

Quand j'appelle service A, le client fournit les informations d'identification et je peux appeler ma méthode sans problèmes. Les mêmes informations d'identification accèdent au service B.

Mais lorsque vous êtes dans le service A, au moment où je dois appeler le service B, y a-t-il un moyen de transférer les informations d'identification fournies de A à B?

Suis-je assez clair?

Answer 1

Vous ne pouvez pas transférer les informations d'identification, mais il peut y avoir un moyen d'obtenir ce que vous voulez selon que vous êtes dans un domaine. Le protocole d'authentification Digest est défini dans RFC 2069 et RFC 2617. Il y a un aperçu plus facile à comprendre sur Wikipedia. Le protocole de base original était le client a essayé de se connecter au serveur non authentifié, le serveur répond alors avec une réponse 401 non autorisée et fournit un défi d'authentification dans l'en-tête WWW-Authenticate. Dans cet en-tête, il existe une valeur et un domaine nonce que le client doit utiliser pour générer un en-tête Authorization. L'en-tête d'autorisation a une valeur calculée comme suit:

HA1=MD5(username:realm:password) 
HA2=MD5(method:digestURI) 
response=MD5(HA1:nonce:HA2) 

Pour un nom d'utilisateur et mot de passe donné, la valeur d'autorisation sera unique pour chaque demande URI, royaume et combinaison nonce. Le client n'a aucun contrôle sur la valeur de nonce. Pour pouvoir utiliser exactement la même valeur de réponse d'autorisation, le service B doit fournir exactement la même valeur de nonce que le service A fourni au client d'origine, et vous devez utiliser une implémentation modifiée de l'algorithme de résumé sur le http. client qui existe sur le Service A et sur le Service B pour permettre à l'authentification digest de réussir avec le même URI qui existait sur le Service A. En d'autres termes, l'authentification fournie au Service A était contre http://serviceA/endpointA et le serivce fonctionnant sur http://serviceB/endpointB devrait accepter le authentification effectuée avec le premier URI. Un autre point clé de l'authentification digest est que le client ne fournit jamais le nom d'utilisateur et le mot de passe au serveur, cela prouve seulement au serveur qu'il les connaît. Le serveur doit déjà les connaître pour vérifier que le client les connaît.
Si vous exécutez dans un environnement de domaine, vous pouvez utiliser l'emprunt d'identité à la place. C'est un mécanisme par lequel le contrôleur de domaine est configuré pour faire confiance au service pour assumer l'identité de tout utilisateur de domaine qui s'authentifie et fournira un jeton d'authentification client valide au service au nom des utilisateurs. Cela peut ensuite être utilisé pour s'authentifier auprès d'autres services. Plus d'informations à ce sujet peuvent être trouvées sur msdn.