Share via

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

  • Статья

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

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

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

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

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

Типы учетных данных транспорта

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

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

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

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

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

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

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

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

Примечание.

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

Внешнее согласование

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

Примечание.

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

Задание значений учетных данных

После выбора режима безопасности необходимо задать фактические значения учетных данных. Например, если типом учетных данных клиента является сертификат, необходимо связать со службой или клиентом определенный сертификат (например, определенный сертификат 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 во второй службе, не может быть изменено. Это становится проблемой, если несколько клиентов могут использовать первую службу, а служба олицетворяет клиенты при доступе ко второй службе. Если служба использует для всех вызывающих один и тот же клиент, все вызовы ко второй службе происходят под идентификацией первого вызывающего, с помощью которой был открыт клиент для второй службы. Иными словами, служба использует идентификацию первого клиента для связи всех своих клиентов с другой службой. Это может привести к повышению привилегий. Если такое поведение службы нежелательно, нужно отслеживать каждого отдельного вызывающего и создавать для каждого из них новый клиент для второй службы. Следует убедиться, что служба использует для связи каждого вызывающего со второй службой только соответствующий клиент.

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

См. также