Identity Cloud : 3.5.7. Reverse Proxy

Общие сведения

Reverse Proxy – технология подключения веб-приложений к Avanpost Identity Cloud с целью обеспечения 2FA/MFA/SSO/SLO. Данный механизм предназначен для использования в ситуациях, когда требуется подключить к системе единой аутентификации унаследованное веб-приложение без поддержки стандартных IdP-протоколов, к примеру, OAuth/OpenID Connect либо SAML

В режиме Reverse Proxy система Avanpost Identity CLoud выступает в роли посредника (прокси-сервера), с которым взаимодействует пользователь, и которая решает за пользователя задачу аутентификации и взаимодействия с веб-сервером непосредственно приложения. 

Механизм Reverse Proxy функционирует без сторонних прокси/веб-серверов.

Reverse Proxy обеспечивает проксирование запросов от пользователя в сторону веб-приложения, возвращая результат, полученный от веб-приложения, пользователю. 

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

Для маршрутизации запросов от пользователей в направлении HTTP-интерфейса механизма Reverse Proxy можно использовать любой сторонний веб-сервер, к примеру, Nginx.

После получения запроса от пользователя механизм Reverse Proxy выполняет:

  • Поиск приложения по URL в запросе пользователя;
  • Проверка, идентифицирован ли пользователь; если нет - идентификация пользователя;
  • Проверка требований к аутентификации и запрос необходимых методов аутентификации, если требуется;
  • Проверка прав доступа к приложению для пользователя.

После выполнения этих операций выполняется проверка параметров приложения в части требований к аутентификации внутри приложения.

Если аутентификация внутри приложения не требуется (режим аутентификации «Без аутентификации») - запросы пользователя и ответы приложения проксируются без дополнительной модификации.

Если аутентификация внутри приложения требуется (режимы «Базовый», «Форма», «Пользовательский скрипт»), то выполняется аутентификация в соответствии с требуемым режимом, после чего в сессии на стороне Avanpost Identity Cloud сохраняется необходимая сессионная информация - Cookie, заголовки и т.д.  Далее эти сведения используются для модификации последующих запросов пользователя.

Режимы аутентификации в Reverse Proxy-механизме

Для приложения, подключаемого к Avanpost Identity Cloud посредством механизма Reverse Proxy, доступны следующие режимы аутентификации:

  • «Без аутентификации» – в этом случае система работает как прокси-сервер, выполняющий предварительную аутентификацию перед штатной аутентификацией. Дополнительных настроек не предполагается.
  • «Базовый» – используется механизм HTTP Basic для аутентификации пользователя во внутреннем механизме унаследованного веб-приложения. Для автоматической работы режима требуется использование механизма импорта учётных записей прикладной системы.
  • «Форма» – используется механизм аутентификации посредством эмуляции отправки HTTP Web Form. Для автоматической работы режима требуется использование механизма импорта учётных записей прикладной системы.
  • «Пользовательский скрипт» – используется механизм аутентификации с использованием ECMAScript-сценария аутентификации (скриптовый язык, подобный JavaScript). Для автоматической работы режима требуется использование механизма импорта учётных записей прикладной системы.

Для режимов «Базовый», «Форма» и «Пользовательский скрипт» требуется обеспечивать заполнение внутренней базы данных учётных записей пользователей целевого приложения. Для режима «Без аутентификации» учётные данные целевого приложения не требуются.

Режим «Без аутентификации»

Применяется для решения задачи публикации унаследованного веб-приложения через прокси-сервер с предварительной аутентификацией посредством MFA-механизмов Avanpost Identity Cloud без прохождения аутентификации от имени пользователя в целевом унаследованном веб-приложении.

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

  1. Пользователь обращается к унаследованному веб-приложению. Пользователю отображается веб-интерфейс аутентификации Avanpost Identity Cloud, реализующий заданный администратором сценарий MFA.
  2. После прохождения аутентификации пользователю отображается страница унаследованного веб-приложения. Если унаследованное веб-приложение требует дополнительной аутентификации, то пользователь видит форму аутентификации унаследованного веб-приложения.

Схема взаимодействия осуществляется следующим образом:

  1. Пользователь выполняет запрос на известный и доступный для него адрес целевого приложения https://webapp, который указывает на сетевой интерфейс Reverse Proxy Identity Cloud.
  2. Avanpost Identity Cloud при необходимости выполняет аутентификацию пользователя по настроенному сценарию MFA.
  3. Запрос проксируется на внутренний адрес https://internal-app, доступный для компонента Identity Cloud.
  4. Ответ на запрос принимается Avanpost Identity Cloud.
  5. Ответ на запрос возвращается пользователю.

Последующие запросы пользователя к унаследованному веб-приложению через механизм Reverse Proxy при наличии сессии выполняются без запроса аутентификации.

Режим «Базовый»

Данный режим применяется в ситуациях, когда на стороне целевого веб-приложения имеется парольная аутентификация посредством механизма HTTP Basic (RFC 7617), подразумевающего передачу учётных данных (логина и пароля) в HTTP Basic-заголовке. В ответе на этот запрос от унаследованного веб-приложения ожидается HTTP-заголовок Set-Cookie, Cookie из которого сохраняется в сессии и автоматически добавляется ко всем последующим запросам пользователя в адрес унаследованного веб-приложения.

Режим «Форма»

Данный режим аутентификации применяется в ситуациях, когда на стороне целевого веб-приложения используется классическая парольная аутентификация, эмулируемая посредством отправки HTTP POST-запроса. Передача логина и пароля учётной записи в унаследованном веб-приложении осуществляется в теле (HTTP Body) HTTP POST-запроса. В ответе на этот запрос от унаследованного веб-приложения ожидается HTTP-заголовок Set-Cookie, Cookie из которого сохраняется в сессии и автоматически добавляется ко всем последующим запросам пользователя в адрес унаследованного веб-приложения.

Режим «Пользовательский скрипт»

Данный режим аутентификации применяется в ситуациях, когда на стороне целевого веб-приложения для прохождения аутентификации требуется выполнение последовательности произвольных HTTP-запросов. Передача логина и пароля учётной записи в унаследованном веб-приложении осуществляется в произвольном HTTP-запросе или последовательности HTTP-запросов. В ответе на этот запрос от унаследованного веб-приложения ожидается произвольный сессионный параметр (Cookie, JWT-токен, Bearer Token и т.д.), значения из которого сохраняется в сессии и автоматически добавляется ко всем последующим запросам пользователя в адрес унаследованного веб-приложения.


Обсуждение