Une fédération peut afficher « connexion réussie » alors que l’application ouvre le mauvais client, conserve un rôle obsolète ou rapproche deux personnes sur leur seule adresse email. WSO2 Identity Server dispose des briques pour connecter des fournisseurs d’identité, gérer des organisations, provisionner des comptes et protéger des APIs. La difficulté consiste à leur donner un ordre et un propriétaire dans le système réel.
Le vrai enjeu consiste donc à partir d’une ressource métier et d’un refus attendu. Quelle organisation tente de lire quelle donnée ? Quel fournisseur a authentifié la personne ? Quelle source attribue le rôle ? Quel composant décide du scope et quel délai maximal accepte-t-on après un départ ? Ces questions révèlent rapidement si WSO2, la gateway et le backend portent trois versions différentes de la même autorisation.
Contre-intuitivement, ajouter un protocole ne réduit pas nécessairement cette ambiguïté. OIDC ou SAML transportent une identité et des attributs ; SCIM transporte un cycle de vie ; un access token transporte des permissions déclarées. Aucun de ces objets ne remplace le contrat qui relie issuer, subject, organisation, compte métier, rôle et ressource protégée.
Le cadrage traite les décisions d’architecture et d’exploitation. Pour auditer une installation, construire les mappings, intégrer les applications et sécuriser les APIs, notre accompagnement d’intégrateur WSO2 Identity Server prend en charge l’implémentation et la recette. Les principes communs restent regroupés dans notre expertise d’intégration API sur mesure.
Le contrat de mise en œuvre précise en entrée l’identité et l’organisation attendues, en sortie le verdict API, les responsabilités de WSO2, de la gateway et du backend, puis les dépendances nécessaires au monitoring et au rollback. Cette fiche accompagne chaque application critique au lieu de rester une note générale sur la plateforme.
Choisir le rôle de WSO2 dans la sécurité des APIs
WSO2 Identity Server peut agir comme service de tokens et appliquer lui-même un contrôle d’accès. Les APIs définissent alors leurs ressources et permissions sous forme de scopes ; les applications reçoivent les scopes qui correspondent aux rôles autorisés ; le serveur de ressources vérifie le token avant l’action. Cette architecture convient lorsqu’aucune plateforme d’API distincte ne porte déjà la politique.
Il peut aussi agir comme fournisseur d’identité et service de tokens derrière WSO2 API Manager, Choreo ou une autre gateway. Identity Server authentifie et émet ; la plateforme d’API interprète le token et applique l’autorisation. Cette séparation est utile quand la gateway gouverne déjà exposition, quotas, routage et politiques, mais elle devient dangereuse si les deux produits maintiennent des règles concurrentes sans propriétaire commun.
La décision doit être écrite endpoint par endpoint. WSO2 vérifie l’identité et peut accorder un scope ; la gateway protège l’entrée ; le backend conserve les règles qui dépendent d’un contrat, d’un plafond, d’un propriétaire de dossier ou d’un état opérationnel. Un scope invoice.read ne dit pas encore quelles factures de quelle organisation cet utilisateur peut lire.
Le schéma d’architecture indique donc le composant qui authentifie, celui qui valide le token, celui qui décide du scope et celui qui tranche l’autorisation métier. Une flèche sans verdict explicite cache souvent un double contrôle. Une panne de WSO2 ne doit jamais conduire la gateway ou l’API à inventer un droit par défaut.
Inventorier version, topologie et personnalisations avant la reprise
Le nom « WSO2 Identity Server » ne décrit pas suffisamment une installation. Il faut relever la version réellement déployée, le mode d’hébergement, les nœuds, domaines, URLs tenant-aware, certificats, magasins de clés, user stores, bases de données, proxies et mécanismes de cache. Les capacités et écrans de documentation peuvent évoluer ; le périmètre doit toujours être confirmé sur l’environnement visé.
L’inventaire fonctionnel liste les applications, connections, fournisseurs d’identité, organisations, claims, scopes, rôles, groupes, méthodes MFA, workflows de récupération et règles de session. Pour chacun, on note le propriétaire métier, la dernière modification connue et les applications consommatrices. Une configuration inutilisée peut pourtant rester appelée par un ancien client ou une tâche technique.
Les personnalisations méritent une piste distincte : scripts de login, connecteurs, thèmes, extensions Java, services externes, tâches de provisioning et transformations de claims. Leur simple présence n’est pas une preuve d’usage. On recherche les appels, les logs et les décisions qu’elles produisent avant de les conserver, les extraire ou les supprimer d’une trajectoire de migration.
Le livrable n’est pas une capture de console. C’est une carte versionnée qui relie chaque objet WSO2 à ses consommateurs, secrets, certificats, dépendances et moyens de test. Elle doit permettre à une personne nouvelle dans l’équipe d’expliquer pourquoi une application reçoit un claim ou refuse un token sans modifier la production pour enquêter.
Modéliser organisations, utilisateurs et comptes métier
Le modèle d’organisation sert les applications B2B où une organisation racine partage des applications avec des partenaires ou clients. Une personne peut être connue dans plusieurs contextes, et WSO2 sait gérer des organisations ainsi que le partage d’utilisateurs. Ce modèle IAM ne doit pas être confondu avec toutes les notions de client, établissement, entité juridique ou abonnement du produit.
Chaque relation reçoit une clé durable. L’issuer et le subject identifient l’identité chez le fournisseur externe ; l’identifiant WSO2 désigne son compte local éventuel ; l’identifiant d’organisation situe le contexte d’accès ; l’identifiant métier pointe vers le compte réellement servi. L’email reste un attribut de contact ou de découverte, pas une clé globale de fusion.
Il faut aussi décider la portée des groupes et des rôles. Un groupe réunit des utilisateurs qui partagent certains privilèges dans une organisation, tandis qu’un rôle porte des permissions. Une appartenance dans l’organisation A ne doit jamais être réutilisée dans l’organisation B parce que le nom du groupe coïncide. Les imports, caches et exports doivent conserver cette portée.
La source de vérité varie selon l’objet. L’annuaire RH peut faire foi pour le statut d’emploi ; WSO2 pour le facteur authentifié et la session ; l’application pour l’abonnement, le propriétaire du dossier et l’autorisation contextuelle. Le tableau des responsabilités précise aussi qui a le droit d’effacer, qui peut seulement enrichir et quelle preuve confirme la propagation.
Acheminer chaque utilisateur vers la bonne organisation
Une application B2B peut commencer le login depuis l’organisation racine, puis demander à l’utilisateur d’identifier son contexte. WSO2 documente plusieurs formes de découverte : handle lisible, nom, identifiant, domaine email ou attribut personnalisé. L’application peut aussi appeler directement le chemin d’une organisation lorsqu’elle connaît déjà le contexte grâce à un sous-domaine, une invitation ou un portail dédié.
Le choix influence sécurité et expérience. Le domaine email réduit les frictions pour des entreprises dont les domaines sont stables, mais il gère mal les consultants, domaines partagés et acquisitions. Le handle est explicite mais doit être communiqué. L’identifiant interne est précis pour une intégration serveur, pas pour une saisie humaine. Un attribut personnalisé exige une gouvernance claire de sa valeur.
La documentation actuelle distingue un modèle amélioré d’authentification par organisation et une approche legacy fondée sur la fédération. Une reprise ne doit pas copier des URLs ou paramètres d’un tutoriel sans vérifier le modèle activé par l’application. La trajectoire précise ce qui reste legacy, ce qui migre et comment les deux parcours sont testés pendant la coexistence.
Le contre-test le plus important utilise une personne légitime dans deux organisations. Le parcours doit proposer ou imposer le bon contexte, émettre un token cohérent et partitionner données, caches, jobs asynchrones et logs. Changer d’organisation exige une nouvelle décision ; remplacer un identifiant côté frontend ne suffit pas.
Fédérer OIDC ou SAML sans perdre l’identité source
Une connection OIDC ou SAML établit la confiance avec un fournisseur externe. Elle définit endpoints, identifiants, certificats ou clés, redirect URLs, attributs reçus et méthode de logout. La première preuve attendue n’est pas une page qui s’ouvre, mais la capacité à relier chaque réponse à la configuration, au fournisseur et à l’application qui l’ont produite.
Le couple issuer-subject reste la clé de rapprochement la plus robuste lorsqu’il est disponible et stable. Fusionner sur l’email crée des collisions entre annuaires, permet des changements de propriétaire et casse les identités renommées. Si une migration doit réunir deux subjects, l’association devient une opération contrôlée avec auteur, date, anciennes clés et possibilité de revenir en arrière.
Les claims sont une projection, pas une copie du profil complet. Pour OIDC, les scopes déterminent les attributs exposés ; pour SAML, les mappings façonnent l’assertion. Chaque claim possède un nom local, une source, une transformation, une portée et des consommateurs autorisés. Les données sensibles ou volatiles restent dans leur référentiel si le token n’en a pas besoin.
Un claim inconnu ne doit pas devenir une valeur par défaut généreuse. Une organisation absente bloque le parcours ou le place en revue ; un rôle non reconnu n’accorde aucun privilège ; une valeur nulle suit une règle distincte de l’absence. Le mapping est versionné et testé avec plusieurs fournisseurs afin qu’une correction pour l’un ne modifie pas silencieusement les autres.
Distinguer JIT, SCIM entrant et provisioning sortant
Le Just-in-Time provisioning intervient après une authentification fédérée positive. WSO2 peut alors créer un compte local avec les attributs reçus. Le JIT simplifie la première connexion, mais il ne représente pas à lui seul le cycle de vie : un salarié qui ne se reconnecte jamais peut rester présent après son départ si aucune autre source ne porte la désactivation.
Les APIs SCIM 2.0 gèrent notamment utilisateurs, groupes, filtres, opérations PATCH et traitements en volume. Elles conviennent lorsqu’un système amont doit créer, modifier ou désactiver les identités avant ou indépendamment du login. Le contrat précise l’identifiant externe, les attributs maîtrisés par la source, la sémantique d’un PATCH, la pagination et le comportement face à un utilisateur déjà existant.
Le provisioning sortant pousse des événements de cycle de vie depuis WSO2 vers des systèmes connectés. Il peut être configuré au niveau de l’organisation ou de l’application, et filtré selon les groupes. Le sens du flux doit être explicite : une création reçue par SCIM peut déclencher une propagation, tandis qu’une mise à jour locale peut toucher plusieurs cibles. Sans graphe d’effets, un changement simple provoque boucle ou écrasement.
JIT et SCIM peuvent coexister si leur règle de rapprochement est commune. Le premier login ne doit pas créer un compte parallèle à celui préparé par le RH. Après timeout, le worker relit l’utilisateur ou le groupe avant de rejouer. La quarantaine conserve source, identifiant, opération, version du mapping, erreur et prochaine action ; elle ne devient jamais un stockage permanent d’exceptions.
Relier rôles, scopes et ressources API
Les rôles WSO2 contrôlent des permissions sur les fonctions du serveur et peuvent aussi soutenir l’accès aux applications et APIs. Les groupes facilitent l’attribution de rôles à plusieurs personnes. Les ressources API et scopes expriment les capacités offertes à une application. Ces concepts doivent être traduits vers des verbes métier précis plutôt que vers des profils génériques comme « admin ».
Une matrice utile part de l’action : consulter un contrat, exporter des données, modifier une adresse de paiement, inviter un administrateur. Elle indique le scope technique, le rôle nécessaire, l’organisation, les conditions métier supplémentaires et le propriétaire de la décision. Le backend vérifie encore le dossier, son état et son rattachement, même lorsque le token contient un scope valide.
Les rôles d’organisation et les rôles d’application n’ont pas la même portée. Un nom identique ne garantit pas la même permission. Lors du partage d’une application vers des sous-organisations, la recette vérifie quelles ressources et quels rôles sont hérités ou attribués. Un utilisateur partagé ne doit pas transporter davantage de droits que ceux prévus dans le contexte cible.
Le refus est un résultat fonctionnel observable. Il distingue token absent, token invalide, scope insuffisant, organisation incohérente et règle métier non satisfaite, tout en gardant le message public sobre. Cette classification permet au support de séparer une attaque, une configuration cassée et un comportement normal sans exposer la politique de sécurité au client.
Arbitrer signature JWT et introspection
La validation locale vérifie la signature du JWT avec les clés publiques exposées par le JWKS, puis contrôle issuer, audience, dates et claims attendus. Elle évite un appel réseau sur chaque requête et convient aux endpoints où la latence et la disponibilité priment, à condition de gérer cache, kid, rotation et rejet des algorithmes inattendus.
L’introspection interroge WSO2 sur l’état d’un access token et renvoie notamment s’il est actif. Elle ajoute une dépendance distante mais peut prendre en compte un token révoqué. Pour une opération sensible, cette fraîcheur peut être préférable à une validation purement cryptographique. La stratégie peut combiner validation locale et contrôle distant selon le risque.
La décision ne doit pas rester dans une librairie partagée invisible. Chaque famille d’endpoints documente le type de token accepté, l’audience, les scopes, le mode de validation, la durée de cache, le fallback et le comportement lorsque WSO2 ne répond pas. « Continuer avec la dernière décision positive » est une autorisation nouvelle ; elle exige une justification de risque.
Exemple concret : si le seuil de fermeture d’un export sensible impose un refus immédiat après révocation, alors cet endpoint utilise l’introspection ou un contrôle d’état équivalent ; une lecture de catalogue peut conserver la signature locale lorsque sa fenêtre de risque est explicitement acceptée. Le choix répond au dommage possible, pas à une préférence de librairie.
- À faire d’abord : classer les endpoints par impact et fraîcheur maximale du droit.
- À valider ensuite : issuer, audience, signature, dates, organisation et scopes sur des tokens contradictoires.
- À différer : le cache agressif tant que la latence réelle ne justifie pas d’allonger la fenêtre.
- À refuser : toute politique qui autorise par défaut pendant une panne d’introspection ou de JWKS.
Prouver révocation, logout et fermeture des accès
Révoquer un access token, terminer une session WSO2 et fermer la session applicative sont trois effets distincts. Un logout dans le navigateur peut laisser un token utilisé par un autre client ; une révocation peut ne pas effacer un cookie local ; une désactivation d’utilisateur peut rester masquée par un cache de gateway. Le runbook suit chaque couche séparément.
Le test part d’un utilisateur actif, crée une session et accède à une ressource sensible. Il retire ensuite un rôle, désactive le compte ou révoque le token, puis mesure le temps jusqu’au refus à l’entrée, dans la gateway et dans le backend. Le résultat attendu dépend du contrat, mais le délai observé ne doit jamais rester inconnu.
Les refresh tokens et sessions longues réclament une attention particulière. Un access token court ne ferme pas le parcours si un refresh encore valide en obtient un nouveau. La procédure inventorie les jetons, sessions, caches et appareils concernés, puis choisit révocation ciblée ou fermeture globale. Elle conserve une preuve sans stocker les secrets.
La métrique « délai de fermeture » relie identité et risque métier. Elle commence au signal faisant foi — départ RH, retrait de rôle, incident de sécurité — et se termine au premier refus démontré sur l’action cible. Cette mesure est plus utile qu’un simple nombre de sessions révoquées, car elle expose les files, caches et dépendances qui retardent réellement la décision.
Faire évoluer WSO2 sans bloquer les montées de version
Une plateforme IAM accumule facilement des changements dans la console, des fichiers de configuration, des extensions et des scripts de déploiement. Notre dossier consacré à l’administration de WSO2 par API détaille le pilotage des applications, utilisateurs et objets SCIM ; la trajectoire de fédération identifie ensuite ce qui appartient au produit standard, à une configuration supportée ou à une personnalisation.
WSO2 propose un modèle d’extensions orienté services pour exécuter certaines logiques hors du cœur du produit. Cette approche peut réduire le couplage d’une personnalisation, mais sa disponibilité et ses points d’extension dépendent de la version réellement exploitée. Le projet vérifie la documentation correspondante avant de promettre un hook, un événement ou un comportement.
La logique métier durable reste de préférence dans un service explicite. Une extension d’authentification peut enrichir ou refuser un parcours ; elle ne doit pas devenir un ERP miniature caché dans le login. Le contrat fixe timeout, authentification du service, payload minimal, idempotence, repli, métriques et réponse sûre lorsque la dépendance échoue.
Avant une montée de version, on rejoue les parcours critiques, compare les métadonnées OIDC ou SAML, contrôle claims et scopes, teste les rotations de certificats et mesure les temps de fermeture. La bascule maintient un chemin de retour qui ne réactive ni ancienne clé compromise ni ancienne politique trop large.
Erreurs fréquentes : éviter une seconde vérité IAM
La première erreur consiste à copier tous les attributs dans WSO2 « au cas où ». Les profils deviennent alors un référentiel parallèle, mis à jour par JIT, SCIM, console et application. Le remède est un dictionnaire de données minimal : source, sens d’écriture, fraîcheur, valeur absente, droit d’effacement et consommateurs pour chaque claim.
La deuxième consiste à considérer l’email comme identité universelle. Deux fournisseurs peuvent remettre la même adresse à des subjects différents ; une adresse peut être renommée ou réattribuée. Le rapprochement conserve toujours la source et l’identifiant externe. Une fusion manuelle laisse une trace et ne détruit pas les anciennes clés tant que la migration n’est pas validée.
La troisième consiste à assimiler réponse HTTP et état final. Un appel SCIM accepté peut être suivi d’un effet sortant en erreur ; un login fédéré réussi peut échouer pendant le JIT ; un token valide peut manquer du scope métier. La recette relit les objets finaux et l’action protégée plutôt que d’interpréter un seul statut intermédiaire.
Enfin, les retries aveugles amplifient les incidents. Rejouer une création après timeout peut fabriquer un doublon ; remplacer un utilisateur complet peut effacer un attribut plus récent ; relancer tout un groupe peut surcharger la cible. Le worker emploie une clé liée à l’effet métier, relit l’état, applique backoff et gigue, puis isole seulement le dossier fautif.
Plan d’action : construire une recette contradictoire
La démonstration heureuse ne couvre qu’une identité, un fournisseur, une organisation et un rôle stables. La recette utile introduit les contradictions que le support rencontrera : homonyme entre IdP, email renommé, organisation inconnue, groupe retiré, claim inattendu, JIT rejoué, SCIM partiel, clé tournée, token révoqué et gateway privée de WSO2.
Chaque cas décrit l’état initial, l’appel, le résultat attendu, la preuve technique, le verdict métier et le propriétaire de la correction. Les fixtures conservent des identifiants synthétiques et des valeurs non sensibles. Elles sont rejouées sur une version contrôlée, puis sur l’environnement cible pour valider URLs, certificats et comportements réellement activés.
Exemple concret : si le seuil de dossiers SCIM sans verdict est dépassé dans la quarantaine, alors le lot suivant reste fermé. Le support reprend d’abord un utilisateur à partir de la source, de l’identifiant externe et de la version du mapping ; il ne relance pas toute la population pour masquer l’écart.
{
"source": "partner-oidc",
"issuer": "<issuer>",
"subject": "<stable-subject>",
"organizationId": "<expected-org>",
"requestedAction": "contract.export",
"expectedDecision": "deny",
"reason": "role-revoked"
}Valider la sortie du pilote avec le support
Trois tests bloquent la production. L’utilisateur multi-organisation ne doit jamais voir une donnée de l’autre contexte. Le départ doit conduire au refus dans le délai annoncé, y compris avec une session et un refresh existants. La rotation de clé doit être absorbée par le JWKS sans accepter une signature invalide ni provoquer une coupure générale.
La sortie du pilote exige enfin un exercice conduit par une personne du support. À partir d’un ticket et d’un correlation ID, elle retrouve organisation, IdP, subject, mapping, session, token et décision. Si elle doit demander une requête ad hoc au développeur ou modifier directement une base, l’exploitation n’est pas prête.
Pour qui rendre la fédération exploitable
Le tableau de bord suit les échecs par étape : découverte, redirection vers l’IdP, retour de fédération, mapping des claims, JIT, SCIM, émission du token, validation, introspection et autorisation métier. Une moyenne globale masque l’étape qui casse ; une série par application, organisation et fournisseur révèle les régressions sans exposer les données sensibles.
Les indicateurs rapprochent technique et décision : comptes sans source durable, mappings rejetés, doublons en attente, écarts de groupes, tokens actifs après retrait, délais de fermeture, erreurs JWKS, latence d’introspection et refus par motif. Chaque seuil désigne une équipe, une procédure et un délai d’action. Une alerte sans owner reste une donnée de plus.
Le runbook commence par ce que connaît le demandeur : application, organisation, adresse de contact, heure et action refusée. Il fixe le seuil d’alerte, la file de quarantaine, les règles de retry et d’idempotence, les dépendances consultées, la journalisation et le repli. Le monitoring confirme en sortie le refus ou la reprise ; le rollback restaure une configuration connue sans réactiver un token ou un rôle retiré.
Une équipe peut intégrer seule un SSO simple et isolé. L’intervention devient pertinente lorsque plusieurs IdP, organisations, user stores, APIs ou cycles de provisioning se croisent, ou lorsqu’une migration doit préserver la continuité. Un projet d’intégration WSO2 API doit alors livrer architecture, mappings, matrice d’autorisation, contre-tests, monitoring et passation — pas seulement une configuration de console.
Guides complémentaires pour approfondir l’architecture
Ces ressources prolongent les décisions WSO2. Elles ne remplacent ni la documentation correspondant à votre version, ni les essais sur votre topologie réelle.
Choisir entre SAML et OpenID Connect
La comparaison SAML ou OpenID Connect pour une intégration B2B aide à choisir la confiance, les métadonnées, les tokens et le type de client adaptés. Elle sépare le protocole d’authentification du modèle d’organisation et du cycle de provisioning.
Ce repère est particulièrement utile pendant une coexistence : application historique en SAML, API protégée par OAuth2 et nouveau portail en OIDC peuvent partager une identité sans partager exactement les mêmes claims ni les mêmes procédures de logout.
Automatiser le cycle de vie avec SCIM
Le dossier SCIM : arrivée, mobilité et départ des utilisateurs détaille clés, opérations, groupes, idempotence et rapprochement. Il complète le JIT lorsque les identités doivent évoluer sans attendre une nouvelle connexion.
Il permet aussi d’écrire le critère de fermeture : un statut reçu ne suffit pas tant que le compte, les groupes, les sessions et l’endpoint sensible ne reflètent pas la décision dans le délai convenu.
Isoler les données d’un SaaS multi-tenant
L’analyse du multi-tenant SaaS étend le contrôle au-delà du token. Elle vérifie filtres de lecture, clés de cache, messages asynchrones, exports et journaux lorsque la même personne change d’organisation.
Cette grille empêche de considérer l’identifiant d’organisation présent dans le token comme une protection automatique : chaque accès aux données doit encore porter et vérifier le contexte attendu.
Fermer réellement une session compromise
Le dossier sur la révocation de tokens distingue expiration, révocation, cache et session applicative. Il aide à choisir signature locale, introspection ou contrôle complémentaire selon la sensibilité de l’action.
Appliqué à WSO2, il transforme la sécurité en délai observable : on part du retrait du rôle ou du signal d’incident, puis on mesure le moment où chaque couche refuse effectivement l’accès.
Conclusion : fédérer une identité, pas une ambiguïté
WSO2 Identity Server peut fédérer plusieurs sources, organiser des parcours B2B, provisionner des utilisateurs et émettre les tokens qui protègent les APIs. Sa richesse ne remplace pas les décisions d’architecture. Le rôle du serveur, le modèle d’organisation, les clés de rapprochement et la source de chaque droit doivent rester lisibles hors de la console.
Le critère de qualité le plus exigeant se trouve dans le retrait. Une équipe maîtrise son IAM lorsqu’elle sait expliquer pourquoi une action a été autorisée, puis prouver dans quel délai elle devient impossible après une mobilité, un départ ou une révocation. Cette preuve traverse IdP, WSO2, gateway, backend, cache et données métier.
Si votre projet doit relier WSO2 à plusieurs applications ou reprendre une plateforme existante, notre expertise WSO2 Identity Server, fédération et sécurité API peut cadrer un premier lot, ses contre-tests et son exploitation. Le périmètre reste volontairement borné jusqu’à ce que le tenant, le rôle et la révocation soient démontrables.
Pour construire cette chaîne avec vos équipes produit, IAM, sécurité et support, notre accompagnement d’intégrateur WSO2 Identity Server cadre les responsabilités métier, la recette de fédération et la capacité de reprise. Aucun périmètre supplémentaire n’est ouvert tant que tenant, rôle et révocation ne sont pas prouvés de bout en bout.
