Problemas ao executar um seguro serviço WCF em um DMZ

Question

Eu estou tendo alguns problemas com duas aplicações web que se comunicam entre si usando WCF Services. Este é o meu cenário:

• Web Application "A" é implantado em um servidor de intranet corporativa e parte do domínio "intranet"
• Aplicação Web "B" é implantado em um servidor da DMZ, expostos a internet e parte do domínio "extranet"
• A é firewall entre os dois domínios, e não há nenhuma relação de confiança.
• "A" chama alguns serviços WCF em "B", usando wsHttpBinding
• WCF Serviços de "B" são o transporte-protegido sob SSL no IIS.
• Nós estamos usando o comportamento de autenticação de nome de usuário para autenticar "A"

Esta é a configuração de ligação de servidor:

">

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

" Tudo parece funciona bem no meu ambiente de teste, que tem dois domínios, como na produção. No entanto, em ambiente de produção eu recebo um erro feio cada vez "A" chamadas "B", que é:

---

    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)

---

Primeiro eu pensei que era um problema de sincronização do relógio entre os servidores, desde que eu poderia reproduzir a mesma exceção no ambiente de teste, alterando o relógio com um differece de 10 minutos. Unfortunally isso não parece ser o problema causa nossos servidores de produção estão em sincronia.

Qualquer informação será apreciado !!

Answer 1

Finalmente, poderíamos sove o problema, e foi essa identidade do pool de aplicativo não foi capaz de escrever em. "C: \ Windows \ Temp" por causa da falta de permissões

Parece que MessageSecurityException é um tipo genérico de exceção e pode ser jogado por muitos problemas. Para saber a verdadeira excepção nós adicionamos um comportamento serviceDebug a configuração de serviço e ver o EventViewer para informações detalhadas sobre o erro.

Esta é a configuração de depuração:

---

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

---

Obrigado de qualquer forma!

Answer 2

Para Anonymous, Nome de usuário ou certificado tipos de credenciais do cliente, a definição dessa propriedade [negotiateservicecredential] para falsa implica que o certificado de serviço deve estar disponível no cliente fora da banda e que o cliente deve especificar o certificado do serviço para uso.

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