Прокси-сервер с поддержкой идентификации (IAP) — это часть программного обеспечения, которая обычно работает как обратный прокси или как часть программного обеспечения, сочетающего возможности обратного прокси и балансировки нагрузки. Что отличает эту концепцию от стандартных архитектурных компонентов, так это роль IAP в аутентификации входящих запросов, а не то, чтобы полагаться исключительно на серверную систему или внешний шаблон аутентификации.
Этот раздел относится почти исключительно к ArcGIS Enterprise, большинство рабочих процессов ArcGIS Online напрямую yе взаимодействуют с прокси-сервером с поддержкой идентификации, хотя внешние сервисы или URL-адреса, добавленные в качестве элементов в ArcGIS Online, могут быть защищены таким образом.
В большинстве развертываний, где используется обратный прокси-сервер или балансировщик нагрузки, компонент работает в основном в прозрачном режиме, что означает, что запросы от клиента не редактируются и не изменяются прокси-сервером существенным образом, а перенаправляются непосредственно в серверную систему, иногда с добавлением заголовка запроса для идентификации серверной системе, что запрос был сделан через этот прокси-сервер. В этих архитектурах аутентификация в системе ArcGIS для пользователя, проходящего через обратный прокси-сервер или балансировщик нагрузки, функционально идентична аутентификации пользователя, который обращается к программному обеспечению напрямую, без этого промежуточного уровня.
При использовании IAP обратный прокси-сервер сначала проверяет аутентификацию пользователя по учетным данным или объекту аутентификации, такому как токен, ключ API или файл cookie для конкретного сайта, и если он отсутствует или недействителен, любой запрос к серверной системе будет немедленно перенаправлен поставщику аутентификации или процессу на основе конфигураций IAP. Только после того, как пользователь должным образом пройдет аутентификацию через этого поставщика учетных записей и будет возвращен в интерфейс IAP с действительным токеном безопасности или учетными данными, его запрос будет перенаправлен в серверную систему. Важно отметить, что этот идентификатор безопасности хранится за пределами серверной системы, т.е. серверная система обычно не знает о сеансе пользователя, согласованном с помощью IAP. Важно отметить, что это означает, что в сценарии, где ArcGIS Enterprise находится за IAP, после первоначального входа в систему, инициированного IAP, пользователю потребуется повторно пройти аутентификацию в IdP, указанном ArcGIS, чтобы установить сеанс с ArcGIS.
Хотя для поддержки функциональности, содержащейся в концепции прокси-сервера с поддержкой идентификации, можно настроить множество программных компонентов и систем, вот некоторые распространенные примеры:
правилом прослушивателя, которое принудительно выполняет аутентификациюФактически, любой обратный прокси-сервер, который обеспечивает уровень “предварительной аутентификации” или для прохождения которого требуется токен, файл cookie или другие учетные данные, может считаться прокси-сервером с поддержкой идентификации для целей обсуждения архитектуры ArcGIS. Некоторые IAP являются более или менее настраиваемыми, могут допускать исключения для определенных URL-адресов или могут предоставлять различные методы аутентификации, начиная от простого входа на основе форм и заканчивая вариантами входа на основе OpenID Connect и SAML.
IAP часто используются для защиты пользовательских общедоступных веб-приложений и конечных точек, где пользователь в основном получает доступ к веб-приложению через веб-браузер, а запросы к серверным API находятся в том же домене, что и приложение, поэтому первоначальный вход в систему может быть повторно использован пользователем для выполнения дальнейших запросов. Некоторые серверные API могут быть разработаны для использования заголовка или другого свойства запроса, проходящего через IAP (например, подписи, указывающей имя пользователя), а затем использовать эту информацию для изменения содержимого или логики ответа API.
Большинство клиентских приложений ArcGIS, будь то веб-, настольные или мобильные приложения, инициируют аутентификацию в ArcGIS через OAuth. Этот процесс, который включает регистрацию клиентского приложения в ArcGIS, начало сеанса входа, предоставление действительных учетных данных и последующее использование кода ответа для создания токена, согласован для каждого из этих типов клиентов. Этот процесс входа в систему OAuth включает несколько разных веб-страниц или HTTP-запросов и обычно происходит во встроенном браузере (для нативных приложений) или в одном окне браузера (для веб-приложений).
Процесс ArcGIS OAuth и, в частности, использование полученного токена доступа ArcGIS в приложении, предполагает, что клиент имеет прозрачный доступ к серверной системе. Иными словами, клиенты ArcGIS понимают только то, как аутентифицироваться в системах ArcGIS, в то время как процесс OAuth в браузере может включать отправку пользователя к поставщику удостоверений SAML или OIDC, в конечном итоге полученный код OAuth возвращается пользователю, а дополнительное окно браузера для нативных приложений закрывается. После завершения входа в OAuth клиент ожидает, что сможет отправлять прозрачные HTTP-запросы (включая токен ArcGIS) в конечные точки ArcGIS Online или ArcGIS Enterprise для дальнейшего использования, любые учетные данные или сеансы, установленные IDP, больше не используются и не считаются релевантными для ArcGIS. В IAP-сценарии IAP постоянно проверяет, был ли каждый входящий инициатор запроса ранее аутентифицирован с помощью IAP, что может привести к нескольким распространенным проблемам.
В процессе входа в систему ArcGIS OAuth обычно есть два настраиваемых свойства, которые определяют, как запустить процесс OAuth: client_id и portal_url.
https://www.arcgis.com или субдоменом, специфичным для организации, например https://myorg.maps.arcgis.com.https://gis.mydomain.org/portal, включая доменное имя и веб-контекст (/portal).Поведение клиентского приложения ArcGIS обычно сводится к тому, что сначала проверяется, является ли настроенный URL-адрес допустимым для системы ArcGIS Enterprise или ArcGIS Online, путем отправки запроса типа (portal_url) + /sharing/rest/info?f=json.
Этот запрос возвращает короткий ответ JSON, в котором указывается используемая версия API, чтобы убедиться, что система является поддерживаемой версией для этого конкретного клиентского приложения.
Когда приложение ArcGIS запрашивает у пользователя URL-адрес ArcGIS Enterprise для подключения, первоначальный запрос от клиента ArcGIS к /sharing/rest/info?f=json часто возвращает ответ 302 HTTP, перенаправляющий пользователя на страницу входа в IAP.
Это приводит к тому, что клиентское приложение ArcGIS не принимает конечную точку как действительную, поскольку она представляет себя не как развертывание ArcGIS, а как страницу входа в систему в формате HTML. Это приводит к отказу, поскольку клиентское приложение пытается помешать вредоносному веб-сайту имитировать развертывание ArcGIS Enterprise, например, если кто-то использует методы с ошибками в написании домена для запроса информации или просит пользователя ввести свои учетные данные на этом сайте, где они могут быть украдены и использованы не по назначению.
Для нативных приложений, включая ArcGIS Pro и мобильные приложения ArcGIS, вход в OAuth выполняется через встроенный браузер, и хотя сеанс IAP может быть успешно установлен в этом браузере, после закрытия этого браузера обычно устанавливаемый файл cookie (для идентификации пользователя как уже прошедшего аутентификацию в IAP) теряется, поэтому последующие запросы к ArcGIS, инициированные непосредственно из нативного приложения, блокируются с обновленным ответом 302.
При тщательном проектировании несколько рабочих процессов могут быть успешно объединены с функциональностью IAP.
Хотя прокси-серверы с поддержкой идентификации, несомненно, являются довольно распространенным классом защиты приложений, в настоящее время их реализации недостаточно стандартизированы или согласованы, что затрудняет надежную реализацию поддержки широкого спектра систем, подобных IAP. Esri изучает возможность дальнейшей поддержки большего числа рабочих процессов на основе IAP из собственных приложений и будет стремиться обеспечить поддержку в рамках широко реализуемого метода, основанного на стандартах, который в будущем может быть применен ко многим различным дистрибутивам программного обеспечения.