Bien qu'OIDC soit de plus en plus utilisé dans les applications modernes, SAML 2.0 reste un standard critique dans les intégrations d'identité d'entreprise et du secteur public. De nombreuses organisations exploitent leurs répertoires existants derrière AD FS, Entra ID, Okta, Ping, Auth0 ou une passerelle de fédération via SAML. Du côté public également, les fédérations d'identité nationales et les services SaaS qui leur sont rattachés reposent souvent sur SAML 2.0.
C'est pourquoi, pour une application nouvelle ou modernisée, la bonne approche n'est pas de créer une base d'utilisateurs distincte. L'application doit se connecter au fournisseur d'identité auquel l'organisation fait déjà confiance. Pour cela, la couche d'accès doit se comporter comme un fournisseur de services SAML 2.0 : elle doit rediriger l'utilisateur vers le bon IdP, vérifier la réponse SAML entrante, extraire l'identité en toute sécurité et la convertir en une session utilisable par l'application.
Mais l'intégration SAML n'est pas seulement une affaire de « prendre le XML, lire l'utilisateur, ouvrir une session ». Mal implémentée, elle produit de graves failles de sécurité. La signature de la réponse SAML doit être vérifiée correctement, il faut contrôler quel élément a réellement été signé et empêcher les attaques comme le retrait de signature ou l'injection d'assertions falsifiées. La durée de validité, la restriction d'audience, l'information d'issuer, le format du NameID et les mappings d'attributs ne doivent pas seulement être lus ; ils doivent être strictement appliqués.
Le côté opérationnel est tout aussi important. La mise à jour des métadonnées de l'IdP, la rotation des certificats et des clés de signature, le routage IdP différent par tenant, les règles de mapping différentes pour différentes applications et les flux de Single Logout ne sont pas de petits détails ajoutés après coup. Ce sont des éléments fondamentaux pour que la fédération SAML fonctionne de manière sûre et durable.
L'une des erreurs les plus courantes consiste à embarquer une bibliothèque SAML séparément dans chaque application. Cette approche distribue la responsabilité de l'identité à chaque backend. Un changement d'IdP nécessite une mise à jour distincte dans de nombreuses applications. La MFA, l'accès conditionnel, la confiance de l'appareil, le comportement de déconnexion et les journaux d'audit sont résolus à nouveau pour chaque application. Le résultat n'est pas une identité centralisée, mais une confusion d'identité distribuée.
Le bon endroit est la périphérie d'accès. SAML doit être terminé en un seul point ; il doit être géré dans la même couche que l'authentification, la MFA, l'accès conditionnel, la confiance de l'appareil et le SSO Backend. Ainsi les applications ne portent pas la complexité du protocole de fédération ; elles reçoivent seulement une identité vérifiée, propre et fiable.
Bien gérer SAML ne se résume pas à se connecter à un IdP. Il s'agit de vérifier, d'auditer la confiance d'identité de l'organisation en un seul point et de la transmettre en toute sécurité aux applications.
Une seule passerelle AAM termine SAML correctement à la périphérie ; le reste du moteur d'accès repose dessus.
AuthnRequest signée en sortie, vérification complète de l'assertion en entrée — signature, audience, fenêtre de validité, AudienceRestriction, format du NameID. Les bindings HTTP-Redirect et HTTP-POST sont tous deux pris en charge. Le traitement de la signature suit les règles de conformité SAML 2.0 existantes pour déjouer les attaques SAML connues.
Une seule passerelle AAM peut router simultanément différentes applications vers différents IdP, et différents tenants de la même application vers différents IdP. La sélection de l'IdP se fait par requête à partir du contexte de l'application — pas de passerelle distincte par IdP, pas de sélecteur de page de connexion manuel pour l'utilisateur.
Les règles de mapping par IdP convertissent le NameID et les déclarations d'attributs de l'assertion SAML vers les champs canoniques utilisés par le reste d'AAM — nom d'utilisateur, e-mail, groupes, nom d'affichage, attributs personnalisés. Le même mapping alimente le gating MFA, les expressions d'accès conditionnel, les journaux d'audit et les injections SSO Backend.
Une authentification SAML ne fonctionne pas seule — elle est composée avec la MFA en périphérie (si l'IdP n'a pas appliqué de step-up), les expressions d'accès conditionnel, l'évaluation continue de la confiance et l'injection SSO Backend vers le backend. L'assertion SAML devient une entrée de la session AAM ; elle ne devient pas toute la session.
Un SP SAML 2.0 conforme aux standards, plus les fonctionnalités opérationnelles qui rendent la fédération sûre et gérable à grande échelle.
L'utilisateur arrive sur l'application, AAM le redirige vers l'IdP configuré avec une AuthnRequest SAML signée, l'utilisateur se connecte à l'IdP et l'IdP renvoie l'assertion signée à l'endpoint Assertion Consumer Service d'AAM. Les bindings HTTP-Redirect pour la requête sortante et HTTP-POST pour l'assertion entrante sont tous deux pris en charge.
Pour les déploiements où le point de départ de l'utilisateur est l'IdP — une rampe de lancement de portail sur l'IdP, un catalogue d'applications, un portail d'identité du secteur public — le SSO initié par l'IdP est accepté. Le RelayState porte la destination d'application visée ; ainsi l'utilisateur atterrit sur la bonne page après la consommation de l'assertion.
La signature de l'assertion est vérifiée contre le certificat de signature de l'IdP configuré ; l'audience correspond à l'identifiant du SP AAM configuré ; NotBefore et NotOnOrAfter définissent la fenêtre de validité ; AudienceRestriction est appliquée. Les attaques SAML connues (signature wrapping, signature stripping, dérive NotBefore) sont explicitement déjouées plutôt que tolérées silencieusement.
Lorsque l'IdP chiffre l'assertion (xmlenc), AAM déchiffre l'assertion avec la clé privée du SP configurée avant la vérification. Les assertions chiffrées sont courantes pour la fédération d'identité du secteur public et pour les IdP qui ne veulent pas que le contenu de l'assertion soit lisible au niveau de la couche de binding. Les clés de chiffrement sont stockées de manière chiffrée dans le magasin de configuration et ne sont jamais journalisées.
Chaque IdP peut être configuré avec un format de NameID préféré (persistent, transient, email-address, unspecified) et un mapping des noms d'attributs SAML vers les champs de session AAM. Différents IdP peuvent présenter l'identité différemment — une revendication d'identifiant national, un e-mail, un identifiant opaque unique — et tout de même produire le même format de session canonique d'AAM.
Une seule passerelle AAM plaçant de nombreux tenants en façade peut router chaque tenant vers son propre IdP. La sélection se fait au moment de la requête à partir du contexte de l'application ou du tenant — pas de passerelle distincte par IdP, pas de sélecteur par utilisateur. La même passerelle peut transporter simultanément la fédération d'identité du secteur public pour un tenant et un IdP d'entreprise privé pour un autre tenant.
Lorsque l'IdP démarre une déconnexion, AAM accepte le SAML LogoutRequest, termine la session AAM et signale aux backends qui reçoivent l'injection SSO Backend. Lorsque l'application démarre la déconnexion, AAM envoie un LogoutRequest signé vers l'IdP et attend le LogoutResponse avant de déclarer la session terminée. Le SLO front-channel est pris en charge.
Le Single Logout back-channel basé sur SOAP, le profil SAML ECP (Enhanced Client/Proxy) pour les clients non navigateurs et la confirmation de sujet holder-of-key pour les intégrations à haute sécurité sont sur la feuille de route. L'objet de configuration et le reste du pipeline SP les prennent déjà en charge ; ce qui manque est le code spécifique au protocole.
Les mécanismes qui maintiennent une fédération SAML sûre, à jour et observable.
Les métadonnées de l'IdP peuvent être chargées en téléchargeant le XML de métadonnées fourni par l'IdP, en configurant une URL de métadonnées qu'AAM récupère et met en cache, ou en saisissant manuellement les endpoints et les certificats. La configuration manuelle est une option réaliste pour les IdP qui ne publient pas de métadonnées conformes aux standards ; là où elles fonctionnent, les deux autres méthodes sont préférées.
AAM publie son propre document de métadonnées SP à une URL stable ; ainsi l'opérateur de l'IdP peut l'importer dans le magasin de confiance de l'IdP au lieu de transférer manuellement les endpoints et les certificats. Les métadonnées reflètent la configuration SP active — URL ACS actuelle, certificat de signature actuel, endpoint SLO actuel.
Les clés de signature et les certificats du SP ont une durée de vie limitée. AAM prend en charge la rotation des clés avec chevauchement — pendant la fenêtre de rollover, l'ancienne et la nouvelle clé sont vérifiées contre les métadonnées mises en cache de l'IdP. Les opérateurs planifient la rotation à l'avance ; le runtime accepte les deux pendant la période de chevauchement et la rotation entre en service proprement.
Les assertions portent des horodatages NotBefore et NotOnOrAfter. Les vraies horloges dérivent ; AAM applique une fenêtre de tolérance configurable ; ainsi une petite dérive ne rejette pas les assertions valides, tandis qu'une grande dérive (indicateur de mauvaise configuration ou de rejeu) est tout de même rejetée. La tolérance est par IdP ; un IdP bien synchronisé reçoit une fenêtre étroite, un IdP problématique reçoit une permission documentée.
Chaque événement SAML — AuthnRequest sortante, assertion entrante, résultat de la vérification de signature, SLO LogoutRequest, LogoutResponse — est enregistré avec un ID de corrélation qui revient à la session AAM, au(x) backend(s) derrière elle et à l'identité de l'utilisateur. La question « qui s'est connecté via quel IdP et quand » se répond avec une seule requête.
Le rafraîchissement automatique périodique des métadonnées de l'IdP depuis l'URL configurée, la détection des différences et l'alerte de l'opérateur en cas de changement de certificat de signature sont sur la feuille de route. La télémétrie de rotation — métriques d'âge des clés, alerte de jours restants avant l'expiration, planification automatique du rollover — est également planifiée.
Les applications qui doivent accepter un IdP de fédération d'identité nationale — typique des déploiements du secteur public, des secteurs réglementés et des services SaaS sous contrat avec des acheteurs publics. AAM termine la fédération SAML à la périphérie et présente une identité propre et vérifiée à l'application derrière elle.
Les IdP d'entreprise existants déjà faisant autorité pour la main-d'œuvre. AAM s'enfiche comme un SP SAML sans demander à l'équipe IdP de changer quoi que ce soit. Les nouvelles applications rejoignent la fédération non pas en ajoutant une nouvelle bibliothèque SAML à chaque base de code, mais en ajoutant un enregistrement dans AAM.
Des applications SaaS où chaque client apporte son propre IdP. Une seule passerelle AAM place tous les tenants en façade ; le trafic de chaque tenant est routé vers l'IdP de ce tenant. Ajouter un tenant n'est pas un déploiement ; c'est ajouter un enregistrement d'IdP au magasin de configuration.
Certains IdP authentifient mais n'appliquent pas la MFA step-up ou l'accès conditionnel — en particulier les anciennes passerelles de fédération. AAM accepte l'authentification de l'IdP, puis fait reposer sa propre MFA, ses expressions d'accès conditionnel et son évaluation continue de la confiance par-dessus, avant d'accorder l'accès à l'application.
Connectons AAM à votre IdP — d'entreprise ou de fédération d'identité du secteur public — et faisons reposer le reste du moteur d'accès, avec MFA, accès conditionnel, confiance de l'appareil et SSO Backend, sur l'assertion.