Problems running a Secure WCF Service in a DMZ

Question

I'm having some trouble with two web applications that communicate each other using WCF Services. This is my scenario:

• Web Application "A" is deployed in a server of the corporate intranet and part of domain "intranet"
• Web Application "B" is deployed in a server of the DMZ, exposed to internet and part of domain "extranet"
• A firewall is between the two domains, and there is no trust relationship.
• "A" calls some WCF services in "B", using wsHttpBinding
• WCF Services in "B" are transport-secured under SSL on IIS.
• We are using user-name authentication behavior to authenticate "A"

this is the server binding configuration:

">

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

" Everything seems to works fine in my test environment, which has two domains like in production. Nevertheless in production environment I get an ugly error every time "A" calls "B" which is:

---

    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)

---

First I thought it was a problem of clock synchronization between servers, since I could reproduce the same exception in test environment by changing the clock with a differece of 10 mins. Unfortunally this doesn't seems to be the problem cause our production servers are in synch.

Any information will be appreciated!!

Answer 1

Finally we could sove the problem, and it was that app pool identity was unable to write at "C:\Windows\Temp" because of lack of permissions.

It seems that MessageSecurityException is a generic kind of exception and can be thrown for many problems. To know the real exception we added a serviceDebug behavior to service config and watch the eventviewer for detailed info about the error.

This is the debug config:

---

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

---

Thanks anyway!

Answer 2

For Anonymous, Username or Certificate client credential types, setting this property [negotiateservicecredential] to false implies that the service certificate must be available at the client out of band and that the client must specify the service's certificate to use.

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