Connecter Okta

Elba se connecte à Okta de l’une de ces deux façons :

• Okta comme fournisseur d’identité Elba : deux configurations d’application Okta, l’une pour la connexion de l’administrateur et l’autre comme intégration de service pour la synchronisation de l’annuaire et des attributions d’applications.
• Okta pour Third-Party Apps uniquement, lorsque votre fournisseur d’identité Elba est Google Workspace ou Microsoft 365 : une application API Services Okta qui lit les attributions d’applications et les connexions. Consultez Connecter Okta avec une application API Services.

Périmètre de cette connexion

La connexion à l’annuaire synchronise les utilisateurs actifs affectés à l’application SSO Elba, les groupes Okta et les appartenances des utilisateurs synchronisés dans Elba. La présence d’un utilisateur dans votre annuaire Okta ne suffit pas à l’importer.

L’intégration de service lit également les applications Okta attribuées à chaque personne synchronisée dans Elba, directement ou via un groupe Okta, ainsi que le mode de connexion de chaque application : SSO fédéré (SAML, OpenID Connect ou WS-Federation), coffre-fort de mots de passe (SWA) ou favori (bookmark). Dans Third-Party Apps :

• chaque attribution apparaît avec la mention Attribuée dans Okta pour cette personne et cette application. Elle compte comme un accès, mais n’ouvre jamais d’alerte, ne reçoit aucun tag et ne modifie pas la politique d’utilisation de l’application ;
• lorsqu’une application fédérée dans Okta est attribuée à une personne, sa méthode de connexion indique le SSO via Okta au lieu d’un mot de passe déduit de l’activité e-mail ;
• les filtres Géré dans Okta et Non géré dans Okta distinguent les applications attribuées dans Okta de celles utilisées hors d’Okta par au moins 5 personnes, sans attribution Okta ;
• une fois qu’Elba lit les connexions Okta, chaque attribution Okta indique la dernière connexion de la personne via Okta, et la vue Attribué, sans connexion Okta depuis 90 jours liste les applications attribuées à quelqu’un il y a plus de 90 jours qui ne s’y est pas connecté via Okta depuis : des attributions candidates au retrait.

Seules les applications Okta qu’Elba peut associer avec certitude à son catalogue d’applications apparaissent ; les autres sont ignorées. Elba lit les attributions après chaque synchronisation de l’annuaire Okta. Consultez Applications gérées dans Okta.

Les dates de connexion nécessitent un champ d’application de lecture supplémentaire : consultez Connexions Okta. La vérification du rôle administrateur sert à autoriser la connexion à Elba, pas à dresser un inventaire des rôles.

Elba n’écrit jamais dans Okta : il ne modifie ni les attributions ni les rôles et ne désactive aucun utilisateur. Gérez les comptes, les groupes et les attributions dans la console d’administration Okta.

Rôles Okta requis

Effectuez la configuration avec un compte super-administrateur ou administrateur d’application actif.

Pour afficher les attributions d’applications, l’intégration de service doit elle-même disposer d’un rôle administrateur capable de lire toutes les applications : super-administrateur, administrateur de l’organisation, administrateur en lecture seule ou administrateur d’application non limité à certaines applications. Sans l’un de ces rôles, Elba ignore la synchronisation des attributions et ne modifie rien : aucune attribution n’est ajoutée ni supprimée. La synchronisation de l’annuaire continue normalement. Une application API Services nécessite le même rôle ; administrateur en lecture seule suffit.

Informations à préparer

Le processus de configuration d’Elba vous demande :

• votre domaine Okta ;
• l’adresse e-mail de l’administrateur ;
• l’ID client et le secret client de l’application SSO ;
• l’ID client et le secret client de l’intégration de service.

L’intégration de service doit être autorisée à lire :

okta.apps.read
okta.users.read
okta.roles.read
okta.groups.read

L’application SSO demande okta.users.read.self pour l’administrateur connecté.

Les attributions d’applications utilisent okta.apps.read et okta.roles.read de cette liste : elles ne demandent aucune autorisation ni aucun consentement supplémentaire. Les connexions nécessitent okta.logs.read, qui est facultatif : consultez Connexions Okta.

Connecter Okta

1. Ouvrez le processus de configuration Okta fourni par Elba.
2. Saisissez votre domaine Okta et l’adresse e-mail de l’administrateur.
3. Créez ou sélectionnez les applications SSO et de service en suivant les instructions affichées dans le produit pour votre environnement.
4. Accordez à l’intégration de service les quatre champs d’application en lecture ci-dessus et, pour afficher les attributions d’applications, l’un des rôles administrateur indiqués plus haut.
5. Copiez les ID et secrets clients dans les champs Elba correspondants.
6. Envoyez la configuration et connectez-vous via Okta lorsque vous y êtes invité.
7. Configurez votre espace Elba et attendez la fin de la synchronisation initiale de l’annuaire.

Si les libellés de la console Okta ou les types d'application diffèrent des instructions affichées dans votre espace Elba, interrompez la procédure et contactez le support Elba avant de créer une seconde application de production.

Connexions Okta

Pour afficher la date de dernière connexion de chaque personne à ses applications attribuées, accordez okta.logs.read à l’intégration de service :

1. Dans la console d’administration Okta, ouvrez Applications > Applications et sélectionnez l’intégration de service Elba.
2. Dans l’onglet Okta API Scopes, accordez okta.logs.read.

Elba demande ce champ d’application sur un jeton distinct : les attributions d’applications continuent de fonctionner sans lui. Tant qu’Elba n’a lu aucune connexion depuis une semaine, il vérifie ce champ d’application une fois par semaine, le lundi : les connexions apparaissent donc dans la semaine qui suit son attribution. Tant qu’il n’est pas accordé, le journal système Okta peut afficher chaque lundi la demande de jeton refusée à Elba.

Ce qu’Elba lit :

• les événements d’authentification unique réussis (user.authentication.sso) du journal système Okta : d’abord sur les 89 derniers jours, dans la limite des 90 jours conservés par Okta, puis chaque jour, ainsi que l’historique de 89 jours d’une application lorsqu’Elba commence à y enregistrer des personnes attribuées ;
• de ces événements, Elba ne conserve que la date de dernière connexion de chaque personne à chaque application qu’il enregistre comme attribution Okta, et rien d’autre ;
• par salves séparées de pauses, qui laissent l’essentiel de la limite de débit du journal système à vos autres outils, comme votre SIEM.

Les applications favorites (bookmark) n’ont pas de connexion à lire : elles n’apparaissent jamais comme inutilisées. Les dates de connexion s’affichent tant qu’Elba continue de les lire : s’il n’en a lu aucune depuis une semaine, par exemple parce que le champ d’application a été retiré, la vue et les dates de connexion sont masquées.

Connecter Okta avec une application API Services

Cette connexion s’adresse aux organisations dont le fournisseur d’identité Elba est Google Workspace ou Microsoft 365. Okta figure dans Third-Party Apps > Sources.

Elle lit les mêmes attributions d’applications et connexions que la connexion via le fournisseur d’identité, grâce à une application API Services Okta que vous créez. Elba associe chaque utilisateur Okta à l’utilisateur Elba qui a la même adresse e-mail : son identifiant Okta lorsqu’il s’agit d’une adresse e-mail, sinon l’e-mail de son profil.

1. Dans la console d’administration Okta, ouvrez Applications > Applications, sélectionnez Create App Integration et choisissez API Services.
2. Sous Client Credentials, réglez Client authentication sur Public key / Private key et ajoutez une clé : générez-en une dans Okta et copiez la clé privée au format JWK, ou enregistrez la clé publique d’une paire de clés RSA que vous avez générée.
3. Décochez Require Demonstrating Proof of Possession (DPoP) header in token requests : la connexion ne prend pas en charge DPoP.
4. Dans l’onglet Okta API Scopes, accordez okta.apps.read, okta.users.read, okta.roles.read et okta.logs.read.
5. Dans l’onglet Admin roles, attribuez le rôle Read-only Administrator. Sans rôle administrateur, Okta répond par des listes vides au lieu d’une erreur : Elba ne trouverait aucune application.
6. Dans Elba, ouvrez Third-Party Apps > Sources et sélectionnez Connecter à côté d’Okta. Saisissez votre domaine Okta sans https:// ni -admin (par exemple acme.okta.com), l’ID client de l’application et sa clé privée au format JWK.

Avant de lire quoi que ce soit, Elba vérifie la connexion :

• Seuls les comptes administrateurs sont pris en charge sur Okta signifie que l’application n’a aucun rôle administrateur capable de voir toutes les applications Okta : consultez l’étape 5 ;
• L'intégration n'a pas été autorisée à se connecter avec Okta signifie qu’Okta a refusé les requêtes de l’application : vérifiez les champs d’application de l’étape 4.

Une fois la connexion validée, les attributions et les connexions se synchronisent chaque jour.

Connexion à Browser Security sur Safari

Safari utilise la même application SSO Okta et les mêmes identifiants clients que les autres parcours de connexion elba. Avant de déployer Browser Security sur Safari, ouvrez cette application OIDC existante dans Okta et vérifiez la présence des deux entrées suivantes dans les URI de redirection de connexion :

• https://login.eu.elba.security/auth-verify/okta
• https://login.eu.elba.security/api/oauth/extension/callback

Conservez la première URI et ajoutez la seconde ; ne remplacez ni l'application existante ni son secret. Effectuez ensuite une connexion Safari complète avec un utilisateur pilote. Le callback Safari est également affiché dans le Deployment Center de Browser Security.