Il y a quelques jours, j'avais des problèmes d'authentification en utilisant l'authentification Windows entre le client et le service Web wcf . L'erreur que j'obtenais était "La requête HTTP n'est pas autorisée avec le schéma d'authentification client" Négocier ". L'en-tête d'authentification reçu du serveur était" NTLM ". Aucune des solutions sur pile ne fonctionnait car la plupart d'entre elles étaient liées à d'anciennes méthodes.
LA RÉPONSE: Le problème était que toutes les publications d'un tel problème étaient liées à des kerberos plus anciens et à des problèmes IIS pour lesquels les informations d'identification de proxy ou les propriétés AllowNTLM étaient utiles. Mon cas était différent. Ce que j’ai découvert après des heures passées à cueillir des vers sur le sol, c’est qu’une certaine installation IIS n’incluait pas Negotiate provider dans la liste IIS des fournisseurs d’authentification Windows. Je devais donc l'ajouter et monter. Mon service WCF a commencé à s'authentifier comme prévu. Voici la capture d’écran à quoi devrait ressembler si vous utilisez l’authentification Windows avec Anonymous Anh OFF.
Vous devez cliquer avec le bouton droit sur l'authentification Windows et choisir l'élément de menu des fournisseurs.
J'espère que cela vous aidera à gagner du temps.
J'ai mis à niveau ma version précédente de WCF vers WCF 4 avec les modifications ci-dessous. J'espère que vous pourrez également apporter des modifications similaires.
1. Web.config:
<system.serviceModel>
<bindings>
<basicHttpBinding>
<binding name="Demo_BasicHttp">
<security mode="TransportCredentialOnly">
<transport clientCredentialType="InheritedFromHost"/>
</security>
</binding>
</basicHttpBinding>
</bindings>
<services>
<service name="DemoServices.CalculatorService.ServiceImplementation.CalculatorService" behaviorConfiguration="Demo_ServiceBehavior">
<endpoint address="" binding="basicHttpBinding"
bindingConfiguration="Demo_BasicHttp" contract="DemoServices.CalculatorService.ServiceContracts.ICalculatorServiceContract">
<identity>
<dns value="localhost"/>
</identity>
</endpoint>
<endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" />
</service>
</services>
<behaviors>
<serviceBehaviors>
<behavior name="Demo_ServiceBehavior">
<!-- To avoid disclosing metadata information, set the values below to false before deployment -->
<serviceMetadata httpGetEnabled="true" httpsGetEnabled="true"/>
<!-- To receive exception details in faults for debugging purposes, set the value below to true. Set to false before deployment to avoid disclosing exception information -->
<serviceDebug includeExceptionDetailInFaults="false"/>
</behavior>
</serviceBehaviors>
</behaviors>
<protocolMapping>
<add scheme="http" binding="basicHttpBinding" bindingConfiguration="Demo_BasicHttp"/>
</protocolMapping>
<serviceHostingEnvironment aspNetCompatibilityEnabled="true" multipleSiteBindingsEnabled="true" />
</system.serviceModel>
2. App.config:
<system.serviceModel>
<bindings>
<basicHttpBinding>
<binding name="BasicHttpBinding_ICalculatorServiceContract" maxBufferSize="2147483647" maxBufferPoolSize="33554432" maxReceivedMessageSize="2147483647" closeTimeout="00:10:00" sendTimeout="00:10:00" receiveTimeout="00:10:00">
<readerQuotas maxArrayLength="2147483647" maxBytesPerRead="4096" />
<security mode="TransportCredentialOnly">
<transport clientCredentialType="Ntlm" proxyCredentialType="None" realm="" />
</security>
</binding>
</basicHttpBinding>
</bindings>
<client>
<endpoint address="http://localhost:24357/CalculatorService.svc" binding="basicHttpBinding" bindingConfiguration="BasicHttpBinding_ICalculatorServiceContract" contract="ICalculatorServiceContract" name="Demo_BasicHttp" />
</client>
</system.serviceModel>
Pour moi, la solution consistait en outre à utiliser "Ntlm" comme type d'informations d'identification:
XxxSoapClient xxxClient = new XxxSoapClient();
ApplyCredentials(userName, password, xxxClient.ClientCredentials);
private static void ApplyCredentials(string userName, string password, ClientCredentials clientCredentials)
{
clientCredentials.UserName.UserName = userName;
clientCredentials.UserName.Password = password;
clientCredentials.Windows.ClientCredential.UserName = userName;
clientCredentials.Windows.ClientCredential.Password = password;
clientCredentials.Windows.AllowNtlm = true;
clientCredentials.Windows.AllowedImpersonationLevel = System.Security.Principal.TokenImpersonationLevel.Impersonation;
}
Pas ce problème exact, mais c’est le meilleur résultat lorsque vous googlez presque exactement la même erreur :
Si vous rencontrez ce problème lors de l'appel d'un service WCF hébergé sur le même ordinateur, vous devrez peut-être renseigner la clé de registre BackConnectionHostNames
.
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0
MSV1_0
, pointez sur Nouveau et puis cliquez sur Multi-String Value
.BackConnectionHostNames
, puis appuyez sur Entrée.BackConnectionHostNames
, puis cliquez sur Modifier . Dans la zone Données de la valeur, tapez le CNAME ou l'alias DNS utilisé pour les partages locaux sur l'ordinateur, puis cliquez sur OK. Voir Appel du service WCF hébergé dans IIS sur le même ordinateur que le client génère une erreur d'authentification pour plus de détails.