WCF Сбой согласования интерфейса поставщика поддержки безопасности (SSPI)

Question

Я использую созданный мной сервис wcf, когда хост-машина и клиентский компьютер находятся в одном домене, все работает просто отлично Когда я публикую клиентское приложение на веб-сервере в DMZ, я получаю следующую ошибку:

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.

Вот мой основной сервис, где я настроил сервис

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

и вот раздел конфигурации на моем клиенте

  <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>

Я уверен, что проблема в том, что он использует проверку подлинности Windows. Есть идеи? Спасибо!

Answer 1

Я не думаю, что это сработает, и у меня нет среды, чтобы быстро это проверить.SSPI использует NTLM или Kerberos (обязательно, если согласование учетных данных службы не используется) для проверки подлинности службы на клиенте и клиента в службе.И NTLM, и Kerberos ожидают один и тот же домен или доверенные домены.

Если вы хотите использовать защиту сообщений, вы можете изменить свою конфигурацию, используя сертификаты или имя пользователя + пароль (для службы по-прежнему требуется сертификат).Вы можете проверить имя пользователя и пароль в активном каталоге или в любом другом хранилище учетных данных.

Помните, что безопасность сообщений самая медленная.Повышенная производительность может быть достигнута с помощью транспортной безопасности (HTTPS) - ее можно повысить с помощью сетевых устройств.Если вы используете HTTPS, вы можете комбинировать его с обычной аутентификацией и предоставлять учетные данные клиента из своего кода, чтобы вызывать службу в своей внутренней зоне и использовать учетные данные домена для аутентификации.Сервис будет аутентифицирован своим сертификатом, используемым для HTTPS.HTTPS также позволяет выполнять взаимную проверку подлинности сертификата, когда клиент отправляет сертификат в службу - если правильно настроенный сертификат клиента можно сопоставить с учетной записью домена.Эти два подхода аналогичны упомянутым подходам в защите сообщений, но вместо отправки учетных данных в заголовке SOAP используется HTTP-заголовок.

Answer 2

Я думаю, вы должны прокомментировать следующий код в вашем web.config

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

как это решило мою проблему.