SSO pour applications internes : mapper les claims SAML/OIDC vers rôles et équipes

Pourquoi le mapping des claims est important pour les applications internes

L’authentification unique semble simple : cliquer sur "Se connecter avec Okta" ou "Se connecter avec Azure AD" et vous êtes connecté. La difficulté commence après. Sans un mapping clair des claims, des personnes se retrouvent avec trop de droits (un support voit la paie) ou trop peu (un nouveau employé ne peut pas ouvrir l’outil nécessaire dès le premier jour).

Les applications internes sont plus délicates que les applications publiques parce qu’elles sont partagées entre des équipes et changent constamment. Un même outil peut être utilisé par le Support, la Finance et les Ventes en même temps. Les organigrammes bougent, des prestataires arrivent et partent, et des équipes sont renommées ou scindées. Si les règles d’accès ne vivent que dans les têtes des gens, le SSO se contentera de copier ce désordre dans votre application.

Le mapping des claims est la façon dont vous transformez les données d’identité fournies par votre fournisseur d’identité (IdP), comme les groupes, le département ou le poste, en permissions que votre app comprend. Concrètement, cela consiste souvent à décider :

• Quels rôles existent dans l’app (admin, manager, lecteur, etc.)
• À quelles équipes ou espaces de travail les utilisateurs appartiennent
• Ce que chaque rôle peut faire et ce que chaque équipe peut voir
• Qui obtient l’accès automatiquement et qui a besoin d’une approbation

Deux risques causent la plupart des problèmes :

• Mappages erronés. Un nom de groupe correspond au mauvais rôle, ou un groupe trop large « Tous les employés » accorde par accident des droits d’admin.
• Claims manquants. L’IdP n’envoie pas les groupes pour certains utilisateurs, un attribut est vide, ou le token est trop long et est tronqué.

Votre application a besoin de comportements par défaut sûrs pour que des données manquantes ou inattendues ne se transforment jamais en accès accidentel.

SAML vs OIDC en termes simples

Quand vous vous connectez avec le SSO, votre IdP envoie à l’application un petit paquet d’informations vous concernant. Chaque information est une claim, essentiellement un champ étiqueté comme "email = [email protected]" ou "department = Finance".

SAML et OIDC peuvent transporter des informations similaires, mais les emballent différemment.

SAML est courant dans les environnements d’entreprise plus anciens. Il envoie généralement un document XML (une assertion) avec des attributs. Ce sont ces attributs que votre app lit comme des claims.

OIDC est plus récent et basé sur OAuth 2.0. Il envoie typiquement un token JSON signé (un ID token) plus des informations utilisateur optionnelles, où les champs à l’intérieur du token sont les claims.

Pour les applications internes, vous vous souciez généralement d’un petit ensemble de claims :

• Adresse email
• Un identifiant utilisateur stable fourni par l’IdP (subject)
• Nom complet (ou prénom et nom)
• Adhésions aux groupes (équipes, groupes de sécurité)
• Département ou titre du poste

Une distinction évite beaucoup de confusion :

L’authentification répond à « qui est cet utilisateur ? » Des claims comme un ID utilisateur stable et l’email vous aident à relier la connexion SSO au bon compte.

L’autorisation répond à « que peut-il faire ? » Des claims comme les groupes ou le département vous aident à mapper l’utilisateur aux rôles et équipes dans l’app.

Deux personnes peuvent s’authentifier correctement, mais seul celle qui a la claim « Finance » doit pouvoir accéder à un écran de facturation.

Rôles et équipes : décidez ce que vous mappez

Avant de mapper des attributs SAML ou de convertir des claims OIDC en permissions, clarifiez deux choses dont votre app a besoin :

• Les rôles définissent ce qu’on peut faire (permissions).
• Les équipes définissent où on appartient (périmètre).

Les rôles répondent à des questions comme : cette personne peut-elle consulter, modifier, approuver, exporter, gérer des utilisateurs ou changer des paramètres ?

Les équipes répondent à : dans quel département, région, file ou centre de coûts travaille cette personne et quelles données doit-elle voir ?

Gardez les rôles petits et stables. La plupart des applications internes n’ont besoin que de quelques rôles qui changent rarement, même si les personnes bougent. Les équipes doivent refléter la réalité quotidienne : Support Tier 2, couverture EMEA, un responsable temporaire de file.

Le principe du moindre privilège est le comportement par défaut le plus sûr. Beaucoup d’apps internes se contentent de trois rôles :

• Viewer : peut lire les données et lancer des recherches
• Editor : peut créer et mettre à jour des enregistrements
• Admin : peut gérer les paramètres, les utilisateurs et les règles d’accès

Écrivez en langage clair ce que chaque rôle permet. Cela évite des « admins surprise » quand un nom de groupe change et facilite les revues ultérieures.

Accès basé sur les groupes : comment penser les groupes IdP

L’accès basé sur les groupes signifie que votre app ne décide pas des permissions utilisateur par utilisateur. Elle s’appuie sur l’IdP pour maintenir l’appartenance aux groupes, et votre app mappe ces groupes en rôles et équipes.

Commencez par décider ce qu’un groupe accorde. Dans beaucoup d’outils, un groupe correspond à un rôle (par exemple « Support Agent ») et éventuellement à une équipe (par exemple « Tier 2 »). L’important est que le mapping reste ennuyeux et prévisible : le même groupe signifie toujours le même accès.

Quand les utilisateurs sont dans plusieurs groupes

Les gens appartiennent souvent à plusieurs groupes IdP. Il faut une règle pour résoudre cela, et la garder stable.

Approches courantes :

• Règles additives : combiner les permissions de tous les groupes correspondants (utile quand les permissions sont étroitement limitées)
• Règles de priorité : choisir le groupe de plus haute priorité et ignorer les autres (utile quand les rôles sont conflictuels)
• Hybride : additionnel pour les équipes, priorité pour les rôles

Quel que soit votre choix, documentez-le. Le changer plus tard peut faire gagner ou perdre des accès aux utilisateurs soudainement.

Utilisez une convention de nommage extensible

Des noms de groupes clairs réduisent les erreurs et facilitent les audits. Un schéma pratique est :

• --

Par exemple : support-tool-prod-agent ou finance-tool-staging-viewer. Cela évite de réutiliser des noms vagues comme "Admins" sur plusieurs apps.

Si un utilisateur n’appartient à aucun groupe pertinent, par défaut n’accordez aucun accès (ou un état invité clairement limité) et affichez un message expliquant comment demander l’accès.

Liaison de compte : faire correspondre les utilisateurs SSO aux comptes de l’app

Le SSO prouve qui est une personne, mais votre app doit encore décider à quel compte existant rattacher cette identité. Sans liaison de compte, une même personne peut finir avec plusieurs comptes au fil du temps parce que les identifiants changent : nouvel email, mises à jour de nom, transferts entre filiales, changement d’IdP.

Choisissez une clé stable et unique comme correspondance principale.

• Pour OIDC, c’est généralement la claim sub (subject).
• Pour SAML, c’est souvent un NameID persistant ou un attribut utilisateur immuable dédié.

Stockez cette valeur comme « IdP user ID » avec l’ID d’émetteur/entity ID de l’IdP, afin qu’un même sub provenant d’un autre IdP ne puisse pas entrer en collision.

L’email est utile, mais traitez-le comme une clé de commodité, pas comme la source de vérité. Les gens changent d’email après des renommages, migrations de domaine ou fusions. Les alias et boîtes partagées peuvent aussi créer des correspondances surprenantes. Si vous faites une correspondance par email, ne la faites que lorsque le signal de l’IdP est vérifié, et envisagez une étape de confirmation ponctuelle.

Au premier login, la plupart des outils internes choisissent un des schémas d’onboarding :

• Auto-create : créer un compte immédiatement et attribuer un accès minimal.
• Invite-only : n’autoriser que les connexions pour des utilisateurs pré-créés (ou pré-approuvés) dans l’app.
• Flux d’approbation : créer le compte mais bloquer l’accès jusqu’à ce qu’un manager ou un admin approuve le rôle/l’équipe.

Un comportement sûr par défaut est l’auto-création sans permissions par défaut, puis l’attribution d’accès basée sur les groupes ou une étape d’approbation.

Étape par étape : mapper les claims vers rôles et équipes

Un bon mapping rend le SSO invisible : les gens se connectent et tombent au bon endroit avec le bon accès.

Commencez par écrire votre modèle d’accès en langage clair. Listez chaque rôle (Viewer, Agent, Manager, Admin) et chaque équipe (Support, Finance, IT), plus qui doit les obtenir et pourquoi.

Puis confirmez ce que votre IdP peut réellement envoyer. Pour SAML ou OIDC, vous voulez typiquement un ID utilisateur stable (subject ou NameID), l’email et une ou plusieurs claims de groupe. Capturez les valeurs exactes des groupes telles qu’elles apparaissent, y compris la casse et les préfixes. "Support" et "support" ne sont pas identiques.

Un flux pratique :

• Définissez rôles et équipes, et désignez un responsable pour chaque (quelqu’un qui peut approuver les changements).
• Listez les claims disponibles et les noms de groupes exacts fournis par l’IdP, y compris les cas limites (contractuels, boîtes partagées).
• Rédigez les règles de mapping : groupe-vers-rôle, groupe-vers-équipe, et un ordre d’override quand plusieurs groupes correspondent.
• Testez avec 3 à 5 types d’utilisateurs réels (nouveau, manager, prestataire, admin) en utilisant de vrais comptes IdP.
• Pour chaque utilisateur de test, écrivez d’abord le rôle/l’équipe attendus, puis connectez-vous et comparez.

Gardez un petit exemple pour rendre les règles concrètes. Si un utilisateur est dans "okta-support", il devient équipe Support et rôle Agent. S’il est aussi dans "okta-support-managers", le rôle Manager remplace Agent.

Enfin, ajoutez un moyen simple de déboguer. Journalisez les claims bruts reçus (en sécurité), les règles qui ont matché, et le rôle/l’équipe final. Quand quelqu’un dit « Je me suis connecté, mais je ne vois pas mon outil », cela transforme une partie de devinette en vérification rapide.

Comportements sûrs quand des claims manquent

Les claims manquants sont normaux. L’IdP peut ne pas envoyer les groupes pour les comptes de service, un connecteur peut omettre un champ, ou un utilisateur peut être en migration. Traitez « pas de données » comme « pas de confiance ».

Le comportement le plus sûr est le refus par défaut : aucun rôle, aucune équipe, aucun accès. Si vous devez permettre l’entrée pour qu’un utilisateur demande l’accès, limitez-la en lecture seule et indiquez clairement les restrictions.

Choisissez un comportement et documentez-le :

• Bloquer la connexion avec un message clair : "Votre compte n’a aucun accès assigné. Contactez le support."
• Autoriser un accès limité avec un avertissement et désactiver les actions sensibles.
• Créer l’enregistrement utilisateur mais n’attribuer aucun rôle/équipe jusqu’à approbation.

Ne donnez jamais le rôle d’admin par défaut, même temporairement.

Prévoyez des traitements pour les données partielles. Si vous recevez un email mais pas de groupes, vous pouvez quand même créer un compte et le router vers approbation. Si vous recevez des groupes mais pas d’identifiant stable, évitez l’auto-liaison à un compte existant car cela peut rattacher la mauvaise personne.

Ayez une voie d’escalade pour les échecs :

• Un responsable nommé (IT ou admin de l’app) qui peut approuver l’accès
• Un flux d’attribution manuelle avec note d’audit
• Un moyen de revérifier les claims à la prochaine connexion
• Un délai d’expiration pour les comptes en « attente d’accès »

Gérer les changements, suppressions et offboarding

Les gens changent d’équipe, de manager et quittent l’entreprise. Votre configuration SSO doit traiter cela comme normal.

Quand quelqu’un change d’équipe, mettez à jour l’accès à la prochaine connexion : réévaluez les claims de groupe et appliquez le mapping courant. Évitez les accès « collants » qui restent parce qu’ils ont été accordés une fois.

Les départs sont différents. Attendre la prochaine connexion n’est pas suffisant. Vous voulez que leur accès se termine rapidement, même s’ils ont encore une session active. Cela signifie généralement désactiver le compte dans l’IdP, et votre app doit traiter une identité désactivée ou absente comme immédiatement bloquée.

La déprovision devrait être prévisible : désactiver l’utilisateur, retirer les appartenances aux équipes, et conserver les données d’audit. Il est souvent nécessaire de préserver des enregistrements comme les approbations, commentaires et historiques pour la conformité, tout en bloquant les nouvelles actions.

Les prestataires et accès temporaires méritent une attention particulière. Placez-les dans des groupes limités dans le temps dans l’IdP, ou attachez une date de révision à leur rôle pour que l’accès ne persiste pas après la fin d’un projet.

Une politique pratique d’offboarding :

• Réévaluer les claims à chaque connexion et rafraîchir l’appartenance aux équipes depuis l’IdP
• Quand un utilisateur est retiré des groupes requis, supprimer les privilèges immédiatement (au prochain login ou à la prochaine synchro)
• Désactiver le compte tout en conservant les pistes d’audit et l’historique de propriété
• Exiger une date de fin pour l’accès des contractuels et la revoir avant renouvellement
• Faire des revues périodiques des accès pour les rôles sensibles comme finance ou admin

Erreurs courantes et pièges à éviter

La plupart des incidents SSO ne viennent pas du fait que SAML ou OIDC soient « difficiles ». Ils arrivent parce que l’app fait des hypothèses peu sûres sur les personnes, les groupes et les identifiants.

Une erreur fréquente est de confondre mapping de rôle et mapping d’équipe. Les rôles sont « que pouvez-vous faire ? » Les équipes sont « où appartenez-vous ? » Si vous mappez un groupe d’équipe directement sur un rôle puissant comme Admin, vous accordez souvent un accès large à quiconque se trouve dans cette équipe.

Un autre piège est de s’appuyer sur l’email comme unique identifiant pour la liaison de compte. Les emails changent, et les alias peuvent créer des doublons. Préférez un IdP user ID stable (comme sub/NameID) comme clé primaire et utilisez l’email pour l’affichage et les notifications.

Autres problèmes fréquents :

• S’ouvrir quand les groupes manquent (par défaut, pas d’accès ou accès limité, pas plein accès)
• Noms de groupes peu clairs réutilisés entre dev, staging et production
• Traiter l’appartenance à un groupe comme une simple liste de permissions sans revoir la signification de chaque groupe
• Ne pas gérer les utilisateurs multi-équipes qui ont besoin d’accès à plusieurs zones sans devenir admin
• Oublier les partenaires et contractuels qui doivent être isolés des équipes réservées aux employés

Testez les cas limites avant le lancement. Un analyste finance en réponse à incident peut avoir besoin de deux équipes et d’un rôle élevé. Si vos règles n’autorisent qu’une équipe, il perdra l’accès ou se verra sur-permissionné.

Checklist rapide avant le lancement

Avant d’activer le SSO pour tout le monde, faites une répétition avec quelques comptes de test par équipe. La plupart des problèmes d’accès apparaissent immédiatement quand vous testez un nouveau recrutement, un changement de rôle et un cas d’offboarding.

Commencez par la liaison de compte. Choisissez un identifiant unique qui ne changera pas dans le temps, et tenez-vous-y. En OIDC c’est généralement sub. En SAML c’est souvent NameID ou un attribut immuable spécifique.

Ensuite, décidez de ce qu’il se passe quand des claims sont absents. Le comportement le plus sûr est de ne pas accorder d’accès élevé (et souvent aucun accès) quand les claims de groupe ou de rôle sont absents ou vides. Assurez-vous d’avoir au moins un rôle à faible privilège qui permet d’entrer sans exposer des actions sensibles, si cela correspond à votre flux.

Une checklist de pré-lancement simple :

• Confirmez que votre identifiant de liaison est stable et unique (et visible dans les logs)
• Vérifiez que l’absence de claim de groupe n’accorde pas plus d’accès qu’un rôle à faible privilège
• Exigez qu’un accès admin corresponde à un groupe admin explicite, plus une seconde étape d’approbation (même manuelle)
• Testez la suppression : quand un utilisateur quitte un groupe, son accès diminue au prochain login (ou à la prochaine synchro)
• Rédigez les règles de mapping pour qu’un collègue puisse les comprendre en une page

Exemple : un outil interne Support & Finance avec groupes SSO

Imaginez un outil opérationnel utilisé quotidiennement par le Support, la Finance et quelques managers. Vous voulez que les gens se connectent et obtiennent immédiatement les bons écrans et actions sans qu’un admin corrige manuellement les comptes.

Créez quelques groupes IdP et mappez-les aux rôles et équipes de l’app :

• ops-support -> Rôle : Support Agent, Équipe : Support
• ops-finance -> Rôle : Finance Analyst, Équipe : Finance
• ops-managers -> Rôle : Manager, Équipe : Management

Voici comment cela se déroule.

Maintenant un cas de changement d’email : Omar passe de [email protected] à [email protected]. Parce que l’app lie les comptes en utilisant l’IdP user ID stable (comme sub pour OIDC ou un NameID persistant pour SAML) plutôt que l’email, il n’obtient pas de compte dupliqué. Il conserve le même historique et la même piste d’audit.

Pour vérifier l’accès sans deviner, conservez une vue "effective access" qui montre l’identité IdP liée de l’utilisateur, les groupes reçus, le rôle résultant et l’équipe. Quand quelque chose semble incorrect, vous pouvez rapidement dire si c’est un problème IdP, une règle de mapping ou une claim manquante.

Prochaines étapes : garder l’accès prévisible quand l’organisation évolue

Le plus difficile n’est pas le premier lancement, mais de conserver un accès sain après les réorganisations, l’apparition de nouvelles équipes et les exceptions « temporaires ».

Gardez un document de mapping d’une page qui répond :

• Quels groupes IdP correspondent à quels rôles et équipes dans l’app
• Quel est le comportement par défaut quand une claim est manquante (et qui approuve les changements)
• Qui possède chaque rôle à risque élevé (admin finance, admin utilisateurs, export de données)
• Comment sont gérés les contractuels et comptes de service
• Où se trouve la source de vérité (IdP vs app)

Lancez un petit pilote avec un département aux frontières claires, corrigez les cas limites, puis étendez sans inventer de nouvelles règles. Mettez en place une revue récurrente des accès pouvant causer de réels dégâts : mensuelle pour les rôles admin et à risque élevé, trimestrielle pour les rôles normaux.

Si vous développez l’app interne vous-même, il est utile que rôles, équipes et logique métier restent proches pour que les changements soient faciles à tester. AppMaster (appmaster.io) est une option pour les équipes qui veulent modéliser visuellement les rôles et workflows et régénérer du code backend, web et mobile réel au fur et à mesure que les besoins évoluent, sans accumuler de correctifs ponctuels pour les permissions.