Как механизм согласования HTTP-аутентификации устанавливает сеанс?

Как описано в RFC 4559, Negotiate Механизм может принимать несколько запросов для завершения контекста GSSAPI. Однако из RFC я не могу понять, какой механизм используется для связи этих запросов друг с другом. Чтобы взять пример, описанный в разделе 5 RFC:

1:
  C: GET dir/index.html

2:
  S: HTTP/1.1 401 Unauthorized
  S: WWW-Authenticate: Negotiate

3:
  C: GET dir/index.html
  C: Authorization: Negotiate a87421000492aa874209af8bc028

4:
  S: HTTP/1.1 401 Unauthorized
  S: WWW-Authenticate: Negotiate 749efa7b23409c20b92356

5:
  C: GET dir/index.html
  C: Authorization: Negotiate 89a8742aa8729a8b028

Это ясно для меня вплоть до шага 5. Предполагая, что потенциально много клиентов одновременно выполняют аутентификацию, как сервер узнает, что Authorization заголовок на шаге 5 - это ответ на данные с шага 4? Я не вижу никаких упоминаний о сессионных куки-файлах или о чем-либо, и хотя я не являюсь экспертом по GSSAPI, я не думаю, что есть какие-либо присущие данным GSSAPI, которые можно использовать для связи с сеансом аутентификации.

Так в чем же дело?:)

Источник

2 ответа

Состояние поддерживается с помощью TCP-соединения. RFC-4559 не говорит об этом напрямую, вероятно, потому, что это заставит автора чувствовать себя грязным. Но они ускользают от внимания в разделе 6 при обсуждении «Аутентификации на основе сеанса», когда задействованы прокси. Это требование также «вызывается» в последнем абзаце раздела 2.3 RFC-7230 при обсуждении того, как HTTP должен быть протоколом без сохранения состояния:

Известно, что некоторые нестандартные расширения HTTP (например, [RFC4559]) нарушают это требование, что приводит к проблемам безопасности и совместимости.

Еще большая неясность возникает с другим требованием в последнем абзаце раздела 6:

При использовании средства HTTP-аутентификации SPNEGO с предоставленными клиентом данными, такими как PUT и POST, аутентификация между клиентом и сервером должна быть завершена перед отправкой пользовательских данных. Статус возврата из gss_init_security_context будет означать, что контекст безопасности завершен. На этом этапе данные могут быть отправлены на сервер.

Таким образом, сервер должен запомнить состояние аутентификации после успешного завершения контекста (и отправить клиенту 200 с последним токеном), чтобы разрешить один последний запрос, содержащий фактическую полезную нагрузку?

Ваше замешательство оправдано.

Источник

Из RFC 7235

5.1.2. Соображения для новых схем аутентификации

Существуют определенные аспекты HTTP Authentication Framework, которые накладывают ограничения на работу новых схем аутентификации:

o Предполагается, что HTTP-аутентификация не имеет состояния: вся информация, необходимая для аутентификации запроса, ДОЛЖНА быть предоставлена ​​в запросе, а не зависеть от сервера, запоминающего предыдущие запросы. Аутентификация, основанная на базовом соединении или связанная с ним, выходит за рамки данной спецификации и является ошибочной по своей сути, если не предприняты шаги, чтобы гарантировать, что соединение не может быть использовано какой-либо стороной, кроме аутентифицированного пользователя (см. Раздел 2.3 [RFC7230]).,

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

Источник
Другие вопросы по тегам