SAML (Security Assertion Markup Language)

Définition

Le SAML (Security Assertion Markup Language) est un standard ouvert basé sur XML pour l’échange de données d’authentification et d’autorisation entre parties — spécifiquement entre un fournisseur d’identité (IdP) et un fournisseur de service (SP).

Le SAML est la base du Single Sign-On (SSO) pour les applications d’entreprise. Lorsqu’un utilisateur se connecte à son IdP corporatif, les jetons SAML lui donnent accès à plusieurs applications sans se réauthentifier.

Flux SAML (Browser SSO)

Utilisateur → SP (ex. Salesforce)
  │
  │ 1. L'utilisateur demande l'accès
  │
  │ 2. SP → Utilisateur : « Redirection vers l'IdP pour l'authentification » (SAML AuthRequest)
  │
  Utilisateur → IdP (ex. Okta/Azure AD)
  │
  │ 3. L'utilisateur s'authentifie à l'IdP
  │
  │ 4. IdP → Utilisateur : Réponse SAML (XML signé)
  │
  Utilisateur → SP
  │
  │ 5. Le SP valide la signature SAML, crée une session
  │
  ▼
  L'utilisateur est connecté au SP (SSO terminé)

Composants SAML

|| Composant | Description | ||———–|————-| || IdP (Identity Provider) | Authentifie les utilisateurs, émet des assertions SAML (Okta, Azure AD, Keycloak) | || SP (Service Provider) | Application qui fait confiance à l’IdP (Salesforce, Slack, Jira) | || Assertion SAML | Document XML contenant les revendications d’authentification/d’autorisation | || Réponse SAML | Assertion signée envoyée de l’IdP au SP | || Requête SAML (AuthRequest) | Demande d’authentification du SP | || Métadonnées | Configuration XML décrivant les points de terminaison et certificats IdP/SP | || URL SSO | Point de terminaison IdP pour l’authentification | || URL ACS | URL du service consommateur d’assertions (où le SP reçoit la Réponse SAML) |

Exemple d’assertion SAML (simplifié)

<saml2:Assertion xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion">
  <saml2:Issuer>https://idp.example.com</saml2:Issuer>
  <ds:Signature>...</ds:Signature>
  <saml2:Subject>
    <saml2:NameID>user@example.com</saml2:NameID>
  </saml2:Subject>
  <saml2:AuthnStatement>
    <saml2:AuthnContext>
      <saml2:AuthnContextClassRef>
        urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport
      </saml2:AuthnContextClassRef>
    </saml2:AuthnContext>
  </saml2:AuthnStatement>
  <saml2:AttributeStatement>
    <saml2:Attribute Name="email">
      <saml2:AttributeValue>user@example.com</saml2:AttributeValue>
    </saml2:Attribute>
    <saml2:Attribute Name="role">
      <saml2:AttributeValue>admin</saml2:AttributeValue>
    </saml2:Attribute>
  </saml2:AttributeStatement>
</saml2:Assertion>

SAML vs OAuth 2.0 vs OIDC

|| Fonctionnalité | SAML | OAuth 2.0 | OIDC | ||—————-|——|———–|——| || Objectif | Authentification | Autorisation | Authentification | || Format | XML | JWT | JWT | || SSO | Oui | Non (en soi) | Oui | || Cas d’utilisation | SSO entreprise | Accès API | Web/mobile moderne | || Complexité | Élevée (XML, signatures) | Modérée | Modérée | || Adoption | Entreprise, hérité | APIs, microservices | Applications modernes | || Standard | OASIS (2002) | IETF (2012) | OASIS (2014) |

SAML vs OIDC

|| Aspect | SAML | OIDC | ||——–|——|——| || Protocole | Basé sur XML | Basé sur JSON (JWT) | || Complexité | Élevée | Faible | || Support mobile | Faible | Excellent | || Entreprise | Dominant | En croissance | || Expérience développeur | Difficile | Facile | || Compatibilité arrière | Applications legacy | Applications modernes | || Exemples IdP | Okta, Azure AD, ADFS | Okta, Auth0, Keycloak |

SAML dans l’infrastructure

|| Composant | Rôle SAML | ||———–|———–| || IdP | Okta, Azure AD, Keycloak, OneLogin | || SP | Salesforce, Slack, Jira, GitHub Enterprise | || SSO | Single sign-on pour les applications d’entreprise | || Fédération | Partage d’identité inter-organisations | || MFA | Les assertions SAML incluent le statut MFA |

Limitations de SAML

  • Complexité XML : Difficile à implémenter correctement
  • Dépendant du navigateur : S’appuie sur des redirections HTTP et des POST de formulaires
  • Pas de support mobile : Conçu pour les navigateurs web
  • Gestion des certificats : La rotation des certificats SP/IdP est manuelle
  • Débogage : Difficile de résoudre les erreurs SAML
  • Pas adapté aux APIs : Utilisez OAuth 2.0/OIDC pour l’accès API

Termes associés

  • OAuth — OAuth gère l’autorisation ; SAML gère l’authentification
  • OIDC — OpenID Connect est le remplacement moderne de SAML
  • SSO — SAML est le protocole SSO principal pour les entreprises
  • Pki — SAML fait partie de la gestion des identités et des accès
  • MFA — SAML peut affirmer que la MFA a été complétée

Références