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

Я использую созданную мной службу 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="[email protected]" />
    </identity>
  </endpoint>
</client>

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


c# wcf wcf-security
person twal    schedule 19.08.2010    source источник
comment
Я не уверен на 100%, поэтому я не публикую это как ответ, но аутентификация IMO Windows возможна только в том случае, если и клиент, и сервер находятся в одном домене или в доверенных доменах. Кстати. если и внутренняя сеть, и DMZ являются частью инфраструктуры вашего предприятия, почему вы выбрали WsHttpBinding с безопасностью сообщений? Это самый медленный выбор.   -  person Ladislav Mrnka    schedule 20.08.2010
comment
если и внутренняя сеть, и DMZ являются частью инфраструктуры вашего предприятия, почему вы выбрали WsHttpBinding с безопасностью сообщений? -- потому что я не знаю другого способа :) Что мне следует использовать? Как уже упоминалось, я уверен, что проблема связана с проверкой подлинности Windows. Так что мне нужно использовать вместо этого? Спасибо!   -  person twal    schedule 20.08.2010

Ответы (2)


arrow_upward
8
arrow_downward

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

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

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

person Ladislav Mrnka    schedule 20.08.2010
comment
Спасибо! Я ценю вашу помощь в этом.! У меня это работает с Basic Binding. Хотя мне, вероятно, нужно будет добавить к нему безопасность, прежде чем начать жить с ним. Я не знаю, какой риск и потребность в безопасности, когда хост находится за брандмауэром, а единственный клиент находится в DMZ? - person twal; 23.08.2010
comment
Это зависит от архитектуры вашей сети. Если у вас есть прямой доступ к сервису (без прокси), вы можете без проблем использовать HTTPS. Если вы получаете доступ к сервису через прокси-сервер приложения, такой как сервер ISA, у вас будет отдельное HTTPS-соединение между клиентом и ISA, а другое — между ISA и сервисом. Сообщение будет незащищенным на сервере ISA, но обычно это не проблема, поскольку сервер ISA находится под вашим контролем. - person Ladislav Mrnka; 24.08.2010

arrow_upward
1
arrow_downward

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

<identity>
      <userPrincipalName value="[email protected]" />
</identity>

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

person Ankit    schedule 25.07.2014