Passer au contenu principal
Ce guide suppose que vous utilisez Okta comme fournisseur d’identité d’entreprise (IdP) et que vous disposez d’un accès administratif à un locataire Okta que vous pouvez utiliser à des fins de test. Si ce n’est pas le cas, consultez Créer et configurer votre locataire Okta.
La connexion d’applications tierces et d’agents d’IA dans une entreprise pose deux problèmes majeurs : une visibilité limitée des TI sur le partage des données et des demandes de consentement répétées pour les utilisateurs. Cross App Access (XAA) répond à ces défis en permettant aux administrateurs TI de définir de façon centralisée des contrôles d’accès qui encadrent la façon dont les applications SaaS, comme les agents d’IA, se connectent pour le compte d’un utilisateur. Les administrateurs gèrent ces connexions dans une console centralisée, comme la console d’administration Okta, ce qui élimine les demandes de consentement OAuth intrusives pour les utilisateurs finaux. Il en résulte une meilleure sécurité organisationnelle, une meilleure gouvernance et une meilleure expérience utilisateur. XAA met en œuvre le Identity Assertion Authorization Grant, une extension d’OAuth en cours d’élaboration qui permet à un agent d’IA ou à une application (application demandeuse) d’obtenir un jeton sécurisé par l’intermédiaire de l’IdP d’entreprise. Ce jeton permet à l’application demandeuse d’appeler les API d’une autre application (application ressource) pour le compte de l’utilisateur final. Pour en savoir plus, consultez Fonctionnement.

​
Principaux avantages

XAA offre des avantages clés pour chaque rôle de votre écosystème d’entreprise :
  • Pour les administrateurs informatiques d’entreprise : contrôle centralisé, visibilité et application des stratégies pour l’accès des applications aux données d’entreprise et aux données des utilisateurs.
  • Pour les fournisseurs SaaS et les développeurs : intégration normalisée et sécurisée de l’IA d’entreprise afin de favoriser la croissance de l’écosystème.
  • Pour les utilisateurs finaux : connexions simplifiées et fluides entre les applications, sans les flux complexes de consentement OAuth.

​
Cas d’utilisation

Les cas d’utilisation courants de XAA incluent :
  • Connecter des agents d’IA à des applications d’entreprise : un employé utilise un agent d’IA pour consulter son application de calendrier et publier une mise à jour sur sa disponibilité dans l’application de messagerie de l’entreprise. Au lieu d’obliger l’employé à passer par des flux de redirection et des demandes de consentement, l’agent d’IA utilise XAA pour obtenir un jeton d’accès auprès de l’IdP de l’entreprise afin d’appeler de façon sécurisée les API de l’application de calendrier et de l’application de messagerie, si la stratégie d’accès de l’entreprise l’autorise.
  • Connecter des applications SaaS : dans notre exemple précédent, l’application de calendrier d’entreprise et l’application de messagerie prennent toutes deux en charge XAA. Les employés peuvent connecter en toute transparence l’application de messagerie pour accéder à l’API de l’application de calendrier, sans redirection de l’utilisateur ni consentement, tout en respectant les stratégies d’accès de l’entreprise.

​
Fonctionnement

Le flux XAA fait intervenir les acteurs suivants :
  • Application demandeuse : l’application ou l’agent d’IA qui doit accéder à une ressource.
  • Application ressource : l’application qui possède la ressource protégée et l’expose au moyen d’une API
  • IdP d’entreprise : l’IdP, comme Okta, qui authentifie les employés.
Une fois que l’utilisateur final s’est authentifié auprès de l’IdP d’entreprise, l’application demandeuse communique avec celui-ci pour demander l’accès à l’application ressource au nom de l’utilisateur. Après avoir appliqué sa stratégie d’accès pour vérifier si cette connexion interapplication est autorisée, l’IdP d’entreprise génère une assertion appelée ID-JAG, que l’application demandeuse présente ensuite à l’application ressource afin d’obtenir un jeton d’accès pour consommer l’API.  Dans le schéma suivant, Acme est l’entreprise cliente dont les employés s’authentifient auprès de leur IdP d’entreprise, comme Okta, pour accéder à l’application demandeuse (Agent0) et à l’application ressource (Todo0) :
  • Le serveur d’autorisation de l’application ressource (Todo0) est fédéré avec l’IdP d’entreprise par l’entremise d’OIDC afin de pouvoir générer des jetons d’accès pour les utilisateurs finaux authentifiés par cet IdP.
  • L’application demandeuse (Agent0) est enregistrée auprès du serveur d’autorisation de l’application ressource comme application OAuth 2.0 avec un client_id valide et les informations d’identification nécessaires pour demander des jetons d’accès au serveur d’autorisation de l’application ressource.
  • L’administrateur TI d’Acme a défini des contrôles d’accès XAA entre Agent0 et Todo0.

​
Flux XAA de bout en bout

En reprenant notre exemple Acme, le flux XAA de bout en bout se déroule comme suit :
  1. L’employé d’Acme se connecte à l’application demandeuse (Agent0) au moyen du SSO avec l’IdP d’entreprise. L’application demandeuse obtient un jeton d’identité pour vérifier l’identité de l’employé d’Acme.
  2. L’application demandeuse envoie à l’IdP une demande d’échange de jeton pour échanger le jeton d’identité contre un octroi d’autorisation JWT d’assertion d’identité interdomaines, aussi appelé ID-JAG. L’IdP valide la demande et vérifie la stratégie XAA définie par l’administrateur TI d’Acme.
  3. Si la stratégie XAA l’autorise, l’IdP renvoie l’ID-JAG à l’application demandeuse.
  4. L’application demandeuse envoie une demande de jeton au serveur d’autorisation de l’application ressource (Todo0) en utilisant l’ID-JAG.
  5. Le serveur d’autorisation de l’application ressource valide l’ID-JAG à l’aide de la clé publique qu’il utilise également pour son flux OpenID Connect avec l’IdP. S’il est valide, le serveur d’autorisation renvoie un jeton d’accès.
  6. L’application demandeuse envoie une requête à l’API de l’application ressource avec le jeton d’accès.
En tirant parti du flux XAA, les stratégies définies par l’administrateur TI d’Acme régissent l’accès d’Agent0 à Todo0, sans nécessiter de redirection ni d’interaction de l’utilisateur final.

​
Limitations de la version bêta

La version bêta de XAA présente les limitations suivantes :
  • L’application demandeuse doit être une application confidentielle et une application de première partie dans votre locataire Auth0. Les applications publiques, comme les SPA et les applications natives, ne sont pas prises en charge.
  • L’administration déléguée n’est pas prise en charge. Le client d’entreprise ne peut pas configurer directement de connexions SSO dans votre locataire Auth0. La prise en charge du SSO en libre-service est prévue dans une version ultérieure.
  • Il ne peut y avoir qu’une seule connexion XAA activée par émetteur d’IdP en amont. Le même locataire Okta ne peut pas être utilisé pour plus d’une connexion d’entreprise activée pour XAA.
  • La prise en charge des organisations est limitée :
    • Une connexion est associée en 1:1 à une Organisation. Plusieurs organisations ne peuvent pas être associées à la même connexion pour l’accès XAA.
    • Lorsque l’application demandeuse est configurée pour exiger l’utilisation d’organisations, les utilisateurs doivent déjà être membres de l’organisation cible.
  • Si le paramètre resource n’est pas indiqué dans la requête ID-JAG, l’API cible est déterminée par tenant.default_audience.
  • Aucune création dynamique d’utilisateur : l’utilisateur doit déjà s’être connecté à votre application ressource à l’aide de la connexion Okta configurée. Sinon, la demande d’échange de l’assertion ID-JAG contre un jeton d’accès échouera avec une erreur User not found.

​
Limites de taux

Dans la version bêta de XAA, les échanges ID-JAG sur le point de terminaison /token de votre locataire Auth0 sont soumis à une limite de 5 RPS.