IREX - Intégration SSO : provisionner automatiquement un compte d'identité lors d'une approbation métier
Comment la plateforme IREX provisionne automatiquement un compte Keycloak dès qu'une demande d'adhésion est approuvée, sans jamais dupliquer un compte existant.
Integration SSO : provisionner automatiquement un compte d'identite lors d'une approbation metier
SOMMAIRE
1. Introduction
Beaucoup d'organisations separent la gestion applicative (formulaires, demandes, workflow d'approbation) d'un serveur d'identite centralise (SSO) qui gere les acces reels aux outils internes. Cette separation pose une question recurrente : quand une demande est approuvee dans l'application, comment le compte correspondant se retrouve-t-il cree, avec les bons droits, du cote du serveur d'identite, sans qu'un administrateur ait a repeter l'operation manuellement dans les deux systemes ?
C'est le probleme que resout, a plus grande echelle, le provisionnement automatise de comptes dans la gestion des identites et des acces (IAM), un domaine ou existent meme des standards dedies comme SCIM pour synchroniser automatiquement des comptes entre systemes. Le meme principe s'applique a plus petite echelle des qu'une application metier et un serveur d'identite separe doivent rester synchronises. Cet article explique ce mecanisme en general, puis l'illustre par un cas concret sur la plateforme IREX : une personne y demande a devenir membre avec sa propre adresse courriel personnelle, et une fois cette demande approuvee, doit obtenir un acces reel aux outils internes de l'organisation, geres par un serveur d'identite Keycloak (un logiciel libre largement utilise pour la gestion des identites) separe de l'application elle-meme.
1.1 Le declencheur : un hook sur le document, pas sur le bouton
Le reflexe naturel serait de creer le compte Keycloak directement dans le code qui traite le clic sur le bouton "Approuver". Ce n'est pas ce qui a ete fait sur la plateforme IREX. La creation du compte est branchee sur un evenement du document lui-meme : chaque fois qu'une demande d'adhesion est enregistree, une fonction dediee s'execute automatiquement. Elle commence par verifier deux conditions avant de faire quoi que ce soit : que le statut de la demande est bien "Approuvee", et qu'aucun compte Keycloak n'a deja ete cree pour cette demande.
Cette garde a deux roles. Le premier est evident : ne rien faire tant que la demande n'est pas approuvee. Le second est moins visible mais tout aussi important : si un identifiant Keycloak existe deja sur le document, la fonction s'arrete aussi. Sans cette verification, chaque enregistrement ulterieur du document (une simple correction de champ, par exemple) tenterait de recreer un compte Keycloak deja existant, et echouerait.
Image 1 : le flux de provisionnement, depuis l'approbation de la demande jusqu'a l'activation du compte applicatif.
1.2 Le piege sans cette garde
Un hook branche sur l'enregistrement d'un document se declenche a chaque sauvegarde, pas seulement au moment de l'approbation. Sans la verification de l'identifiant Keycloak deja attribue, le scenario suivant devient possible : un administrateur approuve une demande, le compte Keycloak est cree normalement, puis ce meme administrateur rouvre le document plus tard pour corriger une faute de frappe dans le nom et l'enregistre a nouveau. Sans la garde, la fonction tenterait de recreer un compte Keycloak pour la meme personne, avec la meme adresse generee, et echouerait avec une erreur indiquant qu'un utilisateur Keycloak existe deja. Pire, si cette erreur n'etait pas remontee clairement, l'administrateur pourrait croire que sa correction n'a pas ete enregistree du tout. Ce genre de piege est facile a manquer en developpement, ou un document est rarement modifie apres son approbation, et se decouvre generalement en production, quand des corrections mineures deviennent courantes.
1.3 Deux adresses courriel distinctes, et pourquoi
Un detail qui peut surprendre : la personne approuvee ne se connecte pas avec l'adresse courriel qu'elle a utilisee pour s'inscrire. Une adresse professionnelle distincte est generee automatiquement, sur le modele de l'initiale du prenom suivie du nom de famille (kfofack, par exemple, pour Karim Fofack).
L'adresse d'inscription reste associee au compte applicatif (utile pour les communications generales, les notifications), tandis que l'adresse generee devient l'identifiant du compte Keycloak, celui utilise pour se connecter aux outils internes. Cette separation permet de garder une convention de nommage professionnelle uniforme, independamment de ce que la personne a saisi dans le formulaire public.
Image 2 : les deux adresses restent distinctes, chacune avec son propre role.
1.4 La creation du compte cote Keycloak
La creation du compte s'authentifie d'abord aupres de Keycloak avec les identifiants de l'application elle-meme, puis appelle l'API d'administration de Keycloak pour creer l'utilisateur avec son nom, son adresse generee, et son statut actif.
Deux strategies existent pour le mot de passe initial, choisies par une seule ligne de configuration sur le serveur, sans toucher au code : soit un mot de passe temporaire genere aleatoirement, soit un courriel d'invitation envoye directement par Keycloak pour que la personne definisse elle-meme son mot de passe.
Une fois le compte cree, les roles par defaut sont assignes automatiquement, eux aussi lus depuis la configuration du serveur plutot que codes en dur. Cela signifie qu'elargir ou restreindre l'acces accorde a un nouveau membre approuve ne demande aucune modification de code, seulement un changement de configuration sur le serveur concerne.
1.5 Un principe standardise, pas une bricole propre a IREX
Le provisionnement automatique de comptes n'est pas une idee isolee : c'est l'objet direct de SCIM (System for Cross-domain Identity Management), un standard publie sous l'IETF specifiquement pour automatiser la creation, la mise a jour et la desactivation de comptes entre systemes. SCIM formalise a l'echelle de l'industrie exactement le probleme que ce mecanisme resout ici a plus petite echelle : garder un systeme d'identite externe synchronise avec une source de verite applicative, sans intervention manuelle.
Image 3 : schema courant du provisionnement SCIM, ou un systeme source (RH ou fournisseur d'identite) declenche la creation ou la suppression automatique de comptes dans les applications connectees, la meme logique que celle appliquee ici avec la demande d'adhesion comme declencheur. Source : scalekit.com.
Keycloak lui-meme, le serveur d'identite utilise dans cet exemple, documente publiquement le mecanisme de "broker" d'identite sur lequel repose la creation de comptes via son API d'administration.
Image 4 : le schema officiel de Keycloak illustrant le flux d'un broker d'identite, publie dans sa documentation d'administration. Source : keycloak.org.
2. Conclusion
Le point important de cette approche est que l'administrateur qui approuve une demande n'a besoin de rien savoir sur Keycloak. Il clique sur "Approuver" dans l'interface de gestion des adhesions habituelle, et le provisionnement se fait en arriere-plan, avec ses propres verifications d'idempotence pour eviter les doublons. Si l'appel a Keycloak echoue, serveur indisponible ou identifiants invalides, l'operation est explicitement bloquee plutot que de laisser un compte applicatif active sans acces reel aux outils internes.
Cette approche garantit qu'un membre approuve a soit un acces complet et coherent des deux cotes, soit aucun acces du tout, jamais un etat intermediaire silencieusement casse. Le principe se generalise a toute integration entre une application metier et un serveur d'identite externe : brancher le provisionnement sur l'evenement metier lui-meme, pas sur l'action d'interface qui le declenche, et refuser explicitement un etat ou les deux systemes seraient desynchronises.
No comments yet. Start a new discussion.