Une équipe extrait le module commandes d’un extranet legacy et ajoute une connexion sur la nouvelle application. Les utilisateurs obtiennent deux comptes, les droits divergent et la déconnexion du nouveau parcours laisse l’ancien cookie actif ; un salarié désactivé continue ainsi d’accéder aux écrans historiques.
Le problème provoque une douleur immédiate : support saturé, mots de passe réinitialisés au mauvais endroit, autorisations incohérentes et incidents impossibles à attribuer. Deux signaux faibles apparaissent plus tôt : davantage de liens de comptes manuels et un écart croissant entre révocations demandées puis sessions réellement actives.
Le vrai enjeu ne consiste pas à brancher un bouton SSO. Vous allez comprendre comment conserver une autorité d’identité, adapter les preuves au legacy, séparer les droits métier et déplacer des cohortes sans créer une période où deux politiques concurrentes décident qui peut faire quoi.
Une expertise en développement web relie sécurité et architecture de transition. L’accompagnement en migration d’application legacy vers Symfony transforme cette cible en coutures, tests, observabilité et portes de bascule réellement exploitables.
Traiter l’identité comme une contrainte de migration
L’authentification traverse presque toutes les coutures : navigation, API, session, support, audit et autorisation. Une erreur ne touche pas seulement le module migré ; elle ouvre ou ferme un parcours entier.
Cartographier preuves, décisions et dépendances
Le dossier recense sources de compte, identifiants, cookies, sessions serveur, mécanismes de mot de passe, MFA, rôles, groupes, délégations, utilisateurs techniques et chemins de récupération. Chaque dépendance porte propriétaire puis criticité.
La menace couvre usurpation, fixation de session, confusion de compte, replay de jeton, escalade de privilège et révocation incomplète. Les contrôles existants sont testés au lieu d’être présumés grâce à une documentation ancienne.
Les invariants précisent qu’une personne possède un identifiant global, qu’une désactivation coupe tous les chemins sous un délai borné et qu’aucun secret moderne ne transite vers une base legacy non nécessaire.
Le registre de décision relie risque, mesure, preuve, owner et date de revue. Une exception possède durée puis population ; elle ne devient jamais une architecture permanente parce qu’un écran historique résiste.
Choisir une autorité d’identité unique
Pendant la coexistence, plusieurs applications peuvent consommer l’identité, mais une seule autorité doit créer, authentifier, désactiver et établir les attributs de sécurité reconnus par tous les parcours.
Distinguer fournisseur d’identité et profil applicatif
L’IdP maîtrise subject, credentials, MFA, état de compte et sessions centrales. Chaque application conserve un profil local pour ses préférences et relations métier, relié par un subject immuable plutôt que par email.
Le provisioning passe par SCIM, événements ou synchronisation versionnée. Le legacy peut recevoir un identifiant et un état minimal ; il ne redevient pas autorité lorsqu’un administrateur modifie localement un email ou un rôle.
La source d’autorité est écrite attribut par attribut : identité RH, relation client, groupe métier, statut contractuel. Cette matrice évite de remplacer un double login par un conflit silencieux entre annuaires.
Si l’IdP est indisponible, alors la politique de repli définit quels utilisateurs et quelles opérations conservent une session existante. Créer une authentification locale de secours non gouvernée élargirait le risque précisément pendant l’incident.
Stabiliser la correspondance entre comptes
Le legacy connaît user_id=4821, l’IdP émet un subject opaque et le nouveau domaine possède un account_id. La migration doit relier ces clés sans utiliser un email modifiable comme jointure durable.
Construire une table de liaison auditée
La correspondance contient global_subject, legacy_user_id, target_account_id, état, méthode, confiance, created_at et reviewed_by. Une contrainte garantit l’unicité dans chaque espace actif et bloque toute collision.
Le rapprochement automatique utilise identifiants vérifiés, numéro client ou attribut RH. Sous un seuil de confiance explicite, le compte rejoint une revue avec candidats et conséquences, plutôt qu’une fusion silencieuse.
Une fusion ou séparation de comptes devient une commande avec motif puis audit. Les sessions actives sont révoquées avant le changement afin qu’un ancien lien ne continue pas à porter des autorisations mélangées.
Le support recherche par identifiants sans pouvoir les modifier directement. Une procédure à double validation traite les comptes privilégiés et conserve la preuve de chaque rattachement sensible.
Adapter les protocoles sans exposer les secrets
La cible utilise idéalement OpenID Connect ou SAML, tandis que le legacy attend parfois une session PHP, un header ou une table locale. Une passerelle traduit la preuve, pas le mot de passe.
Échanger un jeton court contre une session legacy
Après authentification centrale, un broker valide issuer, audience, signature, nonce, state, PKCE et durée. Il émet un ticket à usage unique lié au navigateur ; le legacy l’échange côté serveur contre sa session locale.
Le ticket contient jti, subject, audience, expires_at et empreinte de contexte nécessaire. Il expire en moins d’une minute, ne circule pas dans les logs et devient inutilisable après son premier échange.
La clé de signature se trouve dans un coffre, avec rotation et période de chevauchement. Le legacy ne reçoit que les clés publiques nécessaires et refuse tout algorithme ou issuer non explicitement autorisé.
Les entrées du broker, ses sorties, son owner, le monitoring, le seuil de rejet et le rollback de version sont documentés. Une erreur ferme l’accès plutôt que de fabriquer une session partiellement validée.
Faire coexister les sessions sans les confondre
Une session centrale prouve une authentification, tandis que chaque application porte son propre contexte et sa propre durée. Partager directement une table ou un cookie crée un couplage fragile et une surface d’attaque commune.
Aligner durées, renouvellement et niveau d’assurance
La session IdP a idle_timeout, absolute_timeout, auth_time et niveau MFA. Les applications demandent une authentification récente pour une action sensible, sans considérer qu’un cookie âgé de huit heures suffit partout.
Les cookies locaux utilisent Secure, HttpOnly, SameSite, domaine minimal et rotation après login. Le legacy abandonne les identifiants prédictibles puis régénère la session lors de toute élévation de privilège.
Le refresh token reste dans le backend moderne ou un BFF, jamais dans le navigateur si le modèle l’évite. Le legacy reçoit une session courte renouvelée par preuve centrale, pas une capacité générale d’émettre des tokens.
Préserver le contexte lors d’un passage entre applications
Le deep link signe destination, tenant et intention, puis les revalide après authentification. Une URL fournie par l’utilisateur ne devient jamais une redirection ouverte vers un domaine arbitraire.
Le panier ou dossier en cours porte un identifiant métier, pas l’état d’autorisation complet. À l’arrivée, la cible recharge les droits et vérifie que la ressource appartient encore au subject reconnu.
Les parcours sont testés avec onglets multiples, session expirée, changement de rôle et retour navigateur. Une expérience fluide ne doit pas dépendre d’un ordre unique impossible à garantir chez les utilisateurs.
Migrer les mots de passe sans les recopier
Exporter des hashes vers la cible semble rapide, mais algorithme, sel, pepper et qualité historique peuvent être inconnus. La transition doit améliorer la sécurité sans forcer tous les utilisateurs le même jour.
Choisir réinitialisation ou migration au prochain login
La stratégie préférée invite à définir un credential dans l’IdP avec preuve forte. Lorsque le volume l’exige, une validation transitoire côté legacy peut confirmer l’ancien mot de passe puis déclencher immédiatement l’enrôlement central.
Le mot de passe en clair ne rejoint jamais le bus, les logs ou la nouvelle base. L’échange transitoire utilise un canal interne authentifié, limité à cette commande et supprimé après la fenêtre de migration.
Les comptes dormants expirent au lieu d’être copiés. Les comptes privilégiés suivent une campagne dédiée avec MFA obligatoire, preuve d’identité et révocation de toutes les sessions historiques.
La métrique suit comptes enrôlés, échecs, support, taux de récupération puis utilisateurs restants. La voie transitoire possède une date de retrait ; aucun « dernier compte » ne justifie son maintien illimité.
Séparer authentification et autorisations métier
L’IdP affirme qui s’est authentifié et quelques attributs stables. Il ne doit pas embarquer toutes les décisions métier d’une application, surtout lorsque leurs règles évoluent à des cadences différentes.
Centraliser les rôles communs sans gonfler les tokens
Les groupes globaux portent emploi, tenant ou niveau d’administration. La cible calcule permissions sur ressources, délégations, état du dossier et séparation des tâches depuis une politique versionnée.
Le legacy traduit temporairement les rôles globaux vers ses ACL, avec une table de mapping explicite. Toute permission sans équivalent devient une décision de migration, jamais un rôle « admin » donné par prudence.
Les tokens évitent des milliers de permissions susceptibles d’être obsolètes avant expiration. Ils portent subject, audience, tenant, auth_time et claims nécessaires ; l’application recharge les autorisations critiques.
Comparer les décisions avant de déplacer l’écriture
Un moteur shadow évalue nouvelle puis ancienne politique sans changer le résultat utilisateur. Les divergences conservent identité pseudonymisée, ressource, action, versions et raisons pour une revue métier.
Le seuil de bascule exige zéro divergence sur les actions privilégiées et moins de 0,1 % sur les lectures, toutes expliquées. Une différence attendue devient une fixture ; une différence inconnue bloque la cohorte.
Contre-intuitivement, viser la parité de chaque anomalie legacy augmente parfois le risque. Les permissions historiques sans owner ni usage passent par une décision de retrait plutôt que d’être fidèlement reproduites.
Propager les droits avec une fraîcheur mesurée
Un rôle modifié dans l’annuaire ne protège rien tant que les deux applications, leurs caches et leurs sessions continuent d’utiliser l’ancienne valeur. La fraîcheur fait partie de la garantie de sécurité.
Combiner événements, versions et relecture critique
L’événement RoleChanged porte subject, tenant, role_version, occurred_at et reason. Les consommateurs appliquent une version croissante, invalident leurs caches et accusent la prise en compte.
Une décision sensible compare role_version du contexte à la version courante. Si elle est trop ancienne, alors l’application recharge la politique ou refuse temporairement au lieu d’autoriser sur un cache périmé.
Le SLO fixe quatre-vingt-dix-neuf pour cent des changements propagés sous deux minutes et cent pour cent des révocations critiques sous trente secondes. Les métriques mesurent la dernière application, pas seulement la publication sur le bus.
Les lots complets servent à la réconciliation quotidienne. Ils détectent événement perdu, compte orphelin ou mapping local divergent, puis produisent une correction idempotente avec origine et version.
Révoquer sessions et accès sur les deux chemins
Une déconnexion locale n’est pas une révocation globale. Départ d’un salarié, appareil compromis, changement de mot de passe et retrait de rôle exigent des périmètres puis délais différents.
Propager un événement de sécurité prioritaire
La révocation crée revocation_id, subject, sessions visées, raison, niveau, issued_at et deadline. L’IdP coupe tokens puis sessions centrales ; les applications détruisent sessions locales et confirment leur résultat.
Le legacy expose une commande serveur capable d’invalider toutes les sessions d’un utilisateur, même si son interface ne connaît qu’une déconnexion par navigateur. Une table d’index relie subject et session_id sans stocker de secret.
Le monitoring compare demandes, accusés et sessions encore observées. À trente secondes, une révocation critique sans confirmation coupe le routage du legacy ou bloque le subject à la passerelle.
Les tests exercent logout front-channel, back-channel, expiration, panne du bus et redémarrage. Le runbook donne entrée, sortie, owner, seuil, journalisation puis procédure de repli jusqu’au rétablissement.
Router les cohortes avec un retour sûr
Le strangler déplace des parcours et populations progressivement. Le routage doit rester stable pendant une session, observable et réversible sans changer l’identité reconnue ni la politique de sécurité.
Définir cohortes et règles déterministes
La cohorte utilise tenant, rôle, fonctionnalité, pays ou hash stable du subject. Elle évite cookies manuels et listes non auditées ; sa règle possède version, owner, début, fin et critère de sortie.
Le routeur évalue après authentification mais avant création de session applicative. Une personne garde la même cible pendant son parcours, sauf incident de sécurité exigeant une réauthentification contrôlée.
Les liens partagés restent valides : le routeur traduit route métier vers implémentation autorisée, sans exposer un domaine interne ou demander à l’utilisateur de choisir l’application.
Préparer le retour sans réactiver une ancienne politique
Le rollback de parcours remet le trafic sur l’interface legacy, mais conserve IdP, subject et révocation centrale. Revenir à l’ancien écran ne doit jamais rétablir ses credentials ou rôles locaux devenus obsolètes.
Les écritures effectuées dans la cible restent compatibles ou répliquées avant le retour. Le plan nomme le dernier état lisible par le legacy, les opérations interdites et la procédure de réconciliation.
La porte de cohorte exige taux de login, erreurs, latence, divergences de droits et révocations sous seuil pendant deux cycles. Chaque alerte peut réduire la cohorte sans invalider les sessions saines.
Surveiller sécurité, dérive et expérience
L’authentification peut rester disponible tout en produisant davantage de boucles, de rattachements manuels ou de droits périmés. L’observabilité relie identité, session, autorisation et parcours sans exposer de secrets.
Tracer un parcours avec des identifiants sûrs
Les logs portent correlation_id, subject pseudonymisé, session_family, application, policy_version, résultat et reason_code. Ils excluent tokens, mots de passe, tickets et attributs personnels non nécessaires.
Le tableau suit succès de login, MFA, boucle de redirection, création de session, erreurs de mapping, divergence d’autorisation, délai de révocation et appels support. Les métriques se découpent par cohorte et version.
Un signal faible se voit quand les utilisateurs repassent plus souvent d’une application à l’autre ou que les refresh de droits augmentent sans changement métier. Ces tendances révèlent une couture instable ou un cache trop court.
L’alerte indique première divergence, impact, cohorte, version et action. Le coût complet inclut charge support, temps de sécurité puis interruption, pas seulement disponibilité de l’IdP.
Dans quel cas appliquer la méthode : extranet métier
Un extranet de maintenance possède vingt mille comptes, des rôles par site et douze modules. Le planning migre vers Symfony, tandis que contrats puis facturation restent six mois dans le monolithe.
Installer l’autorité commune avant le premier module
Les comptes actifs sont rapprochés avec l’annuaire, les collisions passent en revue et l’IdP devient autorité. Un broker émet une session legacy depuis un ticket à usage unique sans recopier les mots de passe.
La porte pilote exige cent pour cent des comptes privilégiés liés, zéro collision non résolue et révocation sous trente secondes. Deux sites internes composent la première cohorte pendant trois semaines.
Exemple concret : un responsable perd son rôle sur un site. L’événement invalide caches et sessions des deux applications ; la prochaine requête refuse l’accès au planning comme au contrat historique.
Déplacer les droits du planning après comparaison
La nouvelle politique évalue les actions en shadow pendant dix jours. Trois divergences révèlent des ACL locales jamais documentées ; le métier en conserve une, retire les deux autres et ajoute des tests.
Le module ouvre à vingt pour cent des utilisateurs, puis cinquante et cent. Un pic de boucle de redirection sur Safari déclenche un retour à dix pour cent sans abandonner l’autorité centrale.
Après deux cycles sans divergence critique, le legacy cesse de décider les droits du planning. Sa table locale devient une projection temporaire, puis disparaît lorsque le dernier module dépendant migre.
Éviter les erreurs fréquentes de transition IAM
Les erreurs classiques sont de créer un second annuaire, partager un cookie, copier les mots de passe, mettre tous les droits dans le token ou oublier les sessions legacy lors d’une révocation.
Refuser les raccourcis qui divisent l’identité
Deux login screens paraissent indépendants, mais ils produisent immédiatement des comptes et supports concurrents. La couture doit précéder la migration fonctionnelle, même si son interface reste invisible.
Partager une base de sessions couple formats, versions et secrets ; une vulnérabilité devient commune. Échanger une preuve courte puis créer des sessions locales isolées réduit cette dépendance.
Un token contenant chaque permission grossit, vieillit et fuit davantage de contexte. L’application garde les décisions métier et revalide les actions sensibles avec une version courante.
Enfin, tester seulement le login heureux ignore expiration, onglets, réinitialisation, changement de rôle et incident réseau. La recette doit d’abord casser les coutures avant de leur confier une cohorte.
Plan d’action : migrer l’identité en six semaines
Le programme installe d’abord l’autorité commune et une couture réversible, puis déplace une population non privilégiée. Chaque semaine réduit une ambiguïté avant d’augmenter le trafic.
Semaines 1 à 3 : inventaire, identité et session
Cartographiez comptes, credentials, sessions, rôles, révocations et parcours. Définissez ensuite subject global, table de liaison, autorité par attribut, protocoles, durées, dépendances et menaces prioritaires.
Implémentez broker, ticket unique et invalidation legacy. Testez collision, fixation, replay, expiration, MFA, logout et panne de l’IdP avec des comptes synthétiques puis une cohorte interne.
La sortie comprend architecture de confiance, mappings, fixtures, SLO et owners. À refuser : tout compte privilégié sans identité unique ou voie de révocation globale vérifiée.
Semaines 4 à 6 : droits, cohortes et retrait
Comparez les autorisations en shadow, qualifiez chaque divergence et activez le routage déterministe. Exercez rollback d’interface, propagation de rôle puis reconstruction des projections avant le premier utilisateur externe.
La bascule exige zéro divergence privilégiée, plus de 99,5 % de logins réussis et révocation sous le SLO pendant deux cycles. Une violation réduit automatiquement la cohorte.
Planifiez enfin retrait des mots de passe legacy, synchronisations locales et endpoints de transition. Chaque composant possède une date, une condition et un responsable afin que le strangler ne devienne pas un double système permanent.
- D’abord, désigner l’autorité, stabiliser le subject et rapprocher les comptes avec une procédure de collision auditée.
- Ensuite, échanger des preuves courtes, isoler les sessions et tester expiration, MFA, révocation puis redirections.
- Puis, comparer les autorisations en shadow et router des cohortes stables avec un retour d’interface sûr.
- À faire enfin : mesurer l’ensemble du parcours, retirer credentials puis projections temporaires et fermer chaque couture résiduelle.
Guides complémentaires : relier coutures et preuves
L’identité constitue une couture transverse parmi les plus sensibles. La cartographie des dépendances, le shadow traffic, le dual write et la matrice de modernisation apportent les preuves complémentaires.
Assembler le dossier de migration progressive
La méthode des coutures d’une application legacy localise précisément frontières, dépendances et transactions. Le shadow traffic compare les décisions sans exposer l’utilisateur aux effets de bord.
La réconciliation du dual write sécurise les projections transitoires et leurs divergences. La matrice de décision de modernisation aide à choisir réécriture, encapsulation ou retrait selon des preuves comparables.
Ensemble, ces pratiques relient identité, données, parcours, sécurité et responsabilité dans une séquence testable, sans confondre coexistence contrôlée, duplication permanente et dette de transition.
- À prioriser : comptes privilégiés, révocations, récupération, délégations et parcours traversant plusieurs applications pendant une session.
- À surveiller : collisions de comptes, boucles, sessions non confirmées, versions de rôle anciennes et exceptions sans date de retrait.
- À refuser : mot de passe recopié, cookie partagé, permission implicite ou rollback qui réactive une ancienne autorité locale.
Conclusion : déplacer les parcours sans diviser les personnes
Le strangler peut faire coexister deux applications, mais il ne doit produire ni deux identités, ni deux credentials, ni deux décisions concurrentes sur les droits d’une même personne.
Une autorité commune stabilise le subject, la passerelle adapte les preuves et les politiques métier restent versionnées. Sessions puis révocations traversent les deux chemins avec une latence mesurée.
Le succès se mesure par moins de tickets, aucune persistance d’accès après révocation et des cohortes capables de revenir sans restaurer les faiblesses de sécurité du legacy.
Pour cadrer cette transition, l’accompagnement de notre expertise en migration d’applications legacy vers Symfony relie identité, coutures, sécurité et bascule afin que chaque module migre sans fragmenter les utilisateurs.
