Erreur 407 lors de l'appel de service Web WCF via un proxy Windows authentifié

Question

je la configuration suivante:

1. machine serveur exécutant un service WCF exposée via une application IIS qui nécessite l'authentification Windows.
2. Un serveur proxy (Squid) nécessitant une authentification Windows.
3. Ordinateur client exécutant un service Windows qui tente d'établir une connexion au service WCF via le serveur proxy. Le service est défini avec des informations d'identification de compte de domaine.

Toutes les machines sont sur le même domaine. Si je laisse tomber le proxy de la configuration et de définir uniquement les propriétés suivantes sur la sécurité du client de liaison, tout fonctionne bien:

1. SecurityMode = TransportCredentialOnly
2. Transport.ClientCredentialType =
de Windows

La connexion est effectué avec succès et les informations d'identification correctes sont transmises au serveur.

Si j'ajoute le proxy mais dépose l'authentification Windows requise sur le serveur proxy, tout fonctionne correctement. Le seul paramètre que je change ici sur la sécurité de liaison est:

ProxyAddress = http://myproxyserver:3128

Je peux voir les appels passent par le serveur proxy avec les informations d'identification correctes.

Le problème est que lorsque je définis l'exigence d'authentification Windows sur le serveur proxy, le serveur proxy renvoie l'erreur 407. Lorsque je vérifie les fichiers journaux, je peux voir qu'il n'y a pas de seconde tentative pour répondre à l'erreur 407 avec les informations d'identification correctes. Le réglage ajouter est:

Transport.ProxyCredentialType = de Windows

choses que j'ai essayé et ne fonctionne pas:

1. Set UseDefaultProxy - puisque c'est un service Windows, il n'accepte pas la proxy par défaut.
2. Définissez manuellement les informations d'identification Windows dans ClientCredentials.Windows (y compris le domaine).
3. Ajouter un proxy par défaut dans app.config et machine.config.

Des idées sur ce qui se passe et comment y remédier?

Answer 1

Deux choses qui pourraient être le problème. Tout d'abord, et je ne peux pas être sûr à ce sujet car je n'ai pas essayé d'utiliser un identifiant Windows avec TransportCredentialOnly, est que la sécurité du transport a tendance à être point à point. Cela signifie qu'un service intermédiaire, tel qu'un proxy, devrait authentifier lui-même les informations d'identification de transport, ainsi que rétablir les informations d'identification appropriées pour la répétition de votre demande sur le noeud final réel. Encore une fois, je ne sais pas comment cela fonctionne avec un identifiant Windows ... mais étant donné qu'il s'agit d'un paramètre de sécurité au niveau du transport, je doute qu'il puisse passer par le proxy sans configuration supplémentaire pour garantir que le proxy répète les informations d'identification appropriées . (Gardez à l'esprit que cela annule votre sécurité au niveau du proxy ... ce qui, dans un environnement contrôlé, n'est pas un problème, mais peut être dans un scénario réel.

Ensuite, l'élément enfant transport de l'élément security pour votre configuration de liaison doit avoir un paramètre proxyCredentialType. Si votre proxy interfère avec votre sécurité, vous devrez peut-être vous authentifier auprès du proxy lui-même. Le paramètre proxyCredentialType définit le type d'informations d'identification de proxy à utiliser pour s'authentifier auprès du proxy lui-même. Vous devez ensuite fournir des informations d'identification proxy avant d'envoyer votre message.