Основные сведения о проверке подлинности HTTP
Проверка подлинности — это процесс определения того, кто является клиентом, как правило, чтобы определить, имеет ли клиент право доступа к ресурсу. Протокол HTTP поддерживает проверку подлинности как средство согласования доступа к защищенному ресурсу.
Исходный запрос от клиента как правило является анонимными и не содержит информацию для проверки подлинности. Приложения HTTP-сервера могут запретить анонимный запрос, указывая, что требуется проверка подлинности. Серверное приложение отправляет заголовки WWW-Authentication, чтобы указать поддерживаемые схемы проверки подлинности. В этой статье описывается несколько схем проверки подлинности для HTTP и рассматриваются их поддержка в Windows Communication Foundation (WCF).
Схемы проверки подлинности HTTP
Сервер может указать несколько схем проверки подлинности для клиента. В следующей таблице описаны некоторые схемы проверки подлинности, часто найденные в приложениях Windows:
| Схема проверки подлинности | Description |
|---|---|
| Анонимные | Анонимный запрос не содержит никаких сведений о проверке подлинности. Анонимный эквивалентен предоставлению всем пользователям доступа к ресурсу. |
| Базовая | Обычная проверка подлинности заключается в передаче строки в кодировке Base64, которая содержит имя пользователя и пароль для клиента. Base64 не является формой шифрования и должен считаться таким же, как отправка имени пользователя и пароля в виде ясного текста. Если требуется защита ресурса, настоятельно рекомендуется использовать схему проверку подлинности, отличную от обычной. |
| Дайджест | Дайджест-проверка подлинности - это схема запроса-ответа, предназначенная для замены обычной проверки подлинности. Сервер отправляет строку случайных данных, называемую nonce , клиенту в качестве задачи. Клиент отвечает с хэшем, который содержит помимо дополнительной информации имя пользователя, пароль и специальное слово. Сложность этого обмена представляет и хэширование данных затрудняет кражу и повторное использование учетных данных пользователя с этой схемой проверки подлинности. Дайджест-проверка подлинности требует использования учетных записей домена Windows. Область дайджеста — это доменное имя Windows. Поэтому вы не можете использовать сервер, работающий в операционной системе, которая не поддерживает домены Windows, такие как Windows XP Home Edition, с проверкой подлинности дайджеста. И наоборот, если клиент работает в операционной системе, которая не поддерживает домены Windows, учетная запись домена должна быть явно указана во время проверки подлинности. |
| NTLM | Проверка подлинности NT LAN Manager (NTLM) — это схема ответа на вызовы, которая является более безопасным вариантом проверки подлинности дайджеста. NTLM использует учетные данные Windows для преобразования данных вызова вместо передачи незашифрованных имени пользователя и пароля. Проверка подлинности NTLM требует множественного обмена между клиентом и сервером. Сервер и любой промежуточный прокси-сервер должны поддерживать постоянные соединения для успешного завершения проверки подлинности. |
| Согласование | Проверка подлинности Negotiate, в зависимости от доступности, автоматически выбирает протокол 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), любая схема, которую она не готова принять или не обеспечивает надлежащей защиты защищенного ресурса. Клиент свободен в выборе любой схемы проверки подлинности, предоставляемой сервером. Некоторые клиенты выбирают по умолчанию слабую схему проверки подлинности или первую схему проверки подлинности в списке сервера.