De nombreuses applications fonctionnant en entreprise — portails internes, systèmes de facturation, consoles d'opérations, panneaux d'administration fournis par des éditeurs, outils métier legacy — ont été construites avant que SAML ou OIDC ne se généralisent. Elles reconnaissent généralement l'utilisateur non pas via des tokens modernes, mais via un en-tête HTTP, un identifiant Basic-Auth ou un cookie de session qu'elles font déjà confiance.
Migrer ces applications vers un SSO moderne semble simple en théorie : réécrire le chemin d'authentification backend, ajouter la prise en charge SAML/OIDC et connecter l'application au fournisseur d'identité central. En pratique, cela n'arrive presque jamais. Le code source peut être ancien, l'application peut appartenir à un éditeur tiers, le changement peut perturber un processus métier réglementé, ou le coût n'est tout simplement pas justifié pour un outil interne qui fonctionne.
Les organisations se retrouvent alors à choisir entre deux mauvaises options : laisser les applications legacy en dehors du périmètre d'identité moderne, ou construire une intégration fragile et distincte pour chacune. Le résultat est une expérience utilisateur fragmentée, un contrôle d'accès décentralisé et une logique d'identité dispersée dans le modèle legacy de chaque backend.
La bonne approche consiste à positionner la couche d'accès moderne en amont de l'application. L'utilisateur passe d'abord par les contrôles d'identité centraux, de MFA, d'accès conditionnel et de confiance dispositif ; l'identité authentifiée est ensuite traduite dans un format que le backend comprend déjà. L'application bénéficie d'une expérience SSO moderne sans modification de code.
Mais cette transition doit être réalisée avec soin. Si les en-têtes d'identité usurpés de l'utilisateur sont transmis au backend sans être supprimés, n'importe qui peut ajouter son propre en-tête X-Auth-User à sa requête et usurper l'identité d'un autre utilisateur. La passerelle doit supprimer les valeurs entrantes non fiables, injecter uniquement l'identité fiable qu'elle produit elle-même, et délimiter cela strictement par route.
La déconnexion, la perte de session et l'état d'identité piloté par le backend doivent également transiter par le même moteur. Sinon, l'utilisateur peut sembler déconnecté du portail tandis que la session backend reste active, ou la session backend peut tomber sans que la couche d'accès ne s'en aperçoive.
Le Backend SSO ne consiste pas à forcer la réécriture des applications legacy — il s'agit de placer le contrôle d'identité moderne en amont de l'application, et de traduire en toute sécurité l'identité de l'utilisateur authentifié dans le langage que le backend accepte déjà.
Un objet de configuration par backend, cinq formes d'injection, coordonnés avec le reste du moteur d'accès.
Chaque règle d'injection commence par supprimer toute copie entrante de l'en-tête cible, du cookie ou de la valeur Authorization, puis injecte la version dérivée de la session authentifiée. Un utilisateur qui envoie son propre en-tête "X-Auth-User" ne peut pas usurper l'identité d'autrui — son en-tête est supprimé avant que la passerelle n'ajoute celui de confiance.
En-têtes personnalisés (X-Auth-User, X-Forwarded-User, tout ce qu'attend le backend), Authorization Basic pour les applications qui nécessitent une paire nom d'utilisateur:mot de passe, Authorization Bearer pour les backends compatibles avec les tokens, fusion de valeur de cookie pour les applications qui lisent un cookie nommé, et SAML-SP pour les backends qui attendent une assertion SAML signée. Chaque injection a sa propre configuration ; un seul backend peut utiliser plusieurs formes simultanément.
Chaque règle d'injection porte sa propre expression de condition — n'appliquer que sur le chemin admin, uniquement quand un attribut de session spécifique est présent, uniquement pour un locataire. Le même backend peut recevoir une identité plus riche sur les routes privilégiées et un sous-ensemble minimal sur les routes publiques.
Quand le backend signale que la session de l'utilisateur a disparu (une forme de réponse connue par service), ou quand le backend lui-même déconnecte l'utilisateur, AAM détecte le signal, nettoie la session côté passerelle et redirige selon la politique configurée. La priorité logout-wins garantit que le nettoyage s'effectue toujours avant toute injection ultérieure.
Cinq formes d'injection en production, la discipline de suppression des entrées qui les rend sûres, ainsi que la feuille de route pour les injections de protocoles de niveau supérieur.
La forme la plus simple et la plus courante. Configurez un nom d'en-tête (X-Auth-User, X-Forwarded-User, REMOTE_USER, ce que le backend lit) et la variable intelligente qui produit la valeur (nom d'utilisateur, e-mail, liste de groupes, nom d'affichage). L'en-tête est supprimé des requêtes entrantes, puis rajouté depuis la session authentifiée avant que la requête n'atteigne le backend.
Pour les applications legacy qui s'authentifient via HTTP Basic, la passerelle injecte Authorization: Basic
Pour les backends qui parlent déjà en Bearer tokens (API internes, microservices, applications intranet modernes) AAM injecte Authorization: Bearer
Les applications qui lisent l'identité depuis un cookie nommé sont prises en charge avec l'injection de valeur de cookie. La passerelle fusionne la paire name=value injectée dans l'en-tête Cookie de la requête sans écraser les autres cookies — la plus susceptible aux erreurs des quatre formes de style en-tête, traitée avec une logique de fusion explicite plutôt que des écrasements naïfs.
Pour les backends qui attendent une assertion SAML signée sur chaque requête, la passerelle génère une assertion SAML 2.0 depuis la session authentifiée, la signe avec la clé de signature SAML d'AAM et la transmet sur l'en-tête configuré au backend. Typique pour les intégrations de fédération d'identité du secteur public et les backends SaaS d'entreprise. L'utilisateur se connecte avec un IdP moderne ; le backend reçoit une assertion SAML fraîche et délimitée à chaque requête.
Chaque injection est couplée à une suppression entrante de la même cible. Un utilisateur qui définit X-Auth-User dans sa propre requête, qui envoie un Cookie forgé avec une valeur d'identité falsifiée, ou qui rejoue un en-tête Authorization depuis ailleurs ne peut pas faire survivre la valeur à travers la passerelle. L'injection ne s'exécute qu'après que la suppression a vidé le slot.
Chaque règle d'injection peut attacher une condition — même langage d'expression que la politique d'accès conditionnel. N'injecter que sur le chemin admin ; n'injecter que lorsque l'utilisateur est dans un groupe spécifique ; n'injecter la variante privilégiée que lorsqu'un attribut est présent. Les conditions sont compilées de manière sécurisée par rapport à la priorité ACL, de sorte que plusieurs règles sur un même backend se composent correctement.
Toutes les injections sont conditionnées à l'état authentifié — elles ne s'exécutent que lorsque la requête porte une session AAM valide. Un utilisateur qui contourne l'authentification via une route mal configurée ne peut pas recevoir accidentellement des identifiants backend injectés ; une requête anonyme atteint toujours le backend sans injection.
Les formes d'injection de protocoles de niveau supérieur — délégation contrainte Kerberos pour les backends qui nécessitent un ticket de service, NTLM pour les environnements Windows anciens — sont sur la feuille de route. L'objet de configuration et la plomberie conditionnelle les accommodent déjà ; le runtime spécifique au protocole est le travail restant.
Les mécanismes qui rendent l'injection de niveau en-tête sûre à la bordure d'accès.
Les conditions par injection se composent avec les autres décisions pilotées par ACL de la passerelle (état d'authentification, politique d'accès, sélection du backend). Le compilateur de conditions utilise un pattern d'entrées supplémentaires de sorte que les conditions d'injection s'évaluent toujours après l'authentification et la politique, jamais avant — une règle par injection ne peut pas accidentellement inverser le résultat d'une décision de politique de priorité supérieure.
Lorsqu'une injection a besoin d'une valeur qui n'est pas dans le sac de session — une valeur dérivée d'une récupération par requête (expansion de groupe, recherche d'attribut) — le dispatcher émet une récupération conditionnelle qui ne s'exécute que lorsque la condition de l'injection correspond. Les backends qui ne voient jamais d'injection ne paient jamais le coût de la récupération de la valeur.
Chaque service peut déclarer la signature de réponse qui signifie « ma session a disparu » — un code de statut spécifique, un en-tête de réponse spécifique, un marqueur de corps. Lorsque la passerelle voit cette signature, elle marque l'indicateur de perte de session, nettoie la session côté passerelle et redirige selon la politique configurée.
Lorsque le backend lui-même déconnecte l'utilisateur — typiquement en répondant avec une signature de déconnexion connue — la passerelle exécute un nettoyage en trois étapes : effacer les cookies côté passerelle, supprimer l'enregistrement de session et rediriger via la cible configurée. La priorité logout-wins garantit que ce chemin prend la priorité sur toute injection en cours.
Les identifiants et tokens utilisés par les injections sont stockés chiffrés dans le store de configuration et ne sont jamais écrits en clair dans les logs d'accès. Les entrées d'audit enregistrent qu'une injection s'est exécutée sur une requête, pas la valeur qu'elle portait. Les opérateurs voient la politique ; la charge utile sur le fil reste sur le fil.
Un flux de ré-authentification silencieuse qui utilise un 302 vers le daemon AAM pour rétablir une session backend sans renvoyer l'utilisateur vers une page de login est sur la feuille de route. La propagation de déconnexion initiée par AAM — pousser un signal de déconnexion vers chaque backend qui a reçu une identité injectée — est également sur la feuille de route.
Un portail interne qui faisait confiance à X-Remote-User depuis une décennie continue de lire X-Remote-User. La passerelle exécute le SAML/OIDC moderne à la bordure, puis injecte le même en-tête qu'elle a toujours vu. Pas de déploiement backend, pas de bascule de migration.
Un cluster de microservices internes souhaite une authentification par Bearer token mais ne veut pas exécuter un flux d'identité par service. La passerelle émet un token signé par requête et l'injecte ; chaque service vérifie le token par rapport aux clés de la passerelle.
Un déploiement multi-applications comprend une application qui veut Basic Auth, une qui veut un en-tête personnalisé et une qui veut un cookie. Une seule passerelle AAM gère le login une fois ; chaque backend reçoit la forme qu'il attend, simultanément, avec des conditions par route.
Les régimes de conformité qui exigent une chaîne d'identité claire — « qui était authentifié lorsque cette requête a atteint le backend » — obtiennent cette chaîne produite par le flux d'audit de la passerelle. Les valeurs d'en-tête, les conditions d'injection et le sujet authentifié sont enregistrés ensemble.
Nous déploierons le Backend SSO contre vos applications réelles — en conservant leur modèle de confiance existant, en retirant l'identifiant des mains de l'utilisateur et en produisant une chaîne d'identité de qualité audit pour chaque requête.