WCF Fallo en la negociación de la interfaz de proveedor de soporte de seguridad (SSPI)

Question

Estoy usando un servicio de wcf que he creado, cuando tanto la máquina de host como la máquina de cliente están en el mismo dominio todo funciona bien. Cuando publico la aplicación cliente al servidor web en la DMZ estoy consiguiendo el error siguiente:

SOAP security negotiation with 'http://10.0.0.14:3790/Bullfrog/QBService/QBService' for 
target 'http://10.0.0.14:3790/Bullfrog/QBService/QBService' failed. See inner exception 
for more details.The Security Support Provider Interface (SSPI) negotiation failed. 

Aquí es mi servicio principal, donde puedo configurar el servicio

 Uri baseAddress = new Uri("Http://10.0.0.14:3790/Bullfrog/QBService"); 
     ServiceHost selfHost = new ServiceHost(typeof(QBService), baseAddress); 

      try 
      { 
       selfHost.AddServiceEndpoint(
        typeof(IQBService), 
        new WSHttpBinding(), 
        "QBService"); 

       ServiceMetadataBehavior smb = new ServiceMetadataBehavior(); 
       smb.HttpGetEnabled = true; 
       selfHost.Description.Behaviors.Add(smb); 
       selfHost.Open(); 

       Console.WriteLine("The service is ready"); 


      } 
      catch (CommunicationException ce) 
      { 
       //log.Error(ce.Message, ce); 
       Console.WriteLine(ce.Message, ce); 
       selfHost.Abort(); 
      } 

y aquí está el config apartado de mi cliente

<system.serviceModel> 
<bindings> 
    <wsHttpBinding> 
    <binding name="WSHttpBinding_IQBService" closeTimeout="00:01:00" 
     openTimeout="00:01:00" receiveTimeout="00:10:00" sendTimeout="00:01:00" 
     bypassProxyOnLocal="false" transactionFlow="false" hostNameComparisonMode="StrongWildcard" 
     maxBufferPoolSize="524288" maxReceivedMessageSize="65536" 
     messageEncoding="Text" textEncoding="utf-8" useDefaultWebProxy="true" 
     allowCookies="false"> 
     <readerQuotas maxDepth="32" maxStringContentLength="8192" maxArrayLength="16384" 
      maxBytesPerRead="4096" maxNameTableCharCount="16384" /> 
     <reliableSession ordered="true" inactivityTimeout="00:10:00" 
      enabled="false" /> 
     <security mode="Message"> 
     <transport clientCredentialType="Windows" proxyCredentialType="None" 
      realm="" /> 
     <message clientCredentialType="Windows" negotiateServiceCredential="true" 
      algorithmSuite="Default" /> 
     </security> 
    </binding> 
    </wsHttpBinding> 
</bindings> 
<client> 
    <endpoint address="http://10.0.0.14:3790/Bullfrog/QBService/QBService" 
     binding="wsHttpBinding" bindingConfiguration="WSHttpBinding_IQBService" 
     contract="IQBService" name="WSHttpBinding_IQBService"> 
    <identity> 
     <userPrincipalName value="Administrator@bullfrogspas.local" /> 
    </identity> 
    </endpoint> 
</client> 

estoy seguro de la problema es porque está usando la autenticación de Windows. ¿Algunas ideas? ¡Gracias!

Answer 1

No creo que esto funcione y no tengo el entorno para probarlo rápidamente. SSPI utiliza NTLM o Kerberos (obligatorio si no se utiliza la negociación de credenciales de servicio) para autenticar el servicio en el cliente y el cliente en el servicio. Tanto NTLM como Kerberos esperan el mismo dominio o dominios de confianza.

Si desea utilizar la seguridad de los mensajes, puede cambiar su configuración para usar certificados o nombre de usuario + contraseña (el servicio aún requerirá el certificado). Puede validar el nombre de usuario y la contraseña en el directorio activo o en cualquier otro almacén de credenciales.

Recuerde que la seguridad de los mensajes es la más lenta. Se puede lograr un mejor rendimiento con la seguridad del transporte (HTTPS); puede acelerarse mediante dispositivos de red. Si usa HTTPS, puede combinarlo con la autenticación básica y proporcionar credenciales de cliente desde su código para que llame al servicio en su zona interna y use las credenciales de dominio para la autenticación. El servicio será autenticado por su certificado utilizado para HTTPS. HTTPS también permite la autenticación de certificado mutal donde el cliente envía el certificado al servicio, si el certificado del cliente correctamente configurado se puede asignar a la cuenta de dominio. Esos dos enfoques son similares a los enfoques mencionados en la seguridad de los mensajes, pero en lugar de enviar credenciales en el encabezado SOAP se utiliza el encabezado HTTP.

Answer 2

Creo que debería comentar el siguiente código en su web.config

<identity> 
     <userPrincipalName value="Administrator@bullfrogspas.local" /> 
</identity> 

ya que resolvió mi problema.