Сравнение относительных достоинств и соответствующих сценариев для поддерживаемых учетных данных аутентификации WCF

Question

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

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

Для справки, варианты аутентификации:

• Нет
• Базовый
• Дайджест
• Ntlm
• Windows
• Сертификат
• Пароль

Примечание. Я видел отличную статью об MSDN, но больше не могу ее найти.

Answer 1

Несмотря на то, что я задал этот вопрос, я добавлю то, что знаю о Сертификатах, так как с этим я уже работал - хотя, если мое понимание несовершенно, я был бы рад исправить.* X.509 сертификат состоит из открытого ключа и закрытого ключа и выдан доверенным центром сертификации (вы можете самостоятельно подписать сертификат , это ограничивает полезностьсертификат только для доверенных источников).Центр сертификации взимает плату за сертификат и срок его действия истекает через некоторое время.

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

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

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

Преимущества X.509:

1. , что он может использоваться в разных доменах;и
2. , чтобы закрытый ключ можно было безопасно хранить в хранилище сертификатов клиента.Таким образом, файл .config, содержащий учетные данные, отсутствует.

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

Answer 2

Нет: Довольно просто - используйте это, если вы не хотите идентифицировать или аутентифицировать своих пользователей.

Базовая и дайджест: Эти типы проверки подлинности больше не используются, но иногда вам может понадобиться подключиться к более старой веб-службе, размещенной в IIS, которая может быть настроена для использования базовой или дайджест-проверки подлинности. Трафик не будет зашифрован. Для Basic пароль будет отправлен в виде простого текста, а для дайджеста пароль будет отправлен в плохо зашифрованном виде. Избегайте использования этих типов аутентификации.

NTLM и Windows: NTLM использует NT LAN Manager для контроля безопасности. Windows по умолчанию будет использовать Kerberos (то есть Active Directory) для управления безопасностью. Если Kerberos недоступен, по умолчанию используется NTLM. Используйте NTLM только в том случае, если вам конкретно нужно избегать Kerberos (я не могу придумать сценарий, в котором вы бы хотели это сделать, но частью величия WCF является его гибкость).

Сертификат: Если у ваших пользователей есть собственные сертификаты, которые можно использовать для их идентификации, вы можете рассмотреть возможность использования этого режима аутентификации. Пароли можно угадать - очень сложно угадать сертификат, поэтому это довольно безопасный режим аутентификации (при условии, что сам сертификат безопасен).

Пароль: Используйте пароль, если вы хотите создать свой собственный метод проверки имени пользователя и пароля пользователя. Это может включать доступ к существующему хранилищу учетных данных пользователя в пользовательской базе данных. Вам нужно будет написать свой собственный UserNamePasswordValidator - пример на http://nayyeri.net/custom-username-and-password-authentication-in-wcf-3-5.

Подводя итог, я обычно выбираю Windows в качестве режима аутентификации. Это безопасно и просто и работает для большинства людей в корпоративной среде. Если вы создаете новую службу и по какой-то причине Windows не может быть использована, выберите Сертификат или Пароль. Если вы подключаетесь к более старой службе SOAP, размещенной в IIS, вам может понадобиться использовать None, Basic или Digest.