Un proxy consciente de la identidad (IAP) es un elemento de software que generalmente funciona como proxy inverso, o como parte de un elemento de software que combina las funcionalidades de proxy inverso y equilibrio de carga. Lo que hace que este concepto sea diferente de esos componentes arquitectónicos estándar es el rol del IAP en la autenticación de las solicitudes entrantes, en lugar de depender exclusivamente de un sistema backend o de un patrón de autenticación externo.
Este tema se aplica casi exclusivamente a ArcGIS Enterprise; la mayoría de los flujos de trabajo de ArcGIS Online no interactúan directamente con un proxy consciente de la identidad, aunque los servicios externos o las URL agregadas como elementos a ArcGIS Online podrían protegerse de este modo.
En la mayoría de las implementaciones en las que se utiliza un proxy inverso o un equilibrador de carga, el componente funciona en gran medida en modo transparente, lo que significa que las solicitudes de un cliente no son editadas ni modificadas por el proxy de forma significativa, sino que se reenvían directamente al sistema backend, a veces con la adición de un encabezado de solicitud para identificar al sistema backend que la solicitud se realizó a través de este proxy. En estas arquitecturas, la autenticación en un sistema ArcGIS para un usuario que pasa por el proxy inverso o el equilibrador de carga es funcionalmente idéntica a la de un usuario que accede directamente al software sin esta capa intermedia.
Cuando se utiliza un IAP, el proxy inverso comprueba primero si el usuario se está autenticado buscando una credencial u objeto de autenticación, como un token, una clave de API o una cookie específica del sitio, y si no está presente o no es válida, cualquier solicitud al sistema backend se redireccionará inmediatamente a un proveedor o proceso de autenticación basado en las configuraciones del IAP. Solo después de que el usuario se haya autenticado correctamente a través de ese proveedor de identidad, y sea devuelto a la interfaz IAP con un token de seguridad o una credencial válidos, se reenviará su solicitud al sistema backend. Es importante destacar que este identificador de seguridad se mantiene fuera del sistema backend, es decir, el sistema backend no suele tener conocimiento de la sesión negociada con el IAP del usuario. Es importante destacar que esto significa que en un escenario en el que ArcGIS Enterprise se coloca detrás de un IAP, después del inicio de sesión inicial iniciado por el IAP el usuario tendría que volver a autenticarse en el IdP especificado por ArcGIS para establecer una sesión con ArcGIS.
Aunque pueden configurarse otros muchos componentes de software y sistemas para admitir la funcionalidad contenida en el concepto de proxy consciente de la identidad, mencionamos algunos ejemplos comunes a continuación:
regla de escucha que impone la autenticaciónEn efecto, cualquier proxy inverso que proporcione una capa de «preautenticación», o que requiera un token, una cookie u otra credencial para pasar, puede considerarse un proxy consciente de la identidad a efectos de las discusiones sobre la arquitectura de ArcGIS. Algunos IAP son más o menos configurables, pueden permitir exenciones para determinadas URL o proporcionar otros métodos de autenticación, que van desde el simple inicio de sesión basado en formularios hasta las opciones de inicio de sesión basadas en OpenID Connect y SAML.
Los IAP se utilizan con frecuencia para proteger aplicaciones y extremos web personalizados de cara al público, en los que un usuario accede principalmente a una aplicación web a través de un navegador web y las solicitudes a las API backend están en el mismo dominio que la aplicación, por lo que un inicio de sesión inicial puede ser reutilizado por el usuario para realizar otras solicitudes. Algunas API de backend se pueden desarrollar para consumir un encabezado u otra propiedad de la solicitud que pase por el IAP (como una firma que indique el nombre del usuario) y luego utilizar esa información para influir en el contenido o la lógica de la respuesta de la API.
La mayoría de las aplicaciones cliente de ArcGIS, ya sean web, de escritorio o basadas en dispositivos móviles, inician la autenticación en ArcGIS a través de OAuth. Este proceso, que implica registrar la aplicación cliente en ArcGIS, iniciar una sesión de conexión, proporcionar credenciales válidas y, a continuación, utilizar el código de respuesta para generar un token, es coherente en cada uno de estos tipos de clientes. Este proceso de inicio de sesión OAuth implica varias páginas web o solicitudes HTTP diferentes y suele producirse dentro de un navegador integrado (para las aplicaciones nativas) o en la misma ventana del navegador (para las aplicaciones web).
El proceso ArcGIS OAuth, y en concreto el uso del token de acceso a ArcGIS resultante en la propia aplicación, presupone que el cliente tiene acceso transparente al sistema backend. Dicho de otro modo, los clientes de ArcGIS solo saben cómo autenticarse en los sistemas ArcGIS: aunque el proceso de OAuth en el navegador puede incluir el envío del usuario a un proveedor de identidad SAML u OIDC, al final el código OAuth resultante que se genera es lo que se devuelve al usuario, y la ventana adicional del navegador para las aplicaciones nativas se cierra. Una vez completado el inicio de sesión OAuth, el cliente espera poder enviar solicitudes HTTP transparentes (incluido el token de ArcGIS) a los extremos de ArcGIS Online o ArcGIS Enterprise para su uso posterior, cualquier credencial o sesión establecida por el IdP ya no se utiliza ni se considera relevante para ArcGIS. En un escenario con IAP, este comprueba constantemente si cada solicitante entrante se ha autenticado previamente contra el IAP, lo que puede dar lugar a varios problemas comunes.
En un proceso de inicio de sesión OAuth de ArcGIS, suele haber dos propiedades configuradas que guían cómo iniciar el proceso OAuth: el client_id y el portal_url.
https://www.arcgis.com o un subdominio específico de la organización como https://myorg.maps.arcgis.com.https://gis.mydomain.org/portal, que incluye un nombre de dominio y un contexto web (/portal).El comportamiento de la aplicación cliente de ArcGIS suele plantear este proceso comprobando en primer lugar si la URL configurada es un sistema válido de ArcGIS Enterprise o ArcGIS Online, enviando una solicitud como la siguiente (portal_url) + /sharing/rest/info?f=json`
Esta solicitud devuelve una breve respuesta JSON que identifica la versión de la API utilizada, para garantizar que el sistema es una versión admitida para esa aplicación cliente específica.
Cuando una aplicación ArcGIS pide a un usuario que proporcione una URL de ArcGIS Enterprise a la que conectarse, la solicitud inicial del cliente ArcGIS a /sharing/rest/info?f=json devolverá con frecuencia una respuesta HTTP 302 redireccionando al usuario a la página de inicio de sesión del IAP.
Esto provoca que la aplicación cliente de ArcGIS no acepte el extremo como válido, ya que no se representa a sí mismo como una implementación de ArcGIS, sino como una página de inicio de sesión HTML. El resultado es una denegación, ya que la aplicación cliente está intentando evitar que un sitio web malicioso imite una implementación de ArcGIS Enterprise como, por ejemplo, que alguien utilice técnicas de confusión de dominios para solicitar información o que pida al usuario que introduzca sus credenciales en ese sitio, donde podrían ser robadas y utilizadas indebidamente.
En el caso de las aplicaciones nativas, incluidas ArcGIS Pro y las aplicaciones móviles de ArcGIS, el inicio de sesión OAuth se completa a través de un navegador integrado; aunque la sesión del IAP puede establecerse correctamente en ese navegador, después de que este se cierre se pierde la cookie que generalmente se establece (para identificar al usuario como que ya se ha autenticado en el IAP), por lo que las solicitudes posteriores a ArcGIS iniciadas directamente desde la aplicación nativa se bloquean con una respuesta 302 renovada.
Es posible combinar correctamente varios flujos de trabajo con las funciones del IAP si se diseñan con cuidado.
Aunque los proxies conscientes de la identidad son claramente una clase bastante común de protección de aplicaciones, actualmente hay poca estandarización o coherencia entre sus implementaciones, lo que hace que la compatibilidad con un amplio conjunto de sistemas similares al IAP sea difícil de admitir de forma fiable. Esri está investigando la futura admisión de más flujos de trabajo basados en el IAP desde aplicaciones nativas y tratará de ofrecer asistencia en un método de implementación común y basado en estándares que pueda aplicarse a otras muchas distribuciones de software futuras.