Выбор типа учетных данных

Учетные данные — это данные, которые Windows Communication Foundation (WCF) использует для установления либо заявленной личности, либо способностей. Например, паспорт — это документ, который выдается государством для подтверждения гражданства в стране или регионе. В WCF учетные данные могут принимать множество форм, таких как маркеры имени пользователя и сертификаты X.509. В этом разделе рассматриваются учетные данные, их использование в WCF и выбор правильных учетных данных для приложения.

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

Представление учетных данных включает представление данных и подтверждение владения данными. WCF поддерживает различные типы учетных данных на уровнях безопасности транспорта и сообщений. Например, рассмотрим два типа учетных данных, поддерживаемых в WCF: имя пользователя и учетные данные сертификата X.509.

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

С учетными данными сертификата X.509 имя субъекта, альтернативное имя субъекта или определенные поля в сертификате можно использовать в качестве утверждений удостоверения, а другие поля, такие как поля Valid From и Valid To, указывают на допустимость сертификата.

Типы транспортных документов

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

Настройки Описание
Отсутствует Указывает, что клиенту не нужно представлять учетные данные. Это переводится как анонимный клиент.
Базовый Указывает базовую проверку подлинности для клиента. Дополнительные сведения см. в разделе RFC2617— проверка подлинности HTTP: обычная и дайджест-проверка подлинности.
дайджест Указывает проверку подлинности дайджеста для клиента. Дополнительные сведения см. в разделе RFC2617— проверка подлинности HTTP: обычная и дайджест-проверка подлинности.
Ntlm Указывает аутентификацию с помощью NT LAN Manager (NTLM). Это используется, если по какой-то причине не удается использовать проверку подлинности Kerberos. Вы также можете отключить его использование в качестве резервного варианта, установив для свойства AllowNtlm значение false, что приведёт к попытке WCF выбросить исключение при использовании NTLM. Обратите внимание, что установка этого свойства false может не препятствовать отправке учетных данных NTLM по проводу.
Виндоус Указывает аутентификацию Windows. Чтобы указать только протокол Kerberos в домене Windows, установите для свойства AllowNtlm значение false (по умолчанию true).
Сертификат Выполняет проверку подлинности клиента с помощью сертификата X.509.
Пароль Пользователь должен указать имя пользователя и пароль. Проверьте пару имени пользователя и пароля с помощью проверки подлинности Windows или другого пользовательского решения.

Типы учетных данных клиента сообщений

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

Настройки Описание
Отсутствует Указывает, что клиенту не нужно представить учетные данные. Это переводится как анонимный клиент.
Виндоус Позволяет обмениваться SOAP-сообщениями в рамках контекста безопасности, установленного учетными данными Windows.
Имя пользователя Позволяет службе требовать, чтобы клиент прошел проверку подлинности с помощью учетных данных имени пользователя. Обратите внимание, что WCF не разрешает какие-либо криптографические операции с именами пользователей, например создание подписи или шифрование данных. WCF гарантирует, что транспорт защищен при использовании учетных данных имени пользователя.
Сертификат Позволяет службе требовать, чтобы клиент прошел проверку подлинности с помощью сертификата X.509.
Выданный токен Настраиваемый тип токена, настроенный в соответствии с политикой безопасности. Тип маркера по умолчанию — язык разметки утверждений безопасности (SAML). Токен выдан службой безопасных токенов. Дополнительные сведения см. в разделе "Федерация" и "Выданные токены".

Модель согласования учетных данных службы

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

За одним исключением, по умолчанию предоставленные системой привязки в WCF автоматически согласовывают учетные данные службы при использовании безопасности на уровне сообщений. (Исключением является BasicHttpBinding, который не включает безопасность по умолчанию.) Чтобы отключить это поведение, см. в разделе свойств NegotiateServiceCredential и NegotiateServiceCredential.

Замечание

При использовании безопасности SSL с .NET Framework 3.5 и более поздних версий клиент WCF использует как промежуточные сертификаты в хранилище сертификатов, так и промежуточные сертификаты, полученные во время согласования SSL, для выполнения проверки цепочки сертификатов на сертификат службы. .NET Framework 3.0 использует только промежуточные сертификаты, установленные в локальном хранилище сертификатов.

Внеполосные переговоры

Если автоматическое согласование отключено, учетные данные службы должны быть сконфигурированы на стороне клиента перед отправкой любых сообщений в службу. Это также называется внеполосной настройкой. Например, если указанный тип учетных данных является сертификатом, а автоматическое согласование отключено, клиент должен связаться с владельцем службы, чтобы получить и установить сертификат на компьютере, на котором запущено клиентское приложение. Это можно сделать, например, если требуется строго контролировать доступ клиентов к службе в бизнес-сценарии. Эта внеполосная договоренность может быть достигнута по электронной почте, причем сертификат X.509 хранится в хранилище сертификатов Windows с помощью таких средств, как оснастка «Консоль управления Microsoft» (MMC).

Замечание

Свойство ClientCredentials используется для предоставления службе сертификата, полученного через внеполосное согласование. Это необходимо при использовании BasicHttpBinding класса, так как привязка не разрешает автоматическое согласование. Свойство также используется в некоррелированном дуплексном сценарии. Это сценарий, когда сервер отправляет клиенту сообщение, не требуя от клиента отправки запроса серверу. Так как сервер не имеет запроса от клиента, он должен использовать сертификат клиента для шифрования сообщения клиенту.

Настройка значений учетных данных

После выбора режима безопасности необходимо указать фактические учетные данные. Например, если для типа учетных данных задано значение certificate, необходимо связать определенные учетные данные (например, определенный сертификат X.509) со службой или клиентом.

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

Настройка учетных данных службы

Если вы используете режим транспорта и используете HTTP в качестве транспорта, необходимо использовать службы IIS или настроить порт с помощью сертификата. Дополнительные сведения см. в разделе "Обзор безопасности транспорта " и "Безопасность транспорта HTTP".

Чтобы подготовить службу с учетными данными в коде, создайте экземпляр класса ServiceHost и укажите соответствующие учетные данные через класс ServiceCredentials, доступные через свойство Credentials.

Настройка сертификата

Чтобы подготовить службу с сертификатом X.509 для проверки подлинности службы клиентами, используйте SetCertificate метод X509CertificateRecipientServiceCredential класса.

Чтобы настроить службу с помощью клиентского сертификата, используйте метод SetCertificate класса X509CertificateInitiatorServiceCredential.

Настройка учетных данных Windows

Если клиент задает допустимое имя пользователя и пароль, эти учетные данные используются для проверки подлинности клиента. В противном случае используются учетные данные текущего пользователя, вошедшего в систему.

Настройка учетных данных клиента

В WCF клиентские приложения используют клиент WCF для подключения к службам. Каждый клиент является производным от ClientBase<TChannel> класса, а свойство ClientCredentials у клиента позволяет задать различные значения для учетных данных клиента.

Настройка сертификата

Чтобы подготовить службу с сертификатом X.509, который используется для проверки подлинности клиента в службе, используйте SetCertificate метод X509CertificateInitiatorClientCredential класса.

Как учетные данные клиента используются для проверки подлинности клиента в службе

Учетные данные клиента, необходимые для взаимодействия со службой, предоставляются с помощью ClientCredentials свойства или Credentials свойства. Канал безопасности использует эти сведения для проверки подлинности клиента в службе. Проверка подлинности выполняется одним из двух режимов:

  • Учетные данные клиента используются один раз перед отправкой первого сообщения с помощью экземпляра клиента WCF для установления контекста безопасности. Затем все сообщения приложения защищаются через контекст безопасности.

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

Установленные идентичности нельзя изменить

При использовании первого метода установленный контекст постоянно ассоциируется с идентификацией клиента. То есть после установления контекста безопасности удостоверение клиента невозможно изменить.

Это важно

Существует ситуация, когда удостоверение не может быть переключено (то есть когда включение контекста безопасности включено, что является поведением по умолчанию). Если вы создаете службу, которая взаимодействует со второй службой, удостоверение, используемое для открытия клиента WCF во второй службе, не может быть изменено. Это становится проблемой, если нескольким клиентам разрешено использовать первый сервис, и сервис выдаёт себя за клиентов при доступе ко второму сервису. Если служба повторно использует одного и того же клиента для всех вызывающих абонентов, все вызовы ко второй службе выполняются под личностью первого вызывающего абонента, который использовался для открытия клиента ко второй службе. Другими словами, служба использует удостоверение первого клиента для всех своих клиентов для взаимодействия со второй службой. Это может привести к повышению привилегий. Если это не желаемое поведение вашей службы, необходимо отслеживать каждого вызывающего и создавать нового клиента для второй службы для каждого отдельного вызывающего, гарантируя, что служба использует только правильного клиента для правильного вызывающего при связи со второй службой.

Дополнительные сведения об учетных данных и безопасных сеансах см. в разделе "Вопросы безопасности для безопасных сеансов".

См. также

  • Last updated on