SSO d'entreprise dans AAA Sentinel : guide pratique avec Auth0 (et ce qui change avec Microsoft Entra ID ou Okta)

AAA Sentinel voit des données sensibles : la facture de vos clouds, les comptes connectés, les dépenses en modèles d'IA et votre posture de sécurité. Quand l'équipe grandit, gérer les accès avec des mots de passe isolés ne tient plus : quelqu'un quitte l'entreprise et son accès reste actif, une autre personne a besoin de droits d'administrateur pendant une semaine et personne ne pense à les lui retirer. Le SSO d'entreprise règle ce problème en connectant AAA Sentinel à l'annuaire que votre entreprise utilise déjà.

Pourquoi utiliser le SSO d'entreprise

Avec le SSO activé, votre fournisseur d'identité (IdP) devient la seule porte d'entrée :

• Départs gérés en un seul endroit : vous désactivez la personne dans l'annuaire et elle ne peut plus se connecter à AAA Sentinel, sans toucher à la plateforme.
• Rôles synchronisés : chaque groupe de l'IdP correspond à un rôle (Administrateur, Approbateur, Finance ou Lecteur) et le rôle est recalculé à chaque connexion.
• Les politiques de votre entreprise s'appliquent aussi ici : MFA, accès conditionnel ou durée de session sont décidés par votre IdP.
• Domaine vérifié : seules les personnes ayant un e-mail sur un domaine dont vous avez prouvé le contrôle par un enregistrement DNS peuvent se connecter en SSO.
• Moins de mots de passe et moins de support : personne n'a à retenir un mot de passe de plus ni à demander sa réinitialisation.

Comment le configurer dans AAA Sentinel

Le SSO est disponible avec le plan Business et se configure par le propriétaire de l'organisation dans Gestion → Configuration, carte « SSO d'entreprise ». Cinq étapes :

• Choisissez le protocole, SAML ou OIDC. Il est figé à l'enregistrement ; pour le changer, il faut supprimer la configuration.
• Copiez dans votre IdP les valeurs affichées dans le panneau : en SAML, l'URL de réponse (ACS), l'identifiant d'entité et l'URL de déconnexion ; en OIDC, l'URL de redirection.
• Renseignez les données de l'IdP (l'URL des métadonnées en SAML ; issuer, client ID et secret en OIDC), le claim de l'e-mail, celui des groupes et la table groupe → rôle.
• Vérifiez votre domaine en publiant l'enregistrement TXT fourni par le panneau. La correspondance doit être exacte.
• Cliquez sur « Tester la connexion » : la page de connexion de votre IdP s'ouvre dans un autre onglet et confirme que tout répond, sans changer votre session. Quand tout est au vert, activez le SSO.

SAML ou OIDC : lequel choisir

Les deux protocoles fonctionnent. La différence tient aux détails :

• SAML : la déconnexion est complète (quitter AAA Sentinel ferme aussi la session de l'IdP) et les groupes voyagent comme un attribut multivalué. C'est l'option recommandée pour synchroniser les rôles avec Microsoft Entra ID ou Okta.
• OIDC : il demande moins de valeurs à configurer (issuer, client ID et secret). AAA Sentinel ferme aussi la session de l'IdP à condition que celui-ci publie un end_session_endpoint et accepte le client ID pour la fermer.
• Dans les deux cas, désactiver le SSO suspend les personnes qui se connectent par ce biais, car elles n'ont pas de mot de passe, et elles ne comptent plus comme un siège. Elles reviennent à la réactivation si elles tiennent encore dans le plan.

Cas pratique : Auth0 comme fournisseur d'identité

Nous avons testé l'intégration complète avec un tenant Auth0 gratuit, d'abord en SAML puis en OIDC. Ce qui est commun aux deux se fait une seule fois : une Action qui publie les rôles de chaque personne (Actions → Library → Build Custom, avec le trigger Login / Post Login) et les paramètres de l'application. La même Action sert pour les deux protocoles :

// Actions → Library → Build Custom → Login / Post Login
exports.onExecutePostLogin = async (event, api) => {
  const roles = event.authorization?.roles ?? []
  const joined = roles.join(',')

  // OIDC : claim avec namespace, dans l'ID token et l'access token (AAA Sentinel le lit dans userinfo)
  api.idToken.setCustomClaim('https://aaa-sentinel.com/groups', joined)
  api.accessToken.setCustomClaim('https://aaa-sentinel.com/groups', joined)

  // SAML : attribut multivalué "groups"
  if (api.samlResponse) api.samlResponse.setAttribute('groups', roles)
}

• Utilisez les Roles d'Auth0 (User Management → Roles) comme groupes : créez-en un pour chaque rôle à mapper et attribuez-le à chaque personne. Le nom du Role est exactement ce que vous saisirez ensuite dans le mapping du panneau.
• Allowed Callback URLs et Allowed Logout URLs acceptent plusieurs URL séparées par des virgules : avec celles du tableau, SAML et OIDC sont couverts. Cliquez sur Save Changes en bas de la page.

Auth0 en SAML

Dans l'onglet Addons de l'application, activez SAML2 Web App. Dans son onglet Settings, Application Callback URL est l'URL de réponse du panneau et le champ Settings reçoit ce JSON, avec le bloc logout pour la déconnexion unique :

{
  "audience": "<identifiant d'entité affiché dans le panneau>",
  "recipient": "https://auth.aaa-sentinel.com/saml2/idpresponse",
  "destination": "https://auth.aaa-sentinel.com/saml2/idpresponse",
  "nameIdentifierFormat": "urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress",
  "nameIdentifierProbes": [
    "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress"
  ],
  "logout": {
    "callback": "https://auth.aaa-sentinel.com/saml2/logout",
    "slo_enabled": true
  }
}

• L'URL des métadonnées se trouve dans l'onglet Usage de l'addon, sous Identity Provider Metadata : copiez-la avec clic droit → « copier l'adresse du lien ». Un clic normal télécharge le XML, alors que le panneau attend l'URL.

Auth0 en OIDC

En OIDC, aucun addon n'est nécessaire : l'application et l'Action ci-dessus suffisent. Voici les valeurs à saisir dans le panneau d'AAA Sentinel :

• L'issuer garde la barre oblique finale : c'est exactement la valeur qu'Auth0 publie comme issuer.
• Le secret ne peut pas être relu : saisissez-le à nouveau à chaque enregistrement de la configuration.
• AAA Sentinel lit les groupes depuis l'endpoint userinfo, pas seulement depuis l'ID token. C'est pourquoi l'Action publie un claim avec namespace, aussi dans l'access token, avec les rôles séparés par des virgules.
• Se déconnecter d'AAA Sentinel ferme aussi la session Auth0 via son end_session_endpoint. Pour cela, https://app.aaa-sentinel.com/login doit figurer dans les Allowed Logout URLs, comme dans le tableau de l'application.

Les erreurs qui nous ont fait perdre le plus de temps

Aucune n'est un bug de la plateforme, mais vues de l'extérieur elles se ressemblent toutes : « je me connecte, mais pas avec le bon rôle ». Voici la liste à vérifier :

• Des noms de groupe qui ne correspondent pas : le mapping tient compte des majuscules et du pluriel. Un rôle nommé finops-admin ne correspond pas à finops-admins, et la personne reçoit le rôle par défaut.
• L'Action déployée mais hors du flux : Auth0 n'envoie aucun groupe et tout le monde reçoit le rôle par défaut.
• Un e-mail hors du domaine vérifié : le SSO ne lui est pas proposé. Les utilisateurs de test ont besoin d'un e-mail sur le domaine, même sans boîte aux lettres.
• Des sessions de l'IdP qui restent ouvertes : si changer d'utilisateur vous connecte directement sans mot de passe, vérifiez que l'URL de déconnexion est autorisée dans l'IdP.

Et avec Microsoft Entra ID ou Okta ?

Les étapes dans AAA Sentinel sont les mêmes avec n'importe quel fournisseur ; c'est la configuration côté IdP qui change. Ce que nous avons fait dans Auth0 (l'Action et le namespace du claim) est propre à Auth0. Voici les points de vigilance avec les deux autres :

• Microsoft Entra ID : par défaut, il envoie les groupes sous forme d'Object ID (un GUID) et non de nom ; le mapping groupe → rôle se remplit donc avec ces identifiants, sauf si vous configurez le claim pour envoyer les noms. Les utilisateurs sans boîte aux lettres ont un e-mail vide : mappez l'e-mail sur l'UPN. Le domaine .onmicrosoft.com ne peut pas être vérifié ; il vous faut votre propre domaine. Et Entra ne renvoie pas les groupes dans userinfo : pour synchroniser les rôles, utilisez SAML.
• Okta : le claim des groupes se définit sur le serveur d'autorisation et doit être inclus pour n'importe quel scope, car AAA Sentinel ne demande que openid et email. Sa déconnexion OIDC exige un jeton que la plateforme ne conserve pas : en OIDC, la session Okta reste donc ouverte après la déconnexion ; en SAML, la déconnexion est complète.
• Avec n'importe quel fournisseur : utilisez « Tester la connexion » avant d'activer et connectez-vous avec un utilisateur de chaque groupe pour valider les rôles.

Checklist avant d'activer

Une fois tout cela en place, le jour où quelqu'un quitte l'entreprise, il suffit de le désactiver dans l'annuaire pour qu'il ne puisse plus se connecter. Si vous voulez aussi couper une session ouverte, retirez-le depuis Utilisateurs.

• Plan Business et accès en tant que propriétaire de l'organisation.
• Un domaine propre et l'accès à son DNS pour publier l'enregistrement TXT.
• Les groupes de l'IdP créés, avec les noms exacts que vous allez mapper.
• L'URL de réponse et l'URL de déconnexion enregistrées dans l'IdP.
• Le test de connexion au vert et trois utilisateurs de test validés.