Aller au contenu principal
Expert Cybersécurité & IAv9.0
Centres de ressources conformité
Besoin d'un accompagnement expert ?
Devis personnalisé sous 24h — audit, conformité, incident
Checklists Sécurité — Audit & Durcissement
Formats disponibles
📄 PDF 📊 Excel 🌐 Web

11 checklists professionnelles couvrant 2 200+ points de contrôle. Téléchargement gratuit, aucune inscription.

SAML 2.0

general

Définition

SAML 2.0 (Security Assertion Markup Language) est un protocole XML standardisé par OASIS pour l'échange d'informations d'authentification et d'autorisation entre un fournisseur d'identité (IdP — Identity Provider) et un fournisseur de service (SP — Service Provider). Il est le standard dominant pour le Single Sign-On (SSO) en entreprise, permettant à un utilisateur de s'authentifier une seule fois sur son IdP (Azure AD, Okta, Ping Identity) et d'accéder à de nombreuses applications sans ré-authentification. Le flux SAML 2.0 le plus courant est le SP-Initiated SSO : l'utilisateur accède à une application (SP), est redirigé vers l'IdP pour authentification, l'IdP authentifie l'utilisateur et génère une assertion SAML signée (XML) contenant l'identité et les attributs de l'utilisateur, puis redirige l'utilisateur vers le SP avec cette assertion. Le SP vérifie la signature de l'assertion contre la clé publique de l'IdP et crée une session locale. Les composants clés d'une assertion SAML incluent : l'émetteur (Issuer — l'IdP), le sujet (Subject — l'identité de l'utilisateur), les conditions (Conditions — fenêtre temporelle de validité), les déclarations d'authentification (AuthnStatement — méthode d'authentification), et les déclarations d'attributs (AttributeStatement — attributs supplémentaires comme les groupes, l'email, le rôle). Les assertions sont signées numériquement avec X.509/RSA ou ECDSA par l'IdP. SAML 2.0 est particulièrement adapté aux intégrations enterprise SSO pour les applications SaaS professionnelles (Salesforce, ServiceNow, Workday, Jira, Confluence, Office 365 legacy). Sa maturité (2005) et sa large adoption en font le standard de facto pour les intégrations B2B et les applications d'entreprise traditionnelles. Les vulnérabilités SAML connues incluent : les attaques par signature wrapping (XSW) qui manipulent la structure XML pour injecter des assertions malveillantes, les vulnérabilités de parsing XML (XXE, SSRF via les URLs metadata), et les assertions mal validées (vérification incomplète de l'audience, de l'expiration, ou de la signature). Des outils comme SAMLraider permettent aux pentesters de tester ces vulnérabilités dans les implémentations SAML. SAML 2.0 est souvent comparé à OAuth 2.0 + OpenID Connect (OIDC) : SAML est XML-based, plus verbeux, idéal pour les applications web enterprise legacy ; OIDC est JSON/REST-based, plus léger, idéal pour les applications mobiles et API modernes.

SP-Initiated vs IdP-Initiated SAML SSO

Le flux SP-Initiated SSO (le plus courant et le plus sécurisé) commence par l'utilisateur qui accède à l'application, est redirigé vers l'IdP via une AuthnRequest signée, s'authentifie sur l'IdP, et est redirigé vers le SP avec une SAMLResponse signée. Le flux IdP-Initiated SSO commence directement depuis le portail de l'IdP (bouton "Lancer l'application") — l'IdP génère une SAMLResponse sans AuthnRequest préalable. Ce second flux est moins sécurisé (absence de protection CSRF via le RelayState, risque de replay attacks) et doit être évité ou strictement contrôlé. De nombreuses politiques de sécurité enterprise désactivent le IdP-Initiated SSO pour les applications sensibles.

SAML vs OIDC — choisir le bon protocole

Pour les nouvelles applications, OpenID Connect (OIDC) est généralement préféré : il est plus simple à implémenter (JSON vs XML), mieux adapté aux architectures API-first et mobile-first, dispose d'un écosystème de bibliothèques plus large, et supporte nativement les tokens Bearer pour les API. SAML reste pertinent pour les applications d'entreprise existantes qui le supportent nativement (Salesforce, Workday, SAP, Microsoft SharePoint legacy) et pour les fédérations d'identités B2B inter-entreprises. Dans les grands environnements enterprise, les IdP (Azure AD, Okta) supportent les deux protocoles en parallèle, permettant d'utiliser SAML pour les legacy et OIDC pour les applications modernes.

Vulnérabilités SAML — XSW et validation des assertions

Les attaques XML Signature Wrapping (XSW) sont les vulnérabilités SAML les plus critiques. Un attaquant envoie une SAMLResponse avec une structure XML valide dont la signature pointe vers un nœud différent du nœud utilisé par l'application pour extraire l'identité. Si le SP lit l'identité depuis le mauvais nœud, il peut accepter une assertion forgée. La protection passe par l'utilisation de bibliothèques SAML auditées (pas d'implémentation maison), la validation stricte de la structure XML avant extraction des attributs, et l'activation de la validation de schema. Des CVE critiques affectant des solutions majeures (GitLab, Duo SSO, OmniAuth-SAML) illustrent la difficulté d'implémenter SAML correctement.

Articles liés

Un projet cybersécurité ?

Expert dispo · Réponse 24h

Devis