Qu'est-ce que SAML 2.0 ?

SAML 2.0 en bref#

SAML 2.0 (Security Assertion Markup Language) est un standard de fédération d’identité. Il permet à un service spécialisé, le fournisseur d’identité, d’authentifier un utilisateur une fois, puis de transmettre à d’autres applications la preuve de cette authentification, sous la forme d’un document XML signé : l’assertion.

Quand un salarié ouvre son outil de notes de frais, sa messagerie ou son intranet sans retaper son mot de passe, parce qu’il s’est déjà connecté le matin sur le portail de son entreprise, il y a de bonnes chances que SAML soit à l’œuvre.

La norme a été adoptée par le consortium OASIS en 2005. Elle est antérieure à OpenID Connect et reste le protocole de référence des applications d’entreprise : logiciels RH, outils de gestion, services en ligne vendus aux organisations.

Pourquoi SAML existe#

Sans fédération, chaque application gère ses propres comptes. L’utilisateur accumule les mots de passe, l’entreprise ne sait plus désactiver proprement un compte au départ d’un salarié, et chaque application doit protéger elle-même une base de mots de passe.

SAML sépare deux responsabilités :

• authentifier l’utilisateur, ce que fait un seul service, le fournisseur d’identité ;
• accorder l’accès, ce que fait chaque application, sur la foi de ce que le fournisseur d’identité affirme.

Cette séparation fonctionne aussi entre organisations. Une entreprise peut donner à ses salariés l’accès à un service externe sans que ce service ne stocke le moindre mot de passe : il fait confiance aux assertions signées par l’entreprise. C’est ce qu’on appelle la fédération.

Les acteurs#

Chaque fournisseur est désigné par un identifiant d’entité (entityID), en général une URL, par exemple https://login.example.fr/tosiam pour l’IdP et https://app.example.fr pour le SP. Les deux parties ne s’échangent jamais directement de mot de passe : le navigateur de l’utilisateur transporte les messages de l’une à l’autre.

Les briques de la norme#

SAML 2.0 se compose de plusieurs spécifications qui s’emboîtent :

Les bindings les plus courants sont les suivants :

Comment se déroule une connexion#

Le parcours le plus répandu est la connexion initiée par le SP (SP-initiated) : l’utilisateur arrive sur l’application, qui l’envoie s’authentifier chez l’IdP.

Quelques éléments méritent qu’on s’y arrête :

• AuthnRequest est la demande d’authentification. Elle porte un identifiant unique (ID), l’entityID du SP et l’adresse à laquelle renvoyer la réponse.
• L’ACS (Assertion Consumer Service) est l’adresse du SP qui reçoit la réponse. Elle doit figurer dans les métadonnées du SP.
• InResponseTo recopie dans la réponse l’ID de la requête. Le SP vérifie qu’il correspond à une demande qu’il a réellement émise.
• RelayState est une valeur opaque que l’IdP renvoie telle quelle. Le SP s’en sert pour retrouver la page demandée au départ.

Le parcours inverse, initié par l’IdP (IdP-initiated), part d’un portail : l’utilisateur clique sur une application, et l’IdP envoie directement une réponse non sollicitée. Il est pratique, mais moins sûr, car le SP n’a aucune requête à laquelle rattacher la réponse.

L’assertion#

L’assertion est le cœur de SAML. C’est un document XML émis et signé par l’IdP, qui décrit l’utilisateur et les conditions dans lesquelles il s’est authentifié :

<saml:Assertion xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
    ID="_9f3c1e7a2b" Version="2.0" IssueInstant="2026-09-30T08:15:02Z">
  <saml:Issuer>https://login.example.fr/tosiam</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">k7Qe2vX9pL</saml:NameID>
    <saml:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
      <saml:SubjectConfirmationData InResponseTo="_4b8d0c21e6"
          Recipient="https://app.example.fr/saml/acs"
          NotOnOrAfter="2026-09-30T08:20:02Z"/>
    </saml:SubjectConfirmation>
  </saml:Subject>
  <saml:Conditions NotBefore="2026-09-30T08:14:32Z" NotOnOrAfter="2026-09-30T08:20:02Z">
    <saml:AudienceRestriction>
      <saml:Audience>https://app.example.fr</saml:Audience>
    </saml:AudienceRestriction>
  </saml:Conditions>
  <saml:AuthnStatement AuthnInstant="2026-09-30T08:15:00Z" SessionIndex="s2a1f0">
    <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="mail">
      <saml:AttributeValue>claire.martin@example.fr</saml:AttributeValue>
    </saml:Attribute>
  </saml:AttributeStatement>
</saml:Assertion>

Le format du NameID détermine la nature de l’identifiant :

Une assertion de type bearer, comme ci-dessus, vaut pour quiconque la présente. C’est pourquoi sa durée de vie est courte (quelques minutes) et pourquoi le SP ne doit l’accepter qu’une seule fois.

Les métadonnées#

Avant tout échange, l’IdP et le SP doivent se connaître. Ils le font en s’échangeant leurs métadonnées, un document XML qui décrit chaque fournisseur :

<md:EntityDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata"
    entityID="https://app.example.fr">
  <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" isDefault="true"
        Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
        Location="https://app.example.fr/saml/acs"/>
  </md:SPSSODescriptor>
</md:EntityDescriptor>

Les métadonnées portent les certificats qui servent à vérifier les signatures et à chiffrer les assertions. C’est donc sur elles que repose toute la confiance : un certificat reçu dans un message n’a de valeur que s’il correspond à celui des métadonnées.

Déconnexion unique#

SAML définit aussi la déconnexion unique (Single Logout, SLO). Quand l’utilisateur se déconnecte d’une application ou de l’IdP, l’IdP envoie une LogoutRequest à chaque SP auquel il a délivré une assertion pendant la session, en s’appuyant sur le SessionIndex. Le mécanisme dépend de la coopération de chaque SP : une application qui ne répond pas garde sa session ouverte.

SAML, OpenID Connect et OAuth 2.0#

Les deux protocoles d’authentification coexistent souvent dans une même organisation : SAML pour les applications d’entreprise qui ne parlent que lui, OpenID Connect pour les nouveaux développements. Un fournisseur d’identité qui parle les deux permet de ne gérer qu’un seul parcours de connexion.

Bonnes pratiques#

• Vérifiez la signature avec le certificat issu des métadonnées du partenaire, jamais avec un certificat embarqué dans le message.
• Utilisez une bibliothèque SAML éprouvée et ne lisez que les éléments couverts par la signature. Les attaques par encapsulation de signature (XML Signature Wrapping) glissent une seconde assertion non signée à côté de la vraie ; refusez toute réponse qui contient plus d’une assertion.
• Contrôlez l’audience, le Recipient, les dates (NotBefore, NotOnOrAfter, avec une tolérance d’horloge de quelques minutes au plus) et l’InResponseTo. Gardez la trace des identifiants d’assertion reçus pour refuser un rejeu.
• Désactivez les DTD et les entités externes dans l’analyseur XML, pour vous protéger des attaques XXE.
• Signez avec RSA-SHA256 au minimum ; SHA-1 n’est plus acceptable.
• Chiffrez les assertions (EncryptedAssertion) lorsqu’elles transportent des attributs sensibles.
• Préférez le parcours initié par le SP et, pour le RelayState, ne redirigez que vers des adresses connues de l’application.
• Surveillez l’expiration des certificats : publiez le nouveau certificat dans les métadonnées avant de l’utiliser, pour que les partenaires aient le temps de le prendre en compte.

SAML 2.0 dans TOSIAM#

TOSIAM joue les deux rôles du protocole. Son moteur de fédération, hérité d’OpenAM, prend en charge les bindings HTTP-Redirect, HTTP-POST, HTTP-Artifact et SOAP, ainsi que la déconnexion unique.

Configuration. Dans la console, la section Fédérations gère, par royaume, les fournisseurs SAML 2.0 et les cercles de confiance qui les relient. Un fournisseur est soit hébergé (TOSIAM lui-même, dans le rôle d’IdP ou de SP), soit distant (un partenaire, déclaré en important ses métadonnées). Les métadonnées d’une entité hébergée s’exportent depuis la console, ou à l’adresse /saml2/jsp/exportmetadata.jsp avec les paramètres entityid et realm.

TOSIAM fournisseur d’identité. Les applications envoient leurs requêtes aux services SSO de TOSIAM, de la forme /SSORedirect/metaAlias/<alias> ou /SSOPOST/metaAlias/<alias> selon le binding. Un portail peut aussi déclencher un parcours initié par l’IdP par /idpssoinit. Si l’utilisateur a déjà une session TOSIAM, l’assertion est émise sans nouvelle authentification : c’est l’authentification unique entre toutes les applications fédérées. Une table de correspondance, définie sur le fournisseur, indique quels attributs du profil sont transmis dans l’assertion.

TOSIAM fournisseur de services. Dans un graphe d’authentification, deux nœuds délèguent la connexion à un IdP externe, par exemple celui d’un partenaire :

• SamlRedirectNode construit l’AuthnRequest et redirige l’utilisateur vers l’IdP (binding HTTP-Redirect). L’identifiant de la requête sert aussi de RelayState.
• L’IdP renvoie sa réponse en HTTP-POST à l’ACS /graph/Consumer/metaAlias/<royaume>/<alias>. TOSIAM y vérifie que l’InResponseTo correspond à la requête émise et que l’émetteur est bien l’IdP attendu, puis contrôle la signature, l’audience, les dates et le rejeu avec son moteur de fédération.
• SamlCallbackNode place ensuite le NameID et les attributs reçus dans l’état partagé du graphe. Sa sortie mfaRequired permet d’exiger un second facteur quand l’IdP indique, par un attribut ou par l’AuthnContextClassRef, que l’authentification reçue ne suffit pas.

D’une assertion à un jeton OAuth 2.0. TOSIAM accepte aussi le grant type urn:ietf:params:oauth:grant-type:saml2-bearer (RFC 7522) : une application échange une assertion SAML contre un access token. L’assertion doit être signée par un IdP déclaré dans le royaume, et son audience doit désigner un SP du royaume qui partage un cercle de confiance avec cet IdP.

Pour aller plus loin#

• SAML 2.0 Technical Overview, la présentation d’ensemble publiée par OASIS
• Assertions and Protocols for SAML 2.0, la spécification principale
• Bindings for SAML 2.0 et Profiles for SAML 2.0
• Metadata for SAML 2.0
• Security and Privacy Considerations for SAML 2.0