J'ai un service WCF utilisant la liaison basicHTTP. Le service sera ciblé pour être déployé en production dans un environnement DMZ sur un serveur Windows Server 2008 64 bits exécutant IIS 7.0 et n'est pas dans un domaine Active Directory.Authentification WCF sur Internet
Le service sera accessible par un partenaire sur Internet avec protection SSL. À l'origine, j'avais construit le service pour utiliser l'authentification Message x.509 avec wsHTTPBinding et après beaucoup de problèmes j'ai punted et décidé de sauvegarder et d'utiliser basicHTTP avec l'authentification UserName.
Résultat: même message d'erreur exact et obscur que j'ai reçu avec le mode certificat.
Le service fonctionne parfaitement dans notre domaine avec exactement la même authentification, mais dès que je passe à la zone démilitarisée je reçois une erreur de lecture. « Un défaut non sécurisé ou mal sécurisé a été reçu de l'autre partie Voir la FaultException interne pour le code d'erreur et le détail ". Le message d'exception interne est: "Une erreur s'est produite lors de la vérification de la sécurité du message."
L'config web de services avec une configuration de liaison est comme suit:
<services>
<service behaviorConfiguration="HSSanoviaFacade.Service1Behavior" name="HSSanoviaFacade.HSSanoviaFacade">
<endpoint address="" binding="basicHttpBinding" contract="HSSanoviaFacade.IHSSanoviaFacade" bindingConfiguration="basicHttp">
<identity>
<dns value="localhost" />
</identity>
</endpoint>
<endpoint address="mex" binding="mexHttpsBinding" contract="IMetadataExchange" />
<host>
<baseAddresses>
<add baseAddress="https://FULLY QUALIFIED HOST NAME CHANGED TO PROTECT/>
</baseAddresses>
</host>
</service>
</services>
<bindings>
<basicHttpBinding>
<binding name="basicHttp">
<security mode="TransportWithMessageCredential">
<message clientCredentialType="UserName" />
</security>
</binding>
</basicHttpBinding>
</bindings>
<behaviors>
<serviceBehaviors>
<behavior name="HSSanoviaFacade.Service1Behavior">
<serviceMetadata httpsGetEnabled="True" />
<serviceDebug includeExceptionDetailInFaults="True" />
</behavior>
</serviceBehaviors>
</behaviors>
La configuration du client de test qui obtient l'erreur:
<bindings>
<basicHttpBinding>
<binding name="BasicHttpBinding_IHSSanoviaFacade" closeTimeout="00:01:00"
openTimeout="00:01:00" receiveTimeout="00:10:00" sendTimeout="00:01:00"
allowCookies="false" bypassProxyOnLocal="false" hostNameComparisonMode="StrongWildcard"
maxBufferSize="65536" maxBufferPoolSize="524288" maxReceivedMessageSize="65536"
messageEncoding="Text" textEncoding="utf-8" transferMode="Buffered"
useDefaultWebProxy="true">
<readerQuotas maxDepth="32" maxStringContentLength="8192" maxArrayLength="16384"
maxBytesPerRead="4096" maxNameTableCharCount="16384" />
<security mode="TransportWithMessageCredential">
<transport clientCredentialType="None" proxyCredentialType="None"
realm="" />
<message clientCredentialType="UserName" algorithmSuite="Default" />
</security>
</binding>
</basicHttpBinding>
</bindings>
<client>
<endpoint address="https://HOST NAME CHANGED TO PROTECT"
binding="basicHttpBinding" bindingConfiguration="BasicHttpBinding_IHSSanoviaFacade"
contract="MembersService.IHSSanoviaFacade" name="BasicHttpBinding_IHSSanoviaFacade" />
</client>
Comme mentionné plus haut, le service fonctionne parfaitement sur le domaine et la boîte IIS de production n'est pas sur un domaine. Je suis en train de peaufiner mes cheveux depuis deux semaines et rien ne semble fonctionner. Si quelqu'un peut aider, j'apprécierais . Même une recommandation pour un travail autour de l'authentification. Je préfère ne pas utiliser un schéma d'authentification personnalisé mais utiliser des fonctionnalités SOAP intégrées.
Les pouvoirs passent à travers le proxy-à-dire proxy.ClientCredentials.UserName.UserName et proxy.ClientCredentials.UserName.Password sont des comptes valides tant sur le domaine interne dans l'environnement de test et comme un compte de machine sur la zone démilitarisée IIS boîte.