Поделиться через

Идентификация и проверка подлинности службы

  • Статья

Удостоверение конечной точки службы представляет собой значение, генерируемое WSDL-кодом службы. Это значение распространяется по всем клиентам и используется для проверки подлинности службы. После того как клиент инициирует связь с конечной точкой и служба пройдет проверку подлинности на клиенте, клиент сравнивает значение удостоверения конечной точки с действительным значением, возвращенным процессом проверки подлинности конечной точки. Если значения совпадают, значит клиент связался с ожидаемой конечной точкой службы. Таким образом обеспечивается защита от фишинга, так как не допускается перенаправление клиента на конечную точку, размещенную на вредоносной службе.

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

ms733130.note(ru-ru,VS.100).gifПримечание
При использовании NT LanMan (NTLM) для проверки подлинности удостоверение службы не проверяется, так как в NTLM проверка подлинности сервера клиентом не поддерживается. NTLM используется, когда компьютеры входят в рабочую группу Windows или при работе в старых версиях Windows, не поддерживающих проверку подлинности Kerberos.

Когда клиент инициирует защищенный канал для отправки сообщения в вышестоящую службу, инфраструктура Windows Communication Foundation (WCF) проверяет подлинность службы и пересылает сообщение только в том случае, если удостоверение службы соответствует удостоверению, указанному в адресе конечной точки, который используется клиентом.

Обработка удостоверений включает следующие этапы.

  • Во время проектирования разработчик клиента определяет удостоверение службы на основе метаданных конечной точки (передаваемых через WSDL).

  • Во время выполнения клиентское приложение проверяет утверждения учетных данных безопасности службы, прежде чем пересылать ей какие-либо сообщения.

Обработка идентификаций на клиенте аналогична проверке подлинности клиента в службе. Защищенная служба не выполняет код до тех пор, пока не будет проведена проверка подлинности учетных данных клиента. Аналогично, клиент не отправляет сообщения службе до тех пор, пока не будет проведена проверка подлинности учетных данных службы, исходя из заранее известной информации на основе метаданных службы.

Свойство Identity класса EndpointAddress представляет удостоверение службы, вызываемой клиентом. Служба публикует свойство Identity в своих метаданных. Когда разработчик клиента запускает Служебное средство ServiceModel Metadata Utility Tool (Svcutil.exe) для конечной точки службы, созданное удостоверение содержит значение свойства Identity службы. Инфраструктура WCF (при настройке с безопасностью) проверяет, принадлежит ли службе указанное удостоверение.

ms733130.Important(ru-ru,VS.100).gif Примечание
Метаданные содержат ожидаемое удостоверение службы, поэтому рекомендуется передавать метаданные службы через защищенные средства, например путем создания конечной точки HTTPS для службы. Дополнительные сведения см. в разделе How to: Secure Metadata Endpoints.

Типы удостоверений

Служба может предоставлять удостоверения пяти типов. Каждый тип удостоверения соответствует элементу, который может содержаться в элементе <identity> в конфигурации. Используемый тип зависит от сценария и требований службы к безопасности. Типы удостоверений описаны в приведенной ниже таблице.

Тип удостоверения Описание Типичный сценарий

Служба доменных имен (DNS)

Этот элемент следует использовать с сертификатами X.509 или учетными записями Windows. Он сравнивает DNS-имя, указанное в учетных данных, со значением, указанным в этом элементе.

Проверка DNS позволяет использовать сертификаты с DNS-именами или именами субъектов. Если сертификат повторно выдан с тем же DNS-именем или именем субъекта, тогда проверка удостоверения по-прежнему действительна. При повторной выдаче сертификата он получает новый ключ RSA, однако при этом сохраняется то же DNS-имя или имя субъекта. Это означает, что клиентам не нужно обновлять в удостоверении информацию о службе.

Сертификат. Используется по умолчанию, если параметру ClientCredentialType присвоено значение "Certificate".

Этот элемент задает значение сертификата X.509 в кодировке Base64 для сравнения с клиентом.

Этот элемент также следует применять при использовании CardSpace в качестве учетных данных для проверки подлинности службы.

Этот элемент ограничивает проверку подлинности одним сертификатом на основе значения отпечатка. Это обеспечивает более строгую проверку подлинности, поскольку значения отпечатков уникальны. При этом следует учитывать следующее: если сертификат был повторно выдан с тем же именем субъекта, у него тем не менее будет новый отпечаток. Поэтому клиенты не могут проверить службу, если неизвестен новый отпечаток. Дополнительные сведения поиске отпечатка сертификата см. в разделе Как извлечь отпечаток сертификата.

Ссылка на сертификат

Идентичен описанному выше типу "Сертификат". Однако этот элемент позволяет задавать имя сертификата и сохранять расположение, из которого нужно получать сертификат.

Аналогичен описанному выше сценарию для типа "Сертификат".

Преимущество в том, что есть возможность изменить расположение хранилища сертификатов.

RSA

Этот элемент задает значение ключа RSA для сравнения с клиентом. Он аналогичен типу "Сертификат", однако вместо использования отпечатка сертификата используется ключ RSA сертификата.

Проверка RSA позволяет ограничить проверку подлинности одним сертификатом с использованием его ключа RSA. Это позволяет выполнять более строгую проверку подлинности определенного ключа RSA, однако если значение ключа RSA будет изменено, служба больше не будет работать с существующими клиентами.

Имя участника-пользователя. Используется по умолчанию, если параметру ClientCredentialType присвоено значение "Windows" и процесс службы выполняется не под одной из системных учетных записей.

Этот элемент задает имя участника-пользователя, под которым выполняется служба. См. раздел "Протокол Kerberos и удостоверение" статьи Переопределение идентификатора службы для проверки подлинности.

Это обеспечивает выполнение службы под определенной учетной записью пользователя Windows. В качестве учетной записи может использоваться либо учетная запись текущего пользователя, либо служба, запущенная под учетной записью определенного пользователя.

Для этого параметра используется безопасность Windows Kerberos, если служба выполняется под учетной записью домена в среде Active Directory.

Имя участника-службы. Используется по умолчанию, если параметру ClientCredentialType присвоено значение "Windows" и процесс службы выполняется под одной из системных учетных записей: LocalService, LocalSystem или NetworkService.

Этот элемент задает имя участника-службы, связанное с учетной записью службы. См. раздел "Протокол Kerberos и удостоверение" статьи Переопределение идентификатора службы для проверки подлинности.

Это обеспечивает идентификацию службы с помощью имени участника-службы и определенной учетной записи Windows, связанной с этим именем.

Для связывания учетной записи компьютера для учетной записи пользователя службы можно воспользоваться средством Setspn.exe.

Этот параметр использует безопасность Windows Kerberos, если служба выполняется под одной из системных учетных записей или под учетной записью домена, с которой связано имя участника-службы, при условии что компьютер входит в домен в среде Active Directory.

Задание удостоверения в службе

Как правило, нет необходимости назначать удостоверение в службе, поскольку выбор типа учетных данных клиента определяет тип удостоверения, передаваемого в метаданных службы. Дополнительные сведения том, как переопределить удостоверение службы, см. в разделе Переопределение идентификатора службы для проверки подлинности.

Использование элемента <identity> в конфигурации

Если изменить тип учетных данных клиента в привязке, ранее показанной сертификату Certificate, созданный WSDL будет содержать сериализованный сертификат X.509 в кодировке Base64, соответствующий значению удостоверения, как показано в следующем примере кода. Используется по умолчанию для всех типов учетных данных клиентов, за исключением Windows.

<Identity xmlns="https://schemas.xmlsoap.org/ws/2006/02/addressingidentity">
<KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
 <X509Data>
 <X509Certificate>MIIBxjCCAXSgAwIBAgIQmXJgyu9tro1M98GifjtuoDAJBgUrDgMCHQUAMBYxFDASBgNVBAMTC1Jvb3QgQWdlbmN5MB4XDTA2MDUxNzIxNDQyNVoXDTM5MTIzMTIzNTk1OVowKTEQMA4GA1UEChMHQ29udG9zbzEVMBMGA1UEAxMMaWRlbnRpdHkuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDBmivcb8hYbh11hqVoDuB7zmJ2y230f/b4e+4P6yXtKKuhUdYcIqc8mAforIM4WWJEVGeJVq9sFEwqrL5Ryid8jMTRwPLvA/x/wvj1gtD1GWJ+aUh2pqieiGL7MWTepHAQBIibUxgOrAOz0j9Xhg0iDFYScdYUjeqI3yZIDC7WbwIDAQABo0swSTBHBgNVHQEEQDA+gBAS5AktBh0dTwCNYSHcFmRjoRgwFjEUMBIGA1UEAxMLUm9vdCBBZ2VuY3mCEAY3bACqAGSKEc+41KpcNfQwCQYFKw4DAh0FAANBADB/J2QjdSPL8Doj3pAveCXd/5fY03eo9kUym/Tmb4ubdqsObri0qnYR/n8Wxsa1yJ4Dks6cNBTPS4l5B7zUeNo=</X509Certificate> 
 </X509Data>
</KeyInfo>
</Identity>

Изменить значение заданного по умолчанию удостоверения службы или тип удостоверения можно с использованием элемента <identity> в конфигурации или задав удостоверение в коде. В следующем коде конфигурации задается идентификатор DNS со значением contoso.com.

Задание удостоверения программным способом

В службе не требуется явным образом задавать удостоверение, так как WCF определяет его автоматически. Однако при необходимости WCF позволяет задавать удостоверение в конечной точке. В приведенном ниже примере кода добавляется новая конечная точка службы с определенным идентификатором DNS.

Dim ep As ServiceEndpoint = myServiceHost.AddServiceEndpoint(GetType(ICalculator), New WSHttpBinding(), String.Empty)
Dim myEndpointAdd As New EndpointAddress(New Uri("https://localhost:8088/calc"), EndpointIdentity.CreateDnsIdentity("contoso.com"))
ep.Address = myEndpointAdd

ServiceEndpoint ep = myServiceHost.AddServiceEndpoint(
                typeof(ICalculator),
                new WSHttpBinding(),
                String.Empty);
EndpointAddress myEndpointAdd = new EndpointAddress(new Uri("https://localhost:8088/calc"),
     EndpointIdentity.CreateDnsIdentity("contoso.com"));
ep.Address = myEndpointAdd;

Назначение удостоверения в клиенте

Во время проектирования разработчик клиента обычно использует Служебное средство ServiceModel Metadata Utility Tool (Svcutil.exe) для создания конфигурации клиента. Созданный файл конфигурации (предназначенный для использования клиентом) содержит удостоверение сервера. Например, приведенный ниже код создан на основе службы, в которой задан идентификатор DNS, как показано в предыдущем примере. Обратите внимание, что значение удостоверения конечной точки клиента совпадает с соответствующим значением службы. В этом случае, когда клиент получает учетные данные Windows (Kerberos) для службы, он ожидает значение contoso.com.

<configuration>
<system.serviceModel>
  <bindings>
    <wsHttpBinding>
      <binding name="WSHttpBinding_ICalculator_Windows">
        <security>
          <message clientCredentialType="Windows"/>
        </security>
      </binding>
    </wsHttpBinding>
  </bindings>
  <client>
    <endpoint address="https://localhost:8003/servicemodelsamples/service/dnsidentity"
      binding="wsHttpBinding"
      bindingConfiguration="WSHttpBinding_ICalculator_Windows"
      contract="ICalculator"
      name="WSHttpBinding_ICalculator">
      <identity>
        <dns value="contoso.com" />
      </identity>
    </endpoint>
  </client>
</system.serviceModel>
</configuration>

Если вместо Windows сертификат в службе задан в качестве клиентского типа учетных данных, тогда ожидается, что свойство DNS будет иметь значение contoso.com. (Если же свойство DNS имеет значение null, имя субъекта сертификата должно иметь значение contoso.com.)

Использование определенного значения для удостоверения

В приведенном ниже файле конфигурации клиента показано, каким образом в качестве удостоверения службы может ожидаться использование определенного значения. В приведенном ниже примере клиент может связываться с двумя конечными точками. Первая конечная точка определяется отпечатком сертификата, а вторая – ключом RSA сертификата. Другими словами, сертификатом, содержащим только пару открытого и закрытого ключей, который не был издан доверенным центром.

<configuration>
<system.serviceModel>
  <bindings>
    <wsHttpBinding>
      <binding name="WSHttpBinding_ICalculator_Anonymous">
        <security>
          <message clientCredentialType="None" />
        </security>
      </binding >
      </wsHttpBinding>
  </bindings>
  <client>
    <endpoint   
address="https://localhost:8003/servicemodelsamples/service/certificateidentity"
        binding="wsHttpBinding"
        bindingConfiguration="WSHttpBinding_ICalculator_Anonymous"
        contract="ICalculator"
        name="WSHttpBinding_ICalculator1">
      <identity>
        <certificate encodedValue="AwAAAAEAAAAUAAAARwEDOI5fk5i0+TbylJ9k8Kljle8gAAAAAQAAAMoBAAAwggHGMIIBdKADAgECAhCZcmDK722ujUz3waJ+O26gMAkGBSsOAwIdBQAwFjEUMBIGA1UEAxMLUm9vdCBBZ2VuY3kwHhcNMDYwNTE3MjE0NDI1WhcNMzkxMjMxMjM1OTU5WjApMRAwDgYDVQQKEwdDb250b3NvMRUwEwYDVQQDEwxpZGVudGl0eS5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMGaK9xvyFhuHXWGpWgO4HvOYnbLbfR/9vh77g/rJe0oq6FR1hwipzyYB+isgzhZYkRUZ4lWr2wUTCqsvlHKJ3yMxNHA8u8D/H/C+PWC0PUZYn5pSHamqJ6IYvsxZN6kcBAEiJtTGA6sA7PSP1eGDSIMVhJx1hSN6ojfJkgMLtZvAgMBAAGjSzBJMEcGA1UdAQRAMD6AEBLkCS0GHR1PAI1hIdwWZGOhGDAWMRQwEgYDVQQDEwtSb290IEFnZW5jeYIQBjdsAKoAZIoRz7jUqlw19DAJBgUrDgMCHQUAA0EAMH8nZCN1I8vwOiPekC94Jd3/l9jTd6j2RTKb9OZvi5t2qw5uuLSqdhH+fxbGxrXIngOSzpw0FM9LiXkHvNR42g==" />
      </identity>
    </endpoint>
    <endpoint address="https://localhost:8003/servicemodelsamples/service/rsaidentity"
        binding="wsHttpBinding"
        bindingConfiguration="WSHttpBinding_ICalculator_Anonymous"
        contract="ICalculator" 
        name="WSHttpBinding_ICalculator2">
      <identity>
        <rsa value="&lt;RSAKeyValue&gt;&lt;Modulus&gt;wZor3G/IWG4ddYalaA7ge85idstt9H/2+HvuD+sl7SiroVHWHCKnPJgH6KyDOFliRFRniVavbBRMKqy+UconfIzE0cDy7wP8f8L49YLQ9RlifmlIdqaonohi+zFk3qRwEASIm1MYDqwDs9I/V4YNIgxWEnHWFI3qiN8mSAwu1m8=&lt;/Modulus&gt;&lt;Exponent&gt;AQAB&lt;/Exponent&gt;&lt;/RSAKeyValue&gt;" />
      </identity>
    </endpoint>
  </client>
</system.serviceModel>
</configuration>

Проверка удостоверения во время выполнения

Во время проектирования разработчик клиента определяет удостоверение сервера с помощью его метаданных. Во время выполнения проверка удостоверения выполняется перед вызовом конечных точек в службе.

Значение удостоверения привязано к типу проверки подлинности, указанному в метаданных; другими словами, к типу учетных данных, используемому в службе.

Если в канале настроена проверка подлинности с использованием протокола SSL на уровне сообщений или транспортном уровне с сертификатами X.509, действительны следующие значения удостоверения.

  • DNS. В WCF сертификат, предоставляемый во время подтверждения SSL, содержит атрибут DNS или CommonName (CN), равный значению, заданному в идентификаторе DNS на клиенте. Обратите внимание, что эти проверки выполняются в дополнение к определению действительности сертификата сервера. По умолчанию WCF проверяет, издан ли сертификат сервера доверенным корневым центром.

  • Сертификат. Во время подтверждения SSL WCF проверяет, предоставлено ли удаленной конечной точкой точное значение сертификата, указанное в удостоверении.

  • Ссылка на сертификат. Аналогичен значению "Сертификат".

  • RSA. Во время подтверждения SSL WCF проверяет, предоставлен ли удаленной конечной точкой точный ключ RSA, указанный в удостоверении.

Если служба выполняет проверку подлинности с использованием протокола SSL на уровне сообщений или транспортном уровне с учетными данными Windows и согласует учетные данные, следующие значения удостоверения являются действительными.

  • DNS. Согласование проходит имя участника-службы, так что DNS-имя может быть проверено. Имя участника-службы указывается в формате host/<dns name>.

  • Имя участника-службы. Возвращается явное имя участника-службы, например host/myservice.

  • Имя участника-пользователя. Имя участника-пользователя учетной записи службы. Имя участника-пользователя указывается в формате username@domain. Например, при выполнении службы под учетной записью пользователя может использоваться такое имя участника-пользователя, как username@contoso.com.

Назначать удостоверение программным путем (с использованием свойства Identity) не обязательно. Если удостоверение не задано и используется тип учетных данных клиента Windows, по умолчанию имени участника-службы назначается значение, соответствующее имени узла в адресе конечной точки службы с префиксом "host/". Если удостоверение задано и в качестве типа учетных данных клиента применяется сертификат, по умолчанию используется значение Certificate. Это относится к безопасности как на уровне сообщений, так и на транспортном уровне.

Удостоверение и пользовательские привязки

Поскольку удостоверение службы зависит от используемого типа привязки, при создании пользовательской привязки убедитесь, что передается требуемое удостоверение. Например, в приведенном ниже примере кода передаваемое удостоверение несовместимо с типом безопасности, поскольку удостоверение для привязки начальной загрузки защищенного диалога не соответствует удостоверению для привязки на конечной точке. Привязка защищенного диалога назначает идентификатор DNS, тогда как WindowsStreamSecurityBindingElement назначает удостоверение имени участника-пользователя или участника-службы.

Dim binding As New CustomBinding()
' The following binding exposes a DNS identity.
binding.Elements.Add(SecurityBindingElement.CreateSecureConversationBindingElement(SecurityBindingElement.CreateIssuedTokenForSslBindingElement(New IssuedSecurityTokenParameters())))

' The following element requires a UPN or SPN identity.
binding.Elements.Add(New WindowsStreamSecurityBindingElement())
binding.Elements.Add(New TcpTransportBindingElement())

CustomBinding binding = new CustomBinding();
// The following binding exposes a DNS identity.
binding.Elements.Add(SecurityBindingElement.
    CreateSecureConversationBindingElement(
    SecurityBindingElement.
    CreateIssuedTokenForSslBindingElement(
    new IssuedSecurityTokenParameters())));

// The following element requires a UPN or SPN identity.
binding.Elements.Add(new WindowsStreamSecurityBindingElement());
binding.Elements.Add(new TcpTransportBindingElement());

Дополнительные сведения том, как правильно создать стек элементов для пользовательской привязки, см. в разделе Создание пользовательских привязок. Дополнительные сведения создании пользовательской привязки с SecurityBindingElement см. в разделе Как создать SecurityBindingElement для заданного режима проверки подлинности.

См. также

Задачи

Как создать SecurityBindingElement для заданного режима проверки подлинности
Как создать пользовательское средство проверки идентификации клиентов
Как извлечь отпечаток сертификата

Основные понятия

Как создавать пользовательскую привязку с использованием элемента SecurityBindingElement
Выбор типа учетных данных
Работа с сертификатами
Служебное средство ServiceModel Metadata Utility Tool (Svcutil.exe)
Создание пользовательских привязок