Http Spec: Прокси-авторизация и заголовки авторизации

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

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

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

после прочтения спецификаций я не совсем уверен, как я должен это реализовать. Вот о чем я думал:--15-->

  1. пользователь делает HTTP-запрос к прокси без какой-либо аутентификации.
  2. прокси-ответы 407 Proxy Authentication Required и возвращает Proxy-Authenticate заголовок в формате:"Proxy-Authenticate: Basic realm="proxy.com".
    вопрос: Это Proxy-Authenticate правильно заголовок?
  3. затем клиент повторяет запрос с Proxy-Authorization заголовок, то есть представление Base64 прокси username:password.
  4. на этот раз прокси аутентифицирует запрос, но затем приложение отвечает с . Пользователь был аутентифицирован прокси-сервером, но не приложением. Приложение добавляет WWW-Authenticate заголовок ответа, как WWW-Authenticate: Basic realm="app.com". вопрос: это значение заголовка правильно правильно?
  5. клиент повторяет попытку запроса с помощью обоих и Authorization заголовок, оцененный с представлением Base64 приложения username:password.
  6. на этом этапе прокси успешно аутентифицирует запрос, перенаправляет запрос в приложение, которое также аутентифицирует пользователя. И клиент, наконец, получает ответ.

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

39
authentication basic-authentication http proxy-authentication specifications

1 ответов

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

интересно отметить, что для данного соединения возможно, хотя и маловероятно, задействовать несколько прокси, которые скованы вместе, и каждый из них может сам требовать аутентификации. В этом случае клиентская сторона каждого промежуточного прокси-сервера сама получит обратно 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-сертификаты как прокси-сервера, так и сервера, позволяя аутентифицировать идентичность обоих.

26