Un IAP (Identity-Aware Proxy) est un logiciel qui fonctionne généralement comme un proxy inverse ou comme un composant logiciel qui combine des fonctionnalités de proxy inverse et d’équilibrage de charge. Le rôle de l’IAP dans l’authentification des requêtes entrantes le différencie des composants architecturaux standard qui s’appuient exclusivement sur un système back-end ou un modèle d’authentification externe.
Cette section s’applique presque exclusivement à ArcGIS Enterprise. La plupart des processus ArcGIS Online n’interagissent pas directement avec un IAP, bien que les services externes ou les URL ajoutés en tant qu’éléments à ArcGIS Online puissent être protégés de cette manière.
Dans la plupart des déploiements faisant appel à un proxy inverse ou un équilibreur de charge, le composant fonctionne en grande partie en mode transparent : les demandes d’un client ne sont pas modifiées par le proxy de manière significative, mais sont transmises directement au système back-end, parfois avec l’ajout d’un en-tête de requête pour lui préciser que la demande a été effectuée via ce proxy. Dans ce type d’architecture, l’authentification auprès d’un système ArcGIS pour un utilisateur passant par le proxy inverse ou l’équilibreur de charge est fonctionnellement identique à celle d’un utilisateur qui accède directement au logiciel sans cette couche intermédiaire.
Lorsqu’un IAP est utilisé, le proxy inverse vérifie d’abord si l’utilisateur est authentifié en recherchant des informations d’identification ou un objet d’authentification, tel qu’un jeton, une clé API ou un cookie spécifique au site. Si ces éléments d’information n’existent pas ou ne sont pas valides, toute requête adressée au système back-end sera immédiatement redirigée vers un fournisseur ou un processus d’authentification basé sur les configurations IAP. Ce n’est qu’une fois que l’utilisateur s’est authentifié correctement auprès de ce fournisseur d’identités et qu’il est renvoyé à l’interface IAP avec un jeton de sécurité ou des informations d’identification valides, que sa requête est transmise au système back-end. Il est important de noter que cet identifiant de sécurité est conservé en dehors du système back-end, c’est-à-dire que le système back-end n’est généralement pas tenu informé de la session négociée par l’IAP de l’utilisateur. Dans un scénario où ArcGIS Enterprise est placé derrière un IAP, après la connexion initiale effectuée par l’IAP, l’utilisateur doit s’authentifier à nouveau auprès du fournisseur d’identités (IdP) spécifié par ArcGIS afin d’établir une session avec ArcGIS.
Bien qu’il soit possible de configurer de nombreux composants logiciels et systèmes pour prendre en charge les fonctionnalités propres à l’IAP (Identity-Aware Proxy), voici quelques exemples courants :
règle d’écouteur qui applique l’authentificationTout proxy inverse qui fournit une couche de « pré-authentification », ou qui nécessite le passage d’un jeton, d’un cookie ou d’autres informations d’identification, peut être considéré comme un IAP dans le cadre de l’architecture ArcGIS. Certains IAP sont plus ou moins configurables, peuvent autoriser des exemptions pour certaines URL ou fournir différentes méthodes d’authentification, allant de la simple connexion basée sur des formulaires aux options de connexion basées sur OpenID Connect et SAML.
Les IAP sont souvent utilisés pour protéger les applications Web et les points de terminaison publics personnalisés. Si un utilisateur accède principalement à une application Web via un navigateur Web et que les requêtes adressées aux API back-end appartiennent au même domaine que l’application, une connexion initiale peut être réutilisée par l’utilisateur pour effectuer d’autres requêtes. Certaines API back-end peuvent être conçues pour utiliser un en-tête ou une autre propriété de requête qui transite par l’IAP (comme une signature qui indique le nom de l’utilisateur), puis tirer parti de ces informations pour affecter le contenu ou la logique de la réponse de l’API.
La plupart des applications clientes ArcGIS, qu’il s’agisse d’applications Web, bureautiques ou mobiles, lancent l’authentification auprès d’ArcGIS via OAuth. Ce processus, qui implique l’inscription de l’application cliente auprès d’ArcGIS, l’exécution d’une session de connexion, la fourniture d’informations d’identification valides, puis l’utilisation du code de réponse pour générer un jeton, est cohérent pour chacun de ces types de clients. Ce processus de connexion OAuth implique plusieurs pages Web ou requêtes HTTP différentes. Il a lieu généralement dans un navigateur intégré (pour les applications natives) ou dans la même fenêtre de navigateur (pour les applications Web).
Le processus OAuth d’ArcGIS, en particulier l’utilisation dans l’application du jeton d’accès ArcGIS résultant, suppose que le client dispose d’un accès transparent au système back-end. En d’autres termes, les clients ArcGIS savent seulement comment s’authentifier auprès des systèmes ArcGIS, alors que le processus OAuth dans le navigateur peut renvoyer l’utilisateur vers un fournisseur d’identités SAML ou OIDC. Au final, le code OAuth généré est celui qui est retourné à l’utilisateur, et la fenêtre de navigateur supplémentaire pour les applications natives est fermée. Une fois la connexion OAuth terminée, le client s’attend à pouvoir transmettre des requêtes HTTP transparentes (y compris le jeton ArcGIS) vers des points de terminaison ArcGIS Online ou ArcGIS Enterprise pour un usage ultérieur. Les informations d’identification ou les sessions définies par le fournisseur d’identités ne sont plus utilisées ou considérées comme pertinentes pour ArcGIS. Dans un scénario mettant en jeu un IAP, celui-ci vérifie en permanence si chaque demandeur entrant s’est déjà authentifié auprès de l’IAP, ce qui peut entraîner plusieurs problèmes courants.
Dans un processus de connexion OAuth d’ArcGIS, il existe généralement deux propriétés configurées qui définissent le mode de lancement du processus OAuth : client_id et portal_url.
https://www.arcgis.com ou à un sous-domaine spécifique à l’organisation, tel que https://myorg.maps.arcgis.com.https://gis.mydomain.org/portal et inclut un nom de domaine et un contexte Web (/portal).Pour mener à bien ce processus, l’application cliente ArcGIS vérifie d’abord si l’URL configurée est un système ArcGIS Enterprise ou ArcGIS Online valide, en envoyant une requête telle que (portal_url) + /sharing/rest/info?f=json
Cette requête renvoie une brève réponse JSON qui identifie la version de l’API utilisée, afin de s’assurer que le système est une version prise en charge pour cette application cliente spécifique.
Lorsqu’une application ArcGIS demande à un utilisateur de fournir une URL ArcGIS Enterprise à laquelle se connecter, la requête initiale du client ArcGIS adressée à /sharing/rest/info?f=json renvoie souvent une réponse HTTP 302 redirigeant l’utilisateur vers la page de connexion de l’IAP.
Cela empêche l’application cliente ArcGIS d’accepter le point de terminaison comme valide, car il ne se présente pas comme un déploiement ArcGIS, mais comme une page de connexion HTML. Cela se traduit par un refus, car l’application cliente tente d’empêcher un site Web malveillant d’imiter un déploiement ArcGIS Enterprise : en simulant, par exemple, des fautes d’orthographe dans le nom de domaine pour demander des informations ou en demandant à l’utilisateur d’entrer ses informations d’identification sur ce site où elles pourraient être volées et utilisées à mauvais escient.
Pour les applications natives, y compris ArcGIS Pro et les applications mobiles ArcGIS, la connexion OAuth est effectuée via un navigateur intégré. Bien que la session IAP puisse être établie avec succès dans ce navigateur, une fois que ce navigateur se ferme, le cookie généralement défini (pour signaler que l’utilisateur s’est déjà authentifié auprès de l’IAP) est perdu. Les requêtes transmises directement à ArcGIS depuis l’application native seront alors bloquées et la réponse HTTP 302 sera renouvelée.
Plusieurs processus peuvent être combinés avec la fonctionnalité IAP lorsqu’ils sont soigneusement conçus.
Bien que les IAP constituent clairement une classe assez courante de protection des applications, on constate actuellement peu de normalisation ou de cohérence entre leurs implémentations. Cela rend la prise en charge d’un large éventail de systèmes de type IAP difficile à mettre en œuvre de manière fiable. Esri étudie la prise en charge future d’un plus grand nombre de processus basés sur un IAP à partir d’applications natives et s’efforcera d’assurer cette prise en charge sous la forme d’une méthode normalisée applicable à de nombreuses distributions de logiciels différentes à l’avenir.