Спецификация HTTP: заголовки прокси-авторизации и авторизации

Итак, я пытаюсь реализовать следующий сценарий:

  • Приложение защищено базовой аутентификацией. Скажем, он размещен на app.com
  • HTTP-прокси, перед приложением, требует аутентификации. Он размещен на proxy.com

Таким образом, пользователь должен предоставлять учетные данные как для прокси, так и для приложения в одном запросе, поэтому у него разные пары имени пользователя и пароля: одна пара для аутентификации против приложения и другая пара имени пользователя/пароля для аутентификации прокси.

После прочтения спецификаций я не уверен, как это реализовать. То, что я собирался сделать, это:

  • Пользователь делает HTTP-запрос к прокси без какой-либо проверки подлинности.
  • Прокси отвечает 407 Proxy Authentication Required и возвращает заголовок Proxy-Authenticate в формате: "Proxy-Authenticate: Basic realm="proxy.com".
    Вопрос. Правильно ли установлен этот заголовок Proxy-Authenticate?
  • Затем клиент повторяет запрос с заголовком Proxy-Authorization, который является представлением Base64 прокси-сервера username:password.
  • На этот раз прокси-сервер аутентифицирует запрос, но затем приложение отвечает заголовком 401 Unauthorized. Пользователь был аутентифицирован прокси, но не приложением. Приложение добавляет заголовок WWW-Authenticate в ответ, например WWW-Authenticate: Basic realm="app.com". Вопрос: это правильное значение заголовка?
  • Клиент снова повторяет запрос с заголовком Proxy-Authorization и заголовком Authorization, оцененным с представлением Base64 приложения username:password.
  • На этом этапе прокси успешно аутентифицирует запрос, перенаправляет запрос в приложение, которое также аутентифицирует пользователя. И клиент, наконец, получит ответ.

Правильно ли работает весь рабочий процесс?

Ответы

Ответ 1

Да, это выглядит как действительный рабочий процесс для описанной вами ситуации, и те заголовки Authenticate, похоже, находятся в правильном формате.

Интересно отметить, что возможно, хотя и маловероятно, для данного соединения задействовать несколько прокси-серверов, которые соединены вместе, и каждый сам может потребовать аутентификации. В этом случае клиентская сторона каждого промежуточного прокси-сервера сама вернет сообщение 407 Proxy Authentication Required и сама повторит запрос с заголовком Proxy-Authorization; Заголовки Proxy-Authenticate и Proxy-Authorization представляют собой заголовки с одним ходом, которые не передаются с одного сервера на другой, но WWW-Authenticate и Authorization представляют собой сквозные заголовки, которые считаются от клиента до конечный сервер, переданный посредниками через дословно.

Поскольку схема Basic отправляет пароль в clear (base64 - обратимая кодировка), он чаще всего используется через SSL. Этот сценарий выполняется по-другому, поскольку желательно, чтобы прокси-сервер не мог видеть пароль, отправленный на конечный сервер:

  • клиент открывает канал SSL для прокси-сервера, чтобы инициировать запрос, но вместо отправки обычного HTTP-запроса он отправил специальный CONNECT запрос (все еще с заголовком Proxy-Authorization), чтобы открыть туннель TCP на удаленном сервере.
  • Затем клиент переходит к созданию другого канала SSL, вложенного в первое, по которому он передает окончательное сообщение HTTP, включая заголовок Authorization.

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