Comparez les attributions Okta aux usages réels.

Une application gère le SSO administrateur. L’intégration de service distincte fournit un accès en lecture seule pour synchroniser l’annuaire et les attributions d’applications, et pour vérifier le rôle administrateur lors de la connexion.

Non. elba se contente de lire Okta. Utilisez les éléments disponibles dans elba pour enquêter, puis modifiez le compte ou l’attribution dans la console d’administration Okta.

Non. Chaque attribution compte comme un accès pour cette personne et cette application, mais elle n’ouvre jamais d’alerte, ne reçoit aucun tag et ne modifie pas la politique d’utilisation de l’application.

L’intégration de service utilise okta.apps.read, okta.users.read, okta.roles.read et okta.groups.read. Les attributions d’applications utilisent ces autorisations existantes, sans nouveau consentement. Les dates de connexion nécessitent okta.logs.read, facultative et demandée sur un jeton distinct.

Effectuez la configuration avec un compte actif de super-administrateur ou d’administrateur d’application. Pour afficher les attributions, l’intégration de service doit disposer du rôle super-administrateur, administrateur de l’organisation ou administrateur en lecture seule, ou d’un rôle d’administrateur d’application non limité à certaines applications.

• Lorsque votre fournisseur d’identité elba est Google Workspace ou Microsoft 365, les attributions d’applications proviennent d’une application API Services Okta que vous connectez pour Third-Party Apps. Elle associe les utilisateurs Okta aux utilisateurs elba par adresse e-mail.
• Les dates de connexion nécessitent l’autorisation okta.logs.read. elba lit alors les connexions Okta réussies et ne conserve que la dernière connexion de chaque personne à chaque application qu’il enregistre comme attribution.
• Seules les applications Okta qu’elba peut associer avec certitude à son catalogue apparaissent ; les autres sont ignorées. Une application sans attribution Okta n’est pas gérée dans Okta, ce qui ne la rend pas, à elle seule, non autorisée ou risquée.
• L’intégration de service doit disposer du rôle super-administrateur, administrateur de l’organisation ou administrateur en lecture seule, ou d’un rôle d’administrateur d’application non limité à certaines applications. Sinon, elba ignore la synchronisation des attributions et n’ajoute ni ne supprime rien.
• elba n’écrit jamais dans Okta : il ne suspend pas les utilisateurs et ne modifie ni les attributions ni les rôles. La vérification du rôle administrateur autorise la connexion à elba ; elle ne constitue pas un inventaire des rôles.
• Le SSO et la synchronisation de l’annuaire utilisent des identifiants d’application distincts qui doivent tous rester correctement configurés.
• Les secrets client sont des identifiants de production et ne doivent jamais être placés dans des tickets, des captures d’écran ou le code source.
• Si les types d’application ou les libellés de la console Okta diffèrent de la configuration dans le produit, confirmez la procédure avant de créer une autre application de production.