SAML 2.0

SAML 2.0 (Security Assertion Markup Language) est un standard OASIS publié en 2005. Il a permis le SSO web entre organisations bien avant OpenID Connect, et il reste très présent dans les progiciels d’entreprise, les universités et les administrations. Keycloak le gère aux côtés d’OIDC. Ce cours en donne les mécanismes essentiels.

Les acteurs et la relation de confiance

SAML reprend les rôles vus au premier cours :

l’IdP (Identity Provider) authentifie l’utilisateur et émet des assertions ;
le SP (Service Provider) est l’application qui consomme ces assertions ;
l’utilisateur et son navigateur portent les messages de l’un à l’autre.

Chaque acteur est désigné par un entityID, un identifiant unique souvent écrit sous forme d’URL, par exemple https://portail.exemple.fr/saml. Contrairement à OIDC, le SP et l’IdP ne communiquent généralement pas directement : tout passe par le navigateur.

Les métadonnées

La confiance se configure en échangeant des métadonnées : un fichier XML qui décrit chaque partie. Celles d’un SP contiennent son entityID, l’adresse de son ACS (Assertion Consumer Service, l’endpoint qui reçoit les assertions), les formats de NameID acceptés et ses certificats.

<md:EntityDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata"
    entityID="https://portail.exemple.fr/saml">
  <md:SPSSODescriptor AuthnRequestsSigned="true"
      WantAssertionsSigned="true"
      protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
    <md:KeyDescriptor use="signing">
      <ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
        <ds:X509Data><ds:X509Certificate>MIIC...</ds:X509Certificate></ds:X509Data>
      </ds:KeyInfo>
    </md:KeyDescriptor>
    <md:NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:persistent</md:NameIDFormat>
    <md:AssertionConsumerService index="0"
        Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
        Location="https://portail.exemple.fr/saml/acs"/>
  </md:SPSSODescriptor>
</md:EntityDescriptor>

Il n’existe pas d’équivalent universel de la discovery OIDC : on télécharge les métadonnées de l’autre partie, ou on les importe à la main. Les certificats qu’elles contiennent sont la base de la confiance. Quand un certificat est renouvelé, il faut redistribuer les métadonnées.

Le déroulement d’un SSO initié par le SP

Le scénario le plus courant démarre sur l’application.

Il existe aussi un SSO initié par l’IdP : l’utilisateur part d’un portail de l’IdP qui envoie directement une assertion au SP, sans requête préalable. C’est pratique, mais moins sûr, car le SP reçoit une réponse qu’il n’a pas sollicitée.

Les bindings : comment les messages voyagent

Un binding décrit comment un message SAML est transporté sur HTTP. Deux sont omniprésents.

Binding	Transport	Usage habituel
HTTP-Redirect	Message compressé, encodé en Base64 puis placé dans l’URL (`SAMLRequest=...`)	Requêtes d’authentification et de déconnexion, courtes
HTTP-POST	Message encodé en Base64 dans un formulaire HTML soumis automatiquement	Réponses contenant une assertion, trop longues pour une URL

Le standard en définit d’autres, comme HTTP-Artifact (le navigateur ne transporte qu’une référence, que le SP échange ensuite directement auprès de l’IdP) ou SOAP pour les échanges serveur à serveur. Vous les rencontrerez plus rarement.

L’assertion et le NameID

L’assertion est le cœur de SAML : un document XML émis et signé par l’IdP. En voici une version allégée.

<saml:Assertion xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
    ID="_a75adf55-01d7-40cc" IssueInstant="2026-11-05T09:15:00Z" Version="2.0">
  <saml:Issuer>https://idp.exemple.fr/realms/demo</saml:Issuer>
  <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">...</ds:Signature>
  <saml:Subject>
    <saml:NameID Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent">
      8f3c2a10-5d4e-4b7a-9c1f-2e6d7a8b9c0d
    </saml:NameID>
  </saml:Subject>
  <saml:Conditions NotBefore="2026-11-05T09:14:30Z" NotOnOrAfter="2026-11-05T09:20:00Z">
    <saml:AudienceRestriction>
      <saml:Audience>https://portail.exemple.fr/saml</saml:Audience>
    </saml:AudienceRestriction>
  </saml:Conditions>
  <saml:AuthnStatement AuthnInstant="2026-11-05T09:14:58Z" SessionIndex="b2c4e6f8">
    <saml:AuthnContext>
      <saml:AuthnContextClassRef>
        urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport
      </saml:AuthnContextClassRef>
    </saml:AuthnContext>
  </saml:AuthnStatement>
  <saml:AttributeStatement>
    <saml:Attribute Name="email">
      <saml:AttributeValue>claire.martin@exemple.fr</saml:AttributeValue>
    </saml:Attribute>
  </saml:AttributeStatement>
</saml:Assertion>

On y retrouve les notions d’un ID token, sous une autre forme : l’émetteur (Issuer), le sujet (Subject), l’audience, la période de validité (Conditions), le moment et la méthode d’authentification (AuthnStatement), et des attributs.

Le NameID est l’identifiant de l’utilisateur transmis au SP. Son format compte beaucoup :

persistent : identifiant opaque et stable, propre à chaque couple IdP et SP ;
transient : identifiant opaque, différent à chaque session ;
emailAddress : l’adresse e-mail, lisible mais susceptible de changer ;
unspecified : le format est laissé à l’appréciation des deux parties.

Un SP qui stocke des données par utilisateur a besoin d’un identifiant stable. Choisir le format et la valeur du NameID est donc une décision d’intégration à part entière.

Les attributs posent la même question. SAML ne fixe pas leurs noms : un SP attend email, un autre mail, un troisième un identifiant de type URN. Chaque raccordement demande donc de s’accorder sur la liste des attributs, leur nom exact et leur format.

Signature et chiffrement

SAML s’appuie sur XML Signature et XML Encryption.

La signature garantit que le message vient bien de l’IdP et n’a pas été modifié. On peut signer la réponse entière, l’assertion, ou les deux. Le SP peut aussi signer ses requêtes.
Le chiffrement de l’assertion, avec la clé publique du SP, empêche le navigateur ou un intermédiaire de lire son contenu. Il est facultatif quand le transport est en HTTPS, mais certains SP l’exigent.

La déconnexion unique (SLO)

SAML définit un protocole de déconnexion : une LogoutRequest envoyée à chaque partie concernée, qui répond par une LogoutResponse. L’IdP se sert du SessionIndex reçu dans l’assertion pour savoir quelles sessions fermer. En pratique, quand la déconnexion passe par le navigateur, une seule application qui ne répond pas interrompt la chaîne. Beaucoup de SP n’implémentent d’ailleurs pas le SLO du tout. Testez-le application par application.

SAML et OpenID Connect

Critère	SAML 2.0	OpenID Connect
Format	XML, assertions	JSON, JWT
Signature	XML Signature	JWS
Configuration	Échange de métadonnées XML	Discovery `.well-known` et JWKS
Applications mobiles et SPA	Mal adapté	Prévu (PKCE, clients publics)
Appels d’API	Pas de modèle standard	Access token OAuth 2.0
Usage principal	SSO web d’entreprise, fédérations établies	Nouvelles applications, API, mobile

Pour une nouvelle application, OpenID Connect est presque toujours le bon choix. Vous rencontrerez pourtant encore SAML dans plusieurs cas : progiciels du marché qui ne proposent que lui, fédérations académiques et de recherche, intégrations historiques entre organisations. Un IdP comme Keycloak permet de servir les deux protocoles à partir des mêmes comptes, ce qui évite d’imposer un choix aux applications.