Problèmes en cours d'exécution d'un service sécurisé WCF dans une zone démilitarisée

Question

Je vais avoir des problèmes avec deux applications web qui communiquent entre eux en utilisant WCF. Ceci est mon scénario:

• Application Web "A" est déployé sur un serveur de l'intranet de l'entreprise et une partie du domaine "intranet"
• Application Web « B » est déployée dans un serveur de la zone démilitarisée, exposé à Internet et une partie du domaine « extranet »
• Un pare-feu est entre les deux domaines, et il n'y a pas de relation de confiance.
• "A" appelle certains services WCF dans "B", en utilisant wsHttpBinding
• services WCF dans "B" sont le transport sécurisé sous SSL sur IIS.
• Nous utilisons le comportement d'authentification de nom d'utilisateur pour authentifier « A »

est la configuration de liaison du serveur:

">

<binding name="UsernameWithTransport">
  <security mode="TransportWithMessageCredential">
    <message clientCredentialType="UserName"
      negotiateServiceCredential="false" />
  </security>
</binding>   </wsHttpBinding>

     

»   Tout semble fonctionne très bien dans mon environnement de test, qui a deux domaines comme la production. Cependant dans un environnement de production, je reçois une erreur laide à chaque fois « A » appelle « B » qui est:

---

    System.ServiceModel.Security.MessageSecurityException: An unsecured or incorrectly secured fault was received from the other party. See the inner FaultException for the fault code and detail. ---> System.ServiceModel.FaultException: An error occurred when verifying security for the message.

Server stack trace: 
at System.ServiceModel.Channels.SecurityChannelFactory`1.SecurityRequestChannel.ProcessReply(Message reply, SecurityProtocolCorrelationState correlationState, TimeSpan timeout)
at System.ServiceModel.Channels.SecurityChannelFactory`1.SecurityRequestChannel.Request(Message message, TimeSpan timeout)
at System.ServiceModel.Security.SecuritySessionSecurityTokenProvider.DoOperation(SecuritySessionOperation operation, EndpointAddress target, Uri via, SecurityToken currentToken, TimeSpan timeout)
at System.ServiceModel.Security.SecuritySessionSecurityTokenProvider.GetTokenCore(TimeSpan timeout)
at System.IdentityModel.Selectors.SecurityTokenProvider.GetToken(TimeSpan timeout)
at System.ServiceModel.Security.SecuritySessionClientSettings`1.ClientSecuritySessionChannel.OnOpen(TimeSpan timeout)
at System.ServiceModel.Channels.CommunicationObject.Open(TimeSpan timeout)
at System.ServiceModel.Channels.ServiceChannel.OnOpen(TimeSpan timeout)
at System.ServiceModel.Channels.CommunicationObject.Open(TimeSpan timeout)
at System.ServiceModel.Channels.ServiceChannel.CallOpenOnce.System.ServiceModel.Channels.ServiceChannel.ICallOnce.Call(ServiceChannel channel, TimeSpan timeout)
at System.ServiceModel.Channels.ServiceChannel.CallOnceManager.CallOnce(TimeSpan timeout, CallOnceManager cascade)
at System.ServiceModel.Channels.ServiceChannel.EnsureOpened(TimeSpan timeout)
at System.ServiceModel.Channels.ServiceChannel.Call(String action, Boolean oneway, ProxyOperationRuntime operation, Object[] ins, Object[] outs, TimeSpan timeout)
at System.ServiceModel.Channels.ServiceChannel.Call(String action, Boolean oneway, ProxyOperationRuntime operation, Object[] ins, Object[] outs)
at System.ServiceModel.Channels.ServiceChannelProxy.InvokeService(IMethodCallMessage methodCall, ProxyOperationRuntime operation)
at System.ServiceModel.Channels.ServiceChannelProxy.Invoke(IMessage message)

Exception rethrown at [0]: 
at System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg)
at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type)

---

D'abord, je pensais qu'il était un problème de synchronisation d'horloge entre les serveurs, puisque je pouvais reproduire la même exception dans un environnement de test en changeant l'horloge avec un differece de 10 minutes. Unfortunally cela ne semble pas être le problème provoquent nos serveurs de production sont en phase.

Toute information sera apprécié !!

Answer 1

Enfin, nous pourrions Sove le problème, et c'était que l'identité du pool d'application n'a pas pu écrire à. « C: \ Windows \ Temp » en raison du manque de permissions

Il semble que MessageSecurityException est une sorte générique d'exception et peut être jeté pour de nombreux problèmes. Pour connaître la véritable exception, nous avons ajouté un comportement serviceDebug au service de configuration et de regarder la EventViewer pour des informations détaillées sur l'erreur.

Ceci est la configuration de débogage:

---

<serviceBehaviors>
<behavior name="ServiceBehavior">
 <serviceMetadata httpGetEnabled="false" httpsGetEnabled="true" />
 <serviceDebug includeExceptionDetailInFaults="true" />
 <serviceSecurityAudit auditLogLocation="Application"
  suppressAuditFailure="false"
  serviceAuthorizationAuditLevel="None"
  messageAuthenticationAuditLevel="SuccessOrFailure" />
</behavior>

---

Merci quand même!

Answer 2

Pour Anonymous, Nom d'utilisateur ou de certificats types d'informations d'identification du client, la définition de cette propriété [negotiateservicecredential] false implique que le certificat de service doit être disponible au client hors bande et que le client doit indiquer le certificat du service à utiliser.

http://msdn.microsoft.com /en-us/library/system.servicemodel.messagesecurityoverhttp.negotiateservicecredential.aspx