401 недостоверный ответ в Kerberos - PullRequest
0 голосов
/ 25 января 2019

Только что заметил, что при аутентификации Kerberos клиентский браузер всегда сначала получает ответ 401 (с заголовком WWW-Authenticate: Negotiate), а в следующем запросе фактический токен Kerberos отправляется для аутентификации (обрабатывается внутренне браузером).

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

Я понимаю, что протокол NTLM разработан так, но хотите понять, почему?

1 Ответ

0 голосов
/ 25 января 2019

HTTP не имеет состояния. Если сервер не сообщит клиенту, что он должен сохранять состояние (через cookie-файл сервера), клиент никогда не должен предполагать что-либо о намерениях сервера.

Более того, неправильно предполагать, что любая из сторон всегда может выполнять Kerberos. Первоначально сервер заявил, что хочет согласовать, а Negotiate содержит набор доступных протоколов в предпочтительном порядке (Kerberos, NTLM и т. Д.). Клиент может выполнять Kerberos, когда он находится на линии прямой видимости с KDC, но он может выполнять NTLM в любых / в большинстве случаев, и он предпочитает Kerberos.

Кроме того, после аутентификации клиента сервер может ответить сессионным cookie. Браузер не понимает содержимого, поэтому он не знает, что произошло. Затем сервер должен всегда указывать браузеру, что ему нужно снова авторизоваться (через 401 + WWW-Auth).

...