Question

I am using a wcf service that I created, when both hosting machine and the client machine are on the same domain everything works just fine.
When I publish the client app to the webserver in the DMZ I am getting the following error:

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.

Here is my service main where I set up the service

      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();
            }

and here is the config section on my client

  <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="[e-mail]" />
    </identity>
  </endpoint>
</client>

I am sure the problem is because it is using windows authentication. Any Ideas?
Thank You!

Answer 1

I don’t think this will work and I don’t have environment to quickly test it. SSPI uses NTLM or Kerberos (mandatory if service credentials negotiation is not used) to authenticate service on the client and the client on the service. Both NTLM and Kerberos expect same domain or trusted domains.

If you want to use message security you can change your configuration to use certificates or user name + password (service will still require certificate). You can validate user name and password in active directory or in any other credential store.

Remember that message security is the slowest one. Better performance can be achived with transport security (HTTPS) – it can be accelerated by network devices. If you use HTTPS you can combine it with Basic authentication and provide client credentials from your code so you will call service in your internal zone and you will use domain credentials for authentication. Service will be authenticated by its certificate used for HTTPS. HTTPS also allows mutal certificate authentication where client sends certificate to the service – if correctly configured client certificate can be mapped to domain account. Those two approaches are similar to mentioned approaches in message security but instead of sending credentials in SOAP header HTTP header is used.