Qu'est-ce que SAML (Security Assertion Markup Language) ?

Qu'est-ce que SAML ?

SAML (Security Assertion Markup Language) est un standard ouvert basé sur XML pour échanger des données d'authentification et d'autorisation entre un Identity Provider (IdP) et un Service Provider (SP). Standardisé en 2005, SAML 2.0 est le protocole SSO entreprise dominant — quand une app SaaS dit "SSO supporté", elles veulent presque toujours dire SAML 2.0. Slack, Salesforce, AWS, Workday, Zoom et des milliers d'autres applications entreprise supportent toutes SAML.

Le mécanisme central : quand un utilisateur essaie de se connecter à un Service Provider (votre app), le SP le redirige vers l'Identity Provider (Okta, Microsoft Entra ID, Google Workspace, Auth0). L'IdP authentifie l'utilisateur (vérifie le mot de passe, impose MFA), puis émet un document XML signé numériquement appelé assertion SAML. Le navigateur de l'utilisateur ramène cette assertion au SP, qui vérifie la signature contre la clé publique de l'IdP et fait confiance que l'utilisateur est qui l'IdP dit qu'il est.

Le flow SAML (SP-initié, le cas courant)

1. L'utilisateur accède au SP (ex. https://app.example.com) et clique "Se connecter avec SSO".
2. Le SP redirige vers l'IdP avec une AuthnRequest SAML — un message XML disant "merci d'authentifier cet utilisateur pour moi". La redirection passe par le navigateur de l'utilisateur via binding HTTP-Redirect ou HTTP-POST.
3. L'IdP authentifie l'utilisateur. Username + mot de passe, puis MFA, possiblement des politiques d'accès conditionnel. Si l'utilisateur a déjà une session IdP active, cette étape est invisible.
4. L'IdP génère une Response SAML. Un document XML contenant une ou plusieurs assertions avec des claims sur l'utilisateur (nom, email, appartenances à des groupes), signé numériquement avec la clé privée de l'IdP.
5. L'IdP redirige le navigateur de l'utilisateur vers l'URL ACS du SP (Assertion Consumer Service) avec la Response signée, typiquement comme corps HTTP POST encodé en base64.
6. Le SP valide la Response. Vérifie la signature contre le certificat public publié de l'IdP, valide les timestamps (NotBefore/NotOnOrAfter), vérifie que l'audience correspond à son entity ID attendu. Si tout est ok, le SP crée une session locale pour l'utilisateur.

L'utilisateur vit typiquement ça comme une seule redirection de navigateur — il clique "Se connecter", voit brièvement la page IdP (ou pas) et atterrit dans l'app déjà authentifié. Temps total écoulé : 1-3 secondes.

Ce qu'il y a dans une assertion SAML (le payload XML)

Une Response SAML 2.0 typique contient :

• Issuer : Quel IdP a signé ça — utilisé pour rechercher la bonne clé publique.
• Signature : La signature numérique XML sur la Response (ou l'Assertion dedans).
• Subject : Identifie l'utilisateur, typiquement comme NameID (email, UUID ou identifiant transient/persistent).
• Conditions : Timestamps NotBefore et NotOnOrAfter qui bornent quand l'assertion est valide (normalement une fenêtre de 5 minutes).
• AudienceRestriction : À quel SP cette assertion est destinée. Si l'entity ID du SP ne correspond pas, rejeter.
• AuthnStatement : Quand et comment l'utilisateur s'est authentifié (mot de passe, MFA, etc.).
• AttributeStatement : Attributs custom que l'IdP inclut — email, prénom/nom, appartenances à des groupes, département, manager, ID employé. Le SP les utilise pour provisionner et autoriser l'utilisateur.

Pourquoi SAML est verbose (et pourquoi il persiste malgré ça)

SAML est célèbrement complexe : namespaces XML, certificats X.509, plusieurs options de signature/chiffrement, des dizaines de champs optionnels. Comparé aux JSON Web Tokens (JWT) utilisés dans OpenID Connect, un message SAML est 10-50× plus grand en octets.

Alors pourquoi SAML domine-t-il toujours le SSO entreprise ?

• Effet réseau. Chaque IdP majeur et chaque SaaS entreprise supporte déjà SAML. Les coûts de basculement sont énormes.
• Outillage mature. 20 ans de librairies, débogueurs, IdPs de test. Les équipes de marchés savent comment évaluer le support SAML.
• Habitudes entreprise. Les acheteurs exigent explicitement SAML dans les RFPs. "OIDC-only" est rédhibitoire pour la plupart des marchés importants.
• Profondeur de sécurité véritable. SAML supporte des cas d'usage complexes (assertions chiffrées, chiffrement d'attributs, signature multi-tier) que les protocoles plus simples gèrent maladroitement.

Pour les nouvelles intégrations entre systèmes modernes, OpenID Connect (construit sur JWT et OAuth 2.0) est plus simple et de plus en plus préféré. Pour le SaaS entreprise, SAML est toujours requis — la plupart des systèmes en production supportent les deux.

Gotchas courants d'implémentation SAML

• Décalage d'horloge. Les assertions SAML ont des timestamps NotBefore et NotOnOrAfter. Si les horloges de l'IdP et du SP diffèrent de plus que la tolérance configurée (normalement 60-300 secondes), l'authentification échoue. Synchronisez tout via NTP.
• Rotation de certificats. Les signatures SAML utilisent des certificats X.509 qui expirent (typiquement 1-3 ans). Échouer à faire tourner avant l'expiration fait tomber le SSO à 03:00 un mardi. Les rappels calendrier sont obligatoires ; l'échange de métadonnées (auto-rotation) est rare en pratique.
• Mappage des claims de groupe. L'IdP envoie les groupes dans l'assertion ; le SP doit les mapper à des rôles locaux. Les mappages de groupe mal configurés sont la source #1 de tickets "pourquoi je ne suis pas admin ?".
• SP-initié vs IdP-initié. Certaines apps SaaS supportent les deux ; certaines seulement SP-initié. IdP-initié (l'utilisateur démarre dans le dashboard Okta, clique sur la tuile du SP) est pratique mais introduit des considérations de sécurité — le SP doit accepter des assertions qu'il n'a pas demandées.
• Format NameID. Différents IdPs par défaut à différents formats NameID (email vs UUID persistant vs transient). Le SP doit s'accorder sur lequel attendre ou le matching casse.
• Protection de replay. Le SP doit se souvenir des IDs des assertions récemment validées et rejeter les doublons. Sans ça, les assertions interceptées peuvent être rejouées.

SAML vs OIDC vs OAuth 2.0

Les trois protocoles souvent confondus :

• SAML 2.0 : Standard d'authentification basé sur XML. Dominant en SSO entreprise. Verbose mais robuste.
• OAuth 2.0 : Framework d'autorisation — "cette app peut-elle accéder aux données de cet utilisateur ?" N'établit pas l'identité tout seul.
• OpenID Connect (OIDC) : Couche d'authentification construite sur OAuth 2.0. Basé sur JSON, tokens JWT. Moderne, plus simple que SAML. Alimente "Se connecter avec Google/Apple/Microsoft".

Guide pratique : implémentez OIDC pour les inscriptions self-service / consumer (plus simple, JSON-friendly) ; ajoutez SAML pour les clients entreprise (obligatoire pour beaucoup d'équipes de marchés).

FAQ : SAML

SAML est-il toujours pertinent en 2026 ?

Oui — pour le SSO entreprise, c'est toujours le standard dominant. OIDC gagne du terrain pour les nouvelles intégrations et l'auth consumer, mais la base installée entreprise de SAML signifie qu'il sera requis dans un avenir prévisible. Prévoyez de supporter les deux.

Quelle est la différence entre SAML et OAuth ?

Buts différents. SAML est authentification-first ("qui est cet utilisateur ?"). OAuth est autorisation-first ("cette app peut-elle accéder aux ressources de cet utilisateur ?"). Ils sont souvent combinés — SAML pour SSO, OAuth pour accès API. OIDC fusionne les deux en ajoutant des claims d'identité à OAuth.

Pourquoi SAML utilise-t-il XML quand JSON est partout maintenant ?

Accident historique. SAML 2.0 a été finalisé en 2005, avant que JSON ne domine le web. Quand JSON est devenu le default, la base installée entreprise de SAML était trop grande pour migrer. Les nouveaux protocoles (OIDC) utilisent JSON ; SAML reste XML par compatibilité.

SAML est-il sécurisé ?

Oui quand correctement implémenté. Le protocole est bien spécifié et battle-tested. La plupart des breaches SAML viennent de bugs d'implémentation (failles de validation de signature, attaques de replay) plutôt que de faiblesses de protocole. Utilisez une librairie SAML battle-tested ; ne faites pas le parsing XML à la main.

Comment déboguer une intégration SAML ?

Outils : extension SAML-tracer Firefox (capture et décode les messages SAML), décodeurs SAML en ligne (collez les assertions encodées en base64, obtenez du XML lisible), logs de debug IdP (Okta, Auth0, Microsoft tous exposent des traces détaillées) et pages d'erreur SP avec mode verbose activé. La plupart des cassures SAML sont des mismatch de signature ou décalage d'horloge — vérifiez ceux-là en premier.

Qu'est-ce que SCIM et comment se rapporte-t-il à SAML ?

SCIM (System for Cross-domain Identity Management) automatise le provisioning d'utilisateurs entre IdP et SPs. SAML gère l'authentification (login) ; SCIM gère "crée cet utilisateur quand il est ajouté à l'IdP, supprime-le quand il est retiré". Ensemble, SAML + SCIM est le standard d'or pour le SaaS entreprise géré.

Comment LoadFocus se rapporte au SAML SSO

LoadFocus supporte SAML 2.0 SSO sur les plans Enterprise (à côté d'OIDC). Pour les tests de charge d'apps qui utilisent l'auth SAML, nos tests de charge supportent les flows OAuth pour les tokens service-à-service — le pattern typique est d'utiliser un compte de service avec échange de token plutôt que SAML basé navigateur pour le trafic synthétique. Le monitoring d'API valide que les endpoints protégés par SAML répondent correctement quand déclenchés par l'automatisation.