Примечание.
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
Проверка подлинности — это процесс определения того, кто является клиентом, как правило, чтобы определить, имеет ли клиент право доступа к ресурсу. Протокол HTTP поддерживает проверку подлинности в качестве средства согласования доступа к защищенному ресурсу.
Первоначальный запрос от клиента обычно является анонимным запросом, не содержащим никаких сведений о проверке подлинности. Приложения HTTP-сервера могут запретить анонимный запрос, указывая, что требуется проверка подлинности. Серверный приложение отправляет заголовки WWW-Authentication, чтобы указать поддерживаемые схемы проверки подлинности. В этой статье описывается несколько схем проверки подлинности для HTTP и рассматриваются их поддержка в Windows Communication Foundation (WCF).
Схемы проверки подлинности HTTP
Сервер может указать несколько схем проверки подлинности для клиента. В следующей таблице описаны некоторые схемы проверки подлинности, часто найденные в приложениях Windows:
| Схема проверки подлинности | Описание |
|---|---|
| Анонимный | Анонимный запрос не содержит никаких сведений о проверке подлинности. Анонимный эквивалентен предоставлению всем пользователям доступа к ресурсу. |
| Базовый | Базовая проверка подлинности отправляет строку в кодировке Base64, содержащую имя пользователя и пароль для клиента. Base64 не является формой шифрования и должен считаться таким же, как отправка имени пользователя и пароля в виде ясного текста. Если ресурсу необходимо защититься, настоятельно рекомендуется использовать схему проверки подлинности, отличной от базовой проверки подлинности. |
| дайджест | Дайджест-проверка подлинности — это схема ответа на вызовы, предназначенная для замены базовой проверки подлинности. Сервер отправляет строку случайных данных, называемую nonce , клиенту в качестве задачи. Клиент отвечает хэшом, который включает имя пользователя, пароль и одноразовое число (nonce), а также дополнительные сведения. Сложность, которую вносит этот обмен, и хэширование данных делают кражу и повторное использование учетных данных пользователя более затруднительным в рамках данной схемы аутентификации. Для проверки подлинности дайджеста требуется использование учетных записей домена Windows. Область дайджеста — это доменное имя Windows. Поэтому вы не можете использовать сервер, работающий на операционной системе, которая не поддерживает домены Windows, например Windows XP Home Edition, с проверкой подлинности с использованием дайджеста. И наоборот, если клиент работает в операционной системе, которая не поддерживает домены Windows, учетная запись домена должна быть явно указана во время проверки подлинности. |
| NTLM | Проверка подлинности NT LAN Manager (NTLM) — это схема ответа на вызовы, которая является более безопасным вариантом проверки подлинности дайджеста. NTLM использует учетные данные Windows для преобразования данных вызовов вместо незакодированного имени пользователя и пароля. Для проверки подлинности NTLM требуется несколько обменов между клиентом и сервером. Сервер и все промежуточные прокси-серверы должны поддерживать постоянные подключения, чтобы успешно завершить проверку подлинности. |
| Вести переговоры | Механизм согласования аутентификации автоматически выбирает между протоколом Kerberos и аутентификацией NTLM в зависимости от доступности. Протокол Kerberos используется, если он доступен; в противном случае используется NTLM. Аутентификация Kerberos значительно превосходит NTLM. Проверка подлинности Kerberos выполняется быстрее, чем NTLM, и позволяет использовать взаимную проверку подлинности и делегирование учетных данных удаленным компьютерам. |
| Windows Live ID | Базовая служба HTTP Windows включает проверку подлинности с помощью федеративных протоколов. Однако стандартные http-транспорты в WCF не поддерживают использование федеративных схем проверки подлинности, таких как Microsoft Windows Live ID. Поддержка этой функции в настоящее время доступна с помощью безопасности сообщений. Дополнительные сведения см. в разделе "Федерация" и "Выданные токены". |
Выбор схемы проверки подлинности
При выборе потенциальных схем проверки подлинности для HTTP-сервера следует учитывать следующие элементы:
Рассмотрите необходимость защиты ресурса. Использование проверки подлинности HTTP требует передачи дополнительных данных и может ограничить взаимодействие с клиентами. Разрешить анонимный доступ к ресурсам, которые не нужно защищать.
Если ресурсу необходимо защититься, рассмотрите, какие схемы проверки подлинности обеспечивают необходимый уровень безопасности. Самая слабая стандартная схема проверки подлинности, описанная здесь: обычная проверка подлинности. Обычная проверка подлинности не защищает учетные данные пользователя. Наиболее надежная стандартная схема авторизации — это Negotiate, включающая протокол Kerberos.
Сервер, например, не должен указывать в заголовках WWW-Authentication любую схему, которую он не готов принять или которая не обеспечивает надлежащую защиту защищенного ресурса. Клиенты могут выбирать одну из схем проверки подлинности, представленных сервером. Некоторые клиенты по умолчанию используют слабую схему проверки подлинности или первую схему проверки подлинности в списке сервера.