подключение к службе wcf, размещенной в домене, с клиента, которого нет в домене - PullRequest
Новая
       34

подключение к службе wcf, размещенной в домене, с клиента, которого нет в домене

1 голос
/ 04 марта 2011

Мне нужен пример или объяснение того, как подключить клиента к сервису wcf, когда клиент не находится в домене.

Я предполагаю, что есть способ указать учетные данные домена с клиентом, и служба wcf может связаться с полномочным органом (dc), чтобы проверить, безопасен ли клиент.

Я следовал примерам наmsdn и может подключиться, чтобы увидеть метаданные (доступные методы), но при использовании wshttpbinding я получаю «Необеспеченную или неправильно защищенную ошибку, полученную от другой стороны».

Заранее спасибо!

Ответы [ 3 ]

1 голос
/ 04 марта 2011

По умолчанию wsHttpBinding будет использовать учетные данные Windows - это работает только в том случае, если и ваша служба, и ваш вызывающий клиент являются членами одного домена (или членами доменов, имеющих отношения взаимного доверия).

ЕслиЕсли вы хотите пройти аутентификацию, используя имя пользователя / пароль, вам нужно сделать несколько вещей:

  • службе требуется сертификат для аутентификации вызывающей стороны и обеспечения механизма шифрования дляобмен логин / паролей и сообщений.Поэтому вам нужно будет создать сертификат безопасности, установить его на серверном компьютере и настроить его: 

    <system.serviceModel>
  <behaviors>
     <serviceBehaviors>
        <behavior name="Internet">
            <serviceCredentials 
                 findValue="MyServiceCertificate"
                 storeLocation="LocalMachine"
                 storeName="My"
                 X509FindType="FindBySubjectName" />
        </behavior>
     <serviceBehaviors>
  <behaviors>
  <services>
      <service name="MyService" behaviorConfiguration="Internet">
         ......
     </service>
  </services>
</system.serviceModel>

  • клиенту необходимо настроить конфигурацию, которая определяет wsHttpBinding сбезопасность сообщений и учетные данные клиента имени пользователя и пароля 

    <system.serviceModel>
  <bindings>
     <wsHttpBinding>
        <binding name="UserNameWS">
            <security mode="Message">
                <message clientCredentialType="UserName" />
            </security>
        </binding>
     <wsHttpBinding>
  <bindings>
  <client>
      <endpoint name="Default"
          address="........."
          binding="wsHttpBinding" bindingConfiguration="UserNameWS"
          contract="........." />
  </client>
</system.serviceModel>

  • на стороне сервера, вам необходимо настроить механизм аутентификации этих имени пользователя / паролей - как правило, самый простой способ - этоиспользовать систему членства ASP.NET 

    <system.serviceModel>
  <behaviors>
     <serviceBehaviors>
        <behavior name="Internet">
            <userNameAuthentication
                userNamePasswordValidationMode="MembershipProvider" />
            <serviceCredentials 

   .....
</system.serviceModel>

  • перед каждым вызовом клиента, вам необходимо установить имя пользователя / пароль на прокси на стороне клиента (это один из немногихвещи, которые вы не можете сделать в конфигурации - работает только в коде). 

    proxy.ClientCredentials.UserName.UserName = "YourUserName";
proxy.ClientCredentials.UserName.Password = "Top$Secret";

Узнайте все о безопасности WCF на Руководстве по безопасности WCF на сайте Codeplex.

0 голосов
/ 04 марта 2011

Причина, по которой вы можете получить доступ к метаданным и не можете вызвать службу, заключается в том, что вы используете WsHttpBinding, вероятно, с конфигурацией по умолчанию.Он использует безопасность сообщений, которая используется только для использования службы, а не для метаданных службы.Он использует учетные данные Windows и безопасность Windows для шифрования и подписи сообщений.Из-за безопасности Windows он работает только тогда, когда и клиент, и сервер находятся в одном домене.

Ваш клиент не является частью домена - вы можете отправлять учетные данные Windows либо с защитой сообщений, либо с безопасностью транспорта.В случае защиты сообщений вы должны будете использовать clientCredentialType="UserName", средство проверки пароля по умолчанию, и вам придется настроить сертификат X509 в режиме обслуживания для поддержки шифрования и подписи.В случае безопасности транспорта будет использоваться либо HTTPS (сертификат X509, настроенный в http.sys / IIS), либо режим TransportCredentialOnly, который будет отправлять имя пользователя и пароль windows в виде простого текста по HTTP (это плохое решение).В случае безопасности на транспорте установлен clientCredentialType="Basic".

0 голосов
/ 04 марта 2011

Сообщение об ошибке «Необеспеченная или неправильно защищенная ошибка была получена от другой стороны» является довольно вводящим в заблуждение. Распространенной причиной является различие в конфигурации привязок между клиентом и сервером. Проверьте раздел system.serviceModel в файле web.config на стороне службы и измените настройки клиента в соответствии с ними.

...