Probleme eines sicheren WCF-Dienst in einer DMZ läuft

Question

Ich habe einige Probleme mit zwei Web-Anwendungen, die sich gegenseitig mit WCF-Diensten kommunizieren. Das ist mein Szenario:

• Web Application "A" wird in einem Server des Unternehmens-Intranet und ein Teil der Domäne "Intranet" eingesetzt
• Web Application "B" befindet sich in einem Server der DMZ bereitgestellt, ausgesetzt Internet und ein Teil der Domain "Extranet"
• Eine Firewall ist zwischen den beiden Domänen, und es gibt keine Vertrauensbeziehung.
• "A" nennt einige WCF-Dienste in "B", mit wsHttpBinding
• WCF-Dienste in "B" ist transport gesichert unter SSL auf IIS.
• Wir verwenden Benutzernamen Authentifizierungsverhalten „A“
zu authentifizieren

Dies ist der Server Bindungskonfiguration:

">

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

     

“   Alles scheint darauf hinzu funktionieren gut in meiner Testumgebung, die wie zwei Domänen in der Produktion. Dennoch in der Produktionsumgebung erhalte ich einen hässlichen Fehler jedes Mal, „A“ Anrufe „B“, das ist:

---

    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)

---

Zuerst dachte ich, es ist ein Problem der Taktsynchronisation zwischen den Servern war, da ich durch eine Änderung der Uhr mit einem differece von 10 Minuten die gleiche Ausnahme in Testumgebung reproduzieren konnte. Unfortunally dies scheint nicht das Problem Ursache unseres Produktions-Server synchronisiert werden soll.

Jede mögliche Informationen geschätzt werden !!

Answer 1

Endlich können wir das Problem sove, und es war, dass AppPool Identität Schreib bei nicht in der Lage war. „C: \ Windows \ Temp“ wegen des Mangels an Berechtigungen

Es scheint, dass Message eine generische Art von Ausnahme und kann für viele Probleme geworfen werden. Um die wirkliche Ausnahme zu wissen haben wir eine serviceDebug Verhalten Dienstkonfiguration und beobachten Sie die Eventviewer für detaillierte Informationen über den Fehler.

Dies ist der Debug-config:

---

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

---

Danke trotzdem!

Answer 2

Für Anonymous, Benutzername oder Zertifikat Client Credential-Typen, die Einstellung dieser Eigenschaft [negotiateservicecredential] auf false bedeutet, dass das Service-Zertifikat auf dem Client aus Band verfügbar sein muss und dass der Kunde der Service-Zertifikat Verwendung angeben müssen.

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