J'ai écrit un service WCF très simple qui envoie et reçoit des messages. J'ai testé l'application via l'hôte du serveur Web par défaut VS 2008 et tout fonctionne correctement. Mais lorsque je déploie le service WCF sur IIS d'un autre ordinateur, le message d'erreur suivant s'affiche:
"La demande de jeton de sécurité n'a pas pu être satisfaite car l'authentification a échoué."
Comment définir le type d'authentification pour utiliser mon nom d'utilisateur et mon mot de passe personnalisés dans le fichier de configuration? Si ce n'est pas possible, merci de me dire comment définir les informations d'identification Windows, car les 2 ordinateurs que j'utilise ne partager les mêmes utilisateurs.
Vous devez désactiver la sécurité pour la liaison. Sinon, je pense que, par défaut, wsHttpBinding tentera de négocier un jeton de contexte de sécurité (SCT).
Modifiez donc la définition du noeud final pour qu'elle pointe vers une section de configuration de liaison. Voici un exemple:
<endpoint address=""
binding="wsHttpBinding"
contract="HelloWorldService.IService1"
bindingConfiguration="TheBindingConfig">
Ajoutez ensuite quelque chose comme la configuration de liaison suivante juste après la section <services>
dans la section <system.serviceModel>
de web.config.
<bindings>
<wsHttpBinding>
<binding name="TheBindingConfig">
<security mode="None" />
</binding>
</wsHttpBinding>
</bindings>
Définir la sécurité sur "Aucun" est la clé.
J'espère que cela a aidé!
Ce qui précède m'a aidé - mais ce qui n'est pas immédiatement évident, c'est comment ajouter au service end (c'est clair une fois que vous l'avez fait, c'est ce qui est nécessaire, mais pas tant que vous ne l'avez pas fait). La raison pour laquelle cela n’est pas tout à fait évident est qu’il n’ya pas de section bindings par défaut, alors qu’il est probable qu’il en existe une dans le client.
Par conséquent, pour que tout soit bien clair: à la fin du service, ajoutez la section bindings (comme indiqué ci-dessus), puis attribuez à l'attribut approprié le binding bindingConfiguration = "TheBindingConfig". Évident une fois que vous l'avez fait une fois ...
Vous n'avez pas réellement besoin de désactiver la sécurité et dans certains cas, vous ne devriez pas. Dans un bindingConfiguration, vous pouvez spécifier une sécurité au niveau du message qui n'établit pas un contexte de sécurité comme suit:
<security mode="Message">
<transport clientCredentialType="Windows" proxyCredentialType="None"
realm="" />
<message clientCredentialType="Windows" negotiateServiceCredential="true"
algorithmSuite="Default" establishSecurityContext="false" />
</security>
Notez l'attribut EstablSecurityContext. Le client et le service doivent tous deux avoir une configuration de sécurité avec EstablSecurityContext défini sur la même valeur. La valeur true fonctionne également très bien, mais false est recommandé dans un environnement où la charge des serveurs est équilibrée.
Assurez-vous de définir cette bindingConfiguration
(en spécifiant le mode de sécurité 'none') sur le client et le serveur , sinon vous obtiendrez ce message - ce qui est un très mauvais moyen de résoudre le problème.
Le message n'a pas pu être traité . Ceci est probablement dû à l'action ' http://tempuri.org/IInterfaceName/OperationName ' est incorrect ou parce que le message contient un invalide ou a expiré jeton de contexte de sécurité ou parce que il y a une discordance entre les liaisons . Le jeton de contexte de sécurité serait invalide si le service a annulé le canal en raison de l'inactivité. Pour prévenir le service d'abandonner inactif sessions prématurément augmenter le Recevez le délai d'attente sur le service liaison du point final.
Si vous êtes en mode débogage, définissez l’attribut debug comme
<serviceDebug includeExceptionDetailInFaults="true"/>
par défaut, il est défini sur false. Ainsi, pendant le débogage, cette exception est levée.
j'espère que ça aide .