Migrer un SSO LemonLDAP::NG ne consiste pas à remplacer un écran de connexion par un autre. Le système existant relie déjà des domaines, des virtual hosts, des règles, des variables de session, des headers HTTP et parfois plusieurs protocoles. Une modification qui ignore cette chaîne peut réussir le login tout en ouvrant le mauvais compte, en conservant un droit retiré ou en rendant une application impossible à diagnostiquer.
En réalité, le bon arbitrage est une coexistence temporaire, organisée et mesurable. Chaque application reçoit un propriétaire, un mode actuel, un mode cible, une source d’identité, un contrat d’attributs, un comportement de session et une date de décision. Le mot « temporaire » doit avoir une preuve : trafic résiduel suivi, dépendances connues, contre-tests réussis et rollback exercé.
Contrairement à ce que suggère une simple bascule de protocole, la difficulté principale n’est pas le format du token : c’est la continuité de la confiance. Pour cadrer une intervention, la page intégrateur LemonLDAP::NG décrit le service, les livrables et les limites de preuve. Pour administrer portail REST, sessions et configuration, le dossier API LemonLDAP::NG et exploitation WebSSO reste spécialisé sur le run.
Décider ce que la migration doit réellement améliorer
« Passer à OIDC » n’est pas un résultat métier. Une trajectoire crédible part des défauts observés : une application accepte des headers sur un port direct, un départ utilisateur laisse une session active, les groupes ont des sens différents selon les hôtes, ou le support ne sait pas distinguer un refus du handler d’une erreur applicative. Chaque défaut devient un critère mesurable.
Une équipe peut vouloir conserver LemonLDAP::NG comme portail et fournisseur d’identité, réduire son rôle à la protection de quelques applications historiques, ou au contraire y centraliser plusieurs fédérations. Ces choix sont différents. Ils modifient le propriétaire du login, de la session, des attributs et du logout. La décision d’architecture doit préciser ce qui reste, ce qui migre et ce qui sera retiré.
Le document de départ tient sur une page : problème actuel, population concernée, action sensible, délai maximal de retrait d’un droit, indisponibilité acceptable et équipe capable de revenir en arrière. Si personne ne peut nommer l’action sensible à rejouer après une migration, le projet n’a pas encore de seuil de réussite.
Pour qui une migration progressive devient nécessaire
La démarche vise d’abord les équipes qui exploitent déjà LemonLDAP::NG sur plusieurs applications, avec des virtual hosts, des headers ou des clients de fédération accumulés dans le temps. Elle devient nécessaire quand une modernisation doit préserver la continuité de service et qu’un arrêt général du SSO n’est pas acceptable.
Elle concerne aussi les responsables applicatifs qui doivent introduire OIDC ou SAML sans perdre les règles historiques, les sessions locales et la capacité du support à diagnostiquer. Sécurité, infrastructure, application et métier doivent partager le même registre des identités et des décisions.
En revanche, une application isolée sans compte partagé, sans autorisation sensible et sans dépendance legacy peut relever d’une intégration plus simple. Le diagnostic reste utile, mais il ne faut pas fabriquer un programme de migration disproportionné lorsque le coût et le risque ne le justifient pas.
Inventorier les applications avant de choisir les protocoles
L’inventaire ne se limite pas aux tuiles visibles dans le portail. Il part des hostnames effectivement appelés, des chemins réseau, des ports backend et des applications qui lisent une identité. Pour chacune, on relève le mode actuel : handler et headers, CAS, SAML, OIDC, authentification locale, rejeu de formulaire ou adaptation spécifique. On ajoute la session locale, le logout, les comptes techniques et les accès hors navigateur.
Il faut ensuite cartographier les dépendances cachées. Une application peut utiliser le header uid pour afficher l’utilisateur mais un autre header pour calculer ses droits. Un batch peut appeler le même backend sans passer par le SSO. Un alias DNS peut exposer un chemin qui évite le reverse proxy. Un module local peut mettre en cache les groupes plus longtemps que la session LemonLDAP::NG.
Le registre utile comporte au minimum : owner applicatif, criticité, population, hostname, chemin de confiance, protocole, identifiant reçu, attributs consommés, règle d’accès, session locale, mécanisme de logout, dépendance au réseau et procédure d’urgence. Les champs inconnus ne sont pas remplis par supposition ; ils deviennent des vérifications du pilote.
Séparer les rôles de portail, handler, manager et application
Le portail authentifie et porte les échanges de fédération
Le portail présente le parcours d’authentification, construit la session et peut jouer un rôle de fournisseur ou de client selon CAS, SAML et OpenID Connect. Cette centralité ne signifie pas qu’il doit connaître toutes les règles métier. Il produit un contexte d’identité ; l’application reste propriétaire de ses opérations sensibles.
Ses endpoints publics, callbacks et éventuelles API REST sont inventoriés séparément des interfaces d’administration. Le contrat précise le domaine, le certificat, les paramètres transmis, la taille maximale du payload et le comportement attendu lorsque le backend d’identité ne répond plus.
Le handler protège avant que l’application ne réponde
Le handler intercepte la requête, retrouve la session, évalue la règle du virtual host et transmet les attributs autorisés. Le point essentiel est topologique : si une autre route atteint directement le backend, l’application peut recevoir un header forgé ou une requête non soumise à la règle. Le diagramme réseau fait donc partie du contrat IAM.
La vérification associe URL, proxy, port, règle et réponse obtenue. Elle couvre aussi les appels d’une API interne, d’un batch ou d’un SDK qui pourraient atteindre le même endpoint sans navigateur et nécessitent une authentification technique distincte.
Le manager administre, l’application décide du métier
Le manager porte la configuration et ses évolutions. Son accès, ses droits, ses sauvegardes et sa traçabilité doivent être plus stricts que ceux du portail public. De son côté, l’application interprète l’identité dans son propre modèle : organisation, contrat, dossier, rôle fonctionnel ou périmètre de données. Déplacer toutes ces décisions dans une macro SSO créerait une seconde logique métier difficile à tester.
Chaque version de configuration possède un auteur, une date, un schéma de changement et une procédure de restauration. Le pipeline contrôle la syntaxe avant activation ; la recette fonctionnelle confirme ensuite que le mapping et les décisions restent identiques sur les applications non migrées.
Choisir un pilote qui révèle les vraies contraintes
Une application trop simple produit un faux succès. Le pilote doit contenir au moins deux profils, une règle conditionnelle, un attribut utile, une session locale et une action qui doit être refusée après retrait du droit. Il doit aussi représenter un mode que l’équipe veut réellement déployer : headers pour un legacy, CAS pour un existant compatible, ou OIDC/SAML pour une application moderne.
Le lot commence par un état initial rejouable. Deux comptes de test, des groupes connus, une configuration exportée, un jeu de requêtes et une preuve du comportement actuel permettent de comparer. L’équipe note les écarts acceptés : format d’identifiant, écran de consentement, durée de session, attribut absent, comportement du logout ou message de refus.
Le pilote se termine par une décision, pas par une démonstration. Le comité relit les contre-tests, le délai de révocation, le temps de diagnostic et l’exercice de rollback. Un login nominal ne compense jamais un header usurpable, un compte mal rapproché ou une procédure de retour arrière dépendante d’une seule personne.
Conserver des headers legacy sans accepter leur usurpation
Les headers HTTP restent une méthode documentée pour protéger les applications qui acceptent une authentification externe. Ils ne sont pas faibles par nature ; leur sécurité dépend de la chaîne de confiance. Le backend ne doit pas être joignable depuis le réseau utilisateur, le proxy doit supprimer les en-têtes sensibles entrants, et le handler doit être la seule brique autorisée à injecter les valeurs attendues.
Le contrat de headers liste le nom, la source, le format, la cardinalité, le caractère sensible et le comportement si la valeur manque. Exporter tout le profil « au cas où » augmente l’exposition et rend les dépendances invisibles. Une application qui ne consomme que l’identifiant et deux groupes ne doit pas recevoir adresse, téléphone, organisation complète et attributs RH.
Le contre-test envoie la requête avec un identifiant administrateur déjà présent dans les headers, tente l’accès direct au port backend et rejoue un ancien nom d’hôte. Le résultat attendu est un refus réseau ou la suppression de la valeur forgée, puis une identité reconstruite depuis la session de confiance. Cette preuve doit être conservée avec la recette.
Maintenir CAS quand son contrat reste utile
Une application compatible CAS n’a pas nécessairement besoin d’une migration immédiate. Si le client est maintenu, si le service URL est stable et si le logout répond aux exigences, CAS peut rester un contrat lisible. Le risque vient plutôt des services déclarés trop largement, des URLs alternatives oubliées et des attributs dont la signification diffère entre applications.
Le registre associe chaque service à son owner, ses URLs exactes, la version de validation utilisée, les attributs transmis et la session locale créée après validation du ticket. Les redirections sont contrôlées, les environnements sont séparés et un ticket ne doit jamais être interprété comme un rôle métier universel.
Le maintien de CAS devient une décision datée. On surveille l’usage, la version du client, les incidents et la capacité de logout. Une migration vers OIDC n’est prioritaire que si elle réduit un risque ou une dette précise. La page intégration CAS approfondit ce protocole sans le confondre avec toute l’architecture LemonLDAP::NG.
Utiliser SAML pour les fédérations qui l’exigent
SAML reste fréquent dans les relations entreprise et les logiciels qui attendent métadonnées, assertions et certificats. LemonLDAP::NG peut recevoir une identité d’un fournisseur externe ou en fournir une à un service. La migration doit donc préciser son rôle pour chaque partenaire : SP, IdP ou proxy de fédération. Une simple mention « SAML activé » ne suffit pas.
Le contrat conserve EntityID, endpoints, certificats, NameID, attributs obligatoires, règles de rapprochement et comportement du Single Logout. Les métadonnées échangées sont versionnées et leur renouvellement est planifié avant expiration. Le compte local est rapproché avec une clé durable ; l’adresse email seule n’est pas une identité sûre lorsqu’elle peut changer ou exister chez plusieurs partenaires.
La recette inclut assertion expirée, signature inconnue, attribut obligatoire absent, horloge décalée, utilisateur homonyme et logout incomplet. Pour travailler cette frontière spécifiquement, la page intégrateur SAML détaille les choix de confiance et de métadonnées.
Introduire OIDC sans fabriquer une seconde identité
OpenID Connect convient aux applications capables de valider un issuer, un ID Token, des claims et une session locale. LemonLDAP::NG peut agir comme fournisseur OpenID Connect et publier discovery ainsi que JWKS. Le client reste responsable de vérifier issuer, audience, signature, nonce et redirect URI selon son flux. Accepter un JWT décodé sans ces contrôles remplace un legacy visible par une faille moderne.
Le subject doit être traité comme un identifiant lié à l’issuer. Le mapping local ne doit pas supposer qu’un même email désigne automatiquement le même compte entre un ancien header, un partenaire SAML et un client OIDC. Une table de rapprochement documente la clé source, la clé cible, la date, la règle et les cas d’ambiguïté.
La migration teste aussi le logout. Fermer la session locale, la session LemonLDAP::NG ou celle d’un fournisseur amont ne produit pas toujours le même effet. L’équipe définit le niveau attendu pour un logout volontaire, un retrait de droit et un incident de sécurité. Le dossier intégration OpenID Connect porte l’intention protocolaire ; cette page reste centrée sur la coexistence.
Rapprocher les identités et versionner les attributs
LemonLDAP::NG sépare les mécanismes d’authentification, de données utilisateur et, selon les modules, de gestion du mot de passe. Cette séparation permet de composer plusieurs sources, mais elle exige de nommer la vérité de chaque donnée. L’annuaire peut porter l’identifiant et les groupes techniques, le référentiel métier l’organisation et l’application un rôle strictement local.
Chaque attribut exporté dispose d’une source, d’un format, d’une règle de transformation, d’une sensibilité et d’un propriétaire. Les macros peuvent calculer une valeur utile, mais leur logique est versionnée comme du code. Une macro sans test et sans owner ne doit pas décider seule d’un accès sensible.
Lors de la coexistence, l’ancien et le nouveau protocole doivent produire une identité comparable. La recette rapproche header, NameID, identifiant CAS, issuer et subject sans forcer l’égalité. Les ambiguïtés passent en quarantaine humaine. Cette prudence évite qu’un changement de protocole fusionne deux personnes ou crée deux comptes pour la même personne.
Traiter sessions, cookies et logout comme un même système
Définir la durée par niveau de risque
Le cookie SSO référence une session dont la durée et le stockage ont des effets concrets sur la révocation. Une longue session améliore le confort mais prolonge potentiellement un état devenu faux. La décision distingue expiration du cookie, expiration de la session, session persistante, session locale de l’application et éventuel token d’accès.
Le stockage choisi impose ses propres limites de disponibilité, de réplication et de purge. La capacité théorique ne suffit pas : un test de charge et une coupure contrôlée vérifient que les handlers retrouvent l’état sans ouvrir un accès par défaut.
Mesurer la fermeture au niveau attendu
Le logout nominal n’est qu’un scénario. Un départ, une compromission ou un groupe retiré peuvent nécessiter d’invalider une session centrale et de refuser une action locale. L’équipe définit la fraîcheur attendue par niveau de droit, puis choisit rafraîchissement, invalidation, réauthentification ou contrôle complémentaire.
Les options de domaine, de sécurité et de SameSite du cookie doivent correspondre aux domaines réellement utilisés et aux parcours fédérés. Une migration de hostname ou de protocole peut produire des comportements différents selon les navigateurs. Les tests couvrent navigation entre domaines, retour d’un IdP, onglet encore ouvert, session expirée et horloge décalée.
Garder les règles d’accès explicables pendant la coexistence
La règle d’un virtual host décide si une requête passe avant l’application. Elle peut utiliser attributs, groupes, niveau d’authentification et macros. Cette puissance ne doit pas transformer le SSO en moteur métier général. Une règle protège une frontière d’accès ; l’application continue de vérifier les permissions fines sur ses propres objets.
Le registre des règles conserve nom, finalité, owner, expression, variables, valeur par défaut, exceptions, date de revue et tests. Une règle refusée produit un motif exploitable sans exposer de donnée sensible à l’utilisateur. Le support doit pouvoir relier l’incident à la version de configuration active.
Pendant une migration, deux règles peuvent coexister sur l’ancien et le nouveau chemin. Elles sont comparées sur les mêmes profils et actions. Si elles rendent des verdicts différents, l’écart est décidé explicitement. Copier l’ancienne expression dans un claim ou dans le code de la nouvelle application ne résout rien : cela crée deux propriétaires.
Plan d’action : déployer par lots avec un vrai retour arrière
Les lots sont construits par dépendance, pas uniquement par nombre d’applications. Une famille partageant le même annuaire et le même contrat de headers peut avancer ensemble. Une application critique avec session locale complexe reste isolée. Chaque lot possède un canary, une fenêtre d’observation, un owner de décision et une procédure de retour vers le mode précédent.
Le rollback n’est pas « remettre l’ancienne configuration » de mémoire. Il indique quel fichier ou quelle version restaurer, comment traiter les sessions créées pendant la bascule, comment rétablir le routage et comment vérifier l’identité après retour. La configuration, les secrets et les métadonnées nécessaires sont disponibles avant le go-live.
Le retrait de l’ancien chemin intervient après une preuve de non-usage, pas après la date théorique de fin. On suit les hostnames, clients, tickets ou headers encore consommés. Les exceptions ont une échéance et un propriétaire. Sans cela, la coexistence devient permanente et chaque incident oblige à diagnostiquer deux architectures.
- D’abord : attribuer les applications, fermer les chemins directs et sauvegarder la configuration réellement active.
- Ensuite : tester un canary avec identités contradictoires, retrait de droit, session existante et dépendance indisponible.
- Puis : élargir seulement si le délai de révocation, le temps de diagnostic et le rollback respectent les seuils convenus.
- À refuser : retirer l’ancien chemin sans preuve de non-usage ou sans personne capable de restaurer le lot.
Jouer les contre-tests qui invalident le scénario nominal
Une recette utile commence par les scénarios qui pourraient contredire l’architecture. Premier test : contourner le handler et présenter un header administrateur. Deuxième test : retirer un groupe pendant qu’une session reste ouverte, puis rejouer une action sensible. Troisième test : rapprocher deux identités portant le même email mais des issuer ou identifiants différents.
On ajoute backend d’identité indisponible, stockage de sessions ralenti, certificat expiré ou clé tournée, callback OIDC incorrect, assertion SAML incomplète, ticket CAS rejoué, logout partiel et configuration précédente restaurée. Chaque test définit état initial, action, résultat attendu, preuve, responsable et délai maximal.
La preuve ne se limite pas à une capture d’écran. Elle relie un identifiant de corrélation, le composant traversé, la session, la règle, l’attribut ou le claim et le verdict applicatif. Les données sensibles sont minimisées. Un test ne passe que si le support sait retrouver la cause à partir du signal qu’il recevra réellement.
Erreurs fréquentes : éviter les raccourcis de coexistence
La première erreur consiste à copier la règle d’accès dans le handler, dans les claims OIDC et dans le code applicatif. Une correction urgente touche alors une seule version et produit trois verdicts. Le propriétaire de la frontière doit rester unique ; les autres composants valident uniquement ce dont ils sont responsables.
La deuxième consiste à rejouer automatiquement une migration d’identité après timeout. Sans idempotence ni relecture, le retry peut associer le mauvais compte ou créer un doublon. La queue conserve source, identifiant, opération, version du mapping et dernier état observé ; un backoff limite la pression pendant l’incident.
La troisième consiste à traiter une réponse HTTP positive comme le succès final. Le callback peut réussir alors que la session locale porte encore l’ancien rôle. Le contrôle relit la ressource cible et rejoue l’action sensible. Ce verdict métier, avec son délai, ferme le dossier.
Donner au support des preuves et des gestes de reprise
Le tableau de bord sépare erreurs d’authentification, refus d’autorisation, sessions invalides, backends indisponibles et erreurs applicatives. Une moyenne de connexions réussies peut masquer un groupe entier bloqué par une règle. Les métriques sont donc reliées aux virtual hosts, protocoles, versions de configuration et populations, dans le respect de la minimisation des données.
Le runbook part du symptôme : boucle de redirection, header absent, accès refusé, mauvais compte, logout inefficace ou portail indisponible. Pour chaque symptôme, il indique les trois premières vérifications, les logs autorisés, la frontière responsable, le geste sûr, le geste interdit et le chemin d’escalade.
Un exercice chronométré valide la passation. Le support reçoit une alerte de session encore active après retrait d’un groupe. Il doit retrouver l’utilisateur de test, identifier la version de règle, fermer ou renouveler l’état attendu et prouver le refus final sans demander une commande improvisée au développeur. Le temps obtenu devient le seuil de service réel.
Répondre aux questions de migration les plus fréquentes
Faut-il migrer toutes les applications en même temps ?
Non. Le lot est borné par dépendances, criticité et capacité de rollback. Une migration progressive permet de comparer les décisions, de corriger le contrat d’attributs et de former le support avant d’étendre. La contrepartie est de dater et mesurer la coexistence pour éviter qu’elle ne devienne permanente.
Le premier lot doit néanmoins être représentatif. Une application sans rôle sensible ni session locale ne révèle pas les écarts de mapping, de fermeture et d’exploitation qui décideront la suite.
Faut-il remplacer tous les headers par OIDC ?
Non. Des headers contrôlés restent adaptés à certaines applications historiques. OIDC apporte un contrat moderne aux applications compatibles, mais ne sécurise pas automatiquement le rapprochement d’identité, les permissions métier ou le logout. Le choix se prend application par application.
La priorité va aux chemins contournables, aux dépendances non maintenues et aux applications dont le coût de support est déjà visible. Le protocole le plus récent n’est pas automatiquement le premier chantier utile.
Comment prouver qu’un droit est retiré ?
Le test retire le droit dans la source, observe la session ou force son renouvellement selon le contrat, puis rejoue une action sensible. La preuve contient l’horodatage source, la règle recalculée, le refus applicatif et la durée totale. Si l’architecture ne sait agir qu’à la prochaine connexion, cette limite est annoncée.
Pour une action critique, le seuil peut imposer une invalidation centrale et locale. Pour un droit faible, une session courte peut être acceptable. Le niveau de risque choisit le mécanisme ; il ne doit pas être déduit après l’incident.
Approfondir administration, protocoles et cycle de vie
La ressource administrer LemonLDAP::NG par API et services REST traite les sessions, la configuration, les règles, les headers et les procédures d’exploitation. Elle complète ce plan de migration sans reprendre l’intention commerciale de la landing LemonLDAP::NG.
Pour arbitrer un nouveau client, le comparatif SAML ou OpenID Connect en B2B aide à choisir le protocole. Le dossier SSO, provisioning et SCIM rappelle que connecter une identité ne pilote pas à lui seul son arrivée, sa mobilité et son départ.
Ces lectures doivent aboutir à un registre unique des décisions, pas à une collection de configurations copiées. Application, mode, source d’identité, contrat d’attributs, session, autorisation, propriétaire et critère de retrait restent les colonnes communes.
Conclusion : baser la bascule sur une décision observable
Une migration LemonLDAP::NG réussie ne se juge pas au nombre d’applications déclarées ni au premier login. Elle se juge quand un header forgé est refusé, qu’un identifiant est rapproché sans ambiguïté, qu’une règle peut être expliquée et qu’un droit retiré cesse d’ouvrir l’action sensible dans le délai convenu.
La trajectoire la plus solide est incrémentale : inventaire réel, architecture cible, pilote contradictoire, lot borné, observation, décision et retrait mesuré. CAS, SAML, OIDC et headers ne sont pas des camps opposés ; ce sont des contrats à choisir et à gouverner selon les applications.
Pour appliquer cette méthode à votre topologie, l’accompagnement LemonLDAP::NG de Dawap permet de cadrer le premier lot, les contre-tests, les contrats API et le runbook avec les responsables sécurité, infrastructure, applications et support.
