SAML 2.0 et SSO : assertions, bindings et fédération d'identité

Bien avant que les navigateurs ne dialoguent en JSON avec des fournisseurs d'identité, les entreprises avaient besoin qu'une seule connexion ouvre une dizaine d'applications, dont certaines tournaient dans une tout autre organisation. SAML 2.0, normalisé par OASIS en 2005, a répondu à ce besoin avec un vocabulaire XML permettant de formuler et de transporter des déclarations sur un utilisateur authentifié, et il soutient discrètement depuis lors les fédérations universitaires, les portails administratifs et les parcs applicatifs d'entreprise. Si vous vendez du logiciel à de grandes organisations, un client finira tôt ou tard par vous envoyer un fichier de métadonnées plutôt qu'un client secret.

Travailler avec SAML diffère de travailler avec OpenID Connect bien au-delà du format de sérialisation. La confiance s'établit hors bande par un échange de certificats, et non en récupérant un document de discovery ; la sécurité de tout l'échange repose sur les signatures numériques XML, une spécification réputée pour ses pièges ; et il n'existe aucune notion d'access token pour appeler des API. Ce guide couvre ce qu'il faut savoir pour s'intégrer correctement et ce qui, historiquement, a mal tourné.

La fédération et ses deux rôles

L'authentification unique (SSO) signifie qu'un utilisateur s'authentifie une fois et que les applications suivantes acceptent cette authentification au lieu de la redemander. La fédération étend ce principe au-delà des frontières d'une organisation : l'application fait confiance à une assertion émise par un fournisseur d'identité qu'elle ne contrôle pas, sur la foi d'un certificat échangé à l'avance.

• Le fournisseur d'identité (IdP) authentifie l'utilisateur et émet les assertions. Il y en a généralement un par organisation.
• Le fournisseur de service (SP) est l'application qui consomme l'assertion. Il ne voit jamais les identifiants de l'utilisateur.
• L'assertion est le document XML signé qui porte les déclarations.
• Le cercle de confiance est l'ensemble des parties qui ont échangé leurs métadonnées et accepté de reconnaître mutuellement leurs déclarations.

Conséquence concrète : les identifiants restent dans l'annuaire de l'employeur. Quand une personne quitte l'organisation, on la désactive une seule fois, de manière centralisée, et toutes les applications fédérées cessent de l'admettre — l'argument du cycle de vie des identités développé dans le guide gestion des identités et des accès.

Anatomie d'une assertion

Une assertion est un élément <saml:Assertion> comportant un émetteur, une signature, un sujet, des conditions de validité et une ou plusieurs déclarations. Débarrassée du bruit des espaces de noms, une assertion réaliste ressemble à ceci.

<saml:Assertion ID="_a1b2c3d4e5" IssueInstant="2026-09-07T09:14:22Z" Version="2.0"
                xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">
  <saml:Issuer>https://idp.university.example/idp/shibboleth</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">
      c7f1e0a9-2b44-4d7e-9f30-8a0e1c2b3d45
    </saml:NameID>
    <saml:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
      <saml:SubjectConfirmationData NotOnOrAfter="2026-09-07T09:19:22Z"
        Recipient="https://app.example.com/saml/acs"
        InResponseTo="_req-88f21a"/>
    </saml:SubjectConfirmation>
  </saml:Subject>
  <saml:Conditions NotBefore="2026-09-07T09:14:12Z" NotOnOrAfter="2026-09-07T09:24:22Z">
    <saml:AudienceRestriction>
      <saml:Audience>https://app.example.com/saml/metadata</saml:Audience>
    </saml:AudienceRestriction>
  </saml:Conditions>
  <saml:AuthnStatement AuthnInstant="2026-09-07T09:14:20Z" SessionIndex="_sess-4471">
    <saml:AuthnContext>
      <saml:AuthnContextClassRef>
        urn:oasis:names:tc:SAML:2.0:ac:classes:MobileTwoFactorContract
      </saml:AuthnContextClassRef>
    </saml:AuthnContext>
  </saml:AuthnStatement>
  <saml:AttributeStatement>
    <saml:Attribute Name="urn:oid:0.9.2342.19200300.100.1.3">
      <saml:AttributeValue>[email protected]</saml:AttributeValue>
    </saml:Attribute>
    <saml:Attribute Name="urn:oid:1.3.6.1.4.1.5923.1.1.1.1">
      <saml:AttributeValue>staff</saml:AttributeValue>
      <saml:AttributeValue>member</saml:AttributeValue>
    </saml:Attribute>
  </saml:AttributeStatement>
</saml:Assertion>

Chaque partie impose des obligations au consommateur. Le format du NameID détermine si vous recevez un identifiant réutilisable : persistent fournit un pseudonyme stable propre à cette relation avec le SP, transient une valeur valable pour une seule session, et emailAddress une valeur lisible mais susceptible de changer. Les conditions doivent être appliquées — c'est la restriction d'audience qui empêche de rejouer auprès d'une application une assertion émise pour une autre, et la fenêtre de validité doit être vérifiée avec une horloge synchronisée par NTP. L'AuthnContextClassRef est l'équivalent SAML d'une déclaration sur la force de l'authentification, et c'est par lui qu'un SP exige une authentification multifacteur. Les attributs sont couramment nommés par des identifiants d'objet LDAP, d'où les chaînes du type urn:oid:1.3.6.1.4.1.5923.1.1.1.1 qui parsèment les guides d'intégration.

Flux et bindings

Un binding décrit la manière dont un message SAML circule sur HTTP. Deux d'entre eux comptent vraiment.

HTTP-Redirect place dans un paramètre de requête un message compressé (deflate), encodé en base64 puis encodé pour l'URL, la signature figurant dans un paramètre distinct. Il convient aux petits messages comme une requête d'authentification, et il est limité par la longueur de l'URL.

HTTP-POST place le message encodé en base64 dans un champ de formulaire caché, qu'une petite page à soumission automatique envoie à l'autre partie. Les réponses porteuses d'assertions utilisent toujours ce binding, car elles sont bien trop volumineuses pour une URL.

Le SSO initié par le SP est le flux à privilégier. L'utilisateur demande une page protégée, le SP construit une AuthnRequest dotée d'un ID unique et redirige le navigateur vers l'IdP ; celui-ci authentifie l'utilisateur, puis envoie en POST une Response contenant l'assertion à l'Assertion Consumer Service du SP.

GET /idp/profile/SAML2/Redirect/SSO?SAMLRequest=fVLLTsMwEPwVy3fHTkI...
  &RelayState=%2Freports%2Fq3
  &SigAlg=http%3A%2F%2Fwww.w3.org%2F2001%2F04%2Fxmldsig-more%23rsa-sha256
  &Signature=Xk9c2Fq... HTTP/1.1
Host: idp.university.example

POST /saml/acs HTTP/1.1
Host: app.example.com
Content-Type: application/x-www-form-urlencoded

SAMLResponse=PHNhbWxwOlJlc3BvbnNlIHhtbG5zOnNhbWxwPSJ1cm46b2FzaXM6...&RelayState=%2Freports%2Fq3

RelayState transporte l'état propre au SP — le plus souvent la page que l'utilisateur voulait atteindre au départ — et doit être traité comme une entrée non fiable : validez-le comme un chemin relatif, faute de quoi vous aurez construit une redirection ouverte. Comme les charges utiles sont en base64, un décodeur base64 est le moyen le plus rapide de lire un message capturé lors du débogage d'une intégration, même si le code de production doit toujours travailler sur le document analysé et vérifié.

Le SSO initié par l'IdP part d'un lien sur un portail : l'IdP poste une assertion non sollicitée, sans InResponseTo. C'est pratique, mais moins sûr, puisque le SP n'a aucune requête de sa part à laquelle rattacher la réponse. Ne le prenez en charge que si un client l'exige, et compensez par des durées de vie courtes et un suivi strict de l'usage unique des identifiants d'assertion.

Métadonnées et certificats

Les métadonnées sont la description lisible par machine d'une partie : son identifiant d'entité, ses endpoints, les formats de NameID qu'elle prend en charge et, surtout, ses certificats.

<md:EntityDescriptor entityID="https://app.example.com/saml/metadata"
                     xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata">
  <md:SPSSODescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol"
                      AuthnRequestsSigned="true" WantAssertionsSigned="true">
    <md:KeyDescriptor use="signing">
      <ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
        <ds:X509Data><ds:X509Certificate>MIIDdzCCAl+gAwIBAgIE...</ds:X509Certificate></ds:X509Data>
      </ds:KeyInfo>
    </md:KeyDescriptor>
    <md:AssertionConsumerService index="0"
      Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
      Location="https://app.example.com/saml/acs"/>
    <md:SingleLogoutService
      Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect"
      Location="https://app.example.com/saml/slo"/>
  </md:SPSSODescriptor>
</md:EntityDescriptor>

Deux habitudes opérationnelles évitent la plupart des pannes SAML. Servez vos métadonnées à une URL HTTPS stable et consommez celles du partenaire de la même façon, à intervalles réguliers, plutôt que d'échanger des fichiers par e-mail. Et renouvelez les certificats avec un recouvrement : publiez le nouveau à côté de l'ancien, attendez que chaque partenaire ait rafraîchi ses métadonnées, basculez la clé de signature, puis retirez l'ancien certificat. Un certificat qui expire à minuit sans recouvrement, c'est l'incident de fédération classique du lundi matin.

Valider la signature, avec rigueur

La sécurité de SAML repose entièrement sur les signatures numériques XML, et celles-ci sont plus délicates qu'il n'y paraît, car la signature désigne une portion du document par son identifiant au lieu de couvrir l'ensemble des octets. Cette indirection a donné naissance à la famille des attaques par signature wrapping : l'attaquant prend une assertion légitimement signée, l'enveloppe ou la déplace dans le document, puis insère une assertion forgée que le parseur de l'application va justement lire. La signature reste valide — sur l'élément d'origine, désormais masqué — tandis que l'application agit sur la version de l'attaquant.

Les parades sont précises :

• Vérifiez d'abord, lisez ensuite. Validez la signature, puis extrayez le sujet et les attributs de l'élément exact qui a été signé, jamais d'une nouvelle requête XPath sur l'ensemble du document.
• Utilisez une bibliothèque SAML maintenue, pas une boîte à outils XML généraliste. La gestion correcte des références, de la canonicalisation et de l'identité de l'élément signé ne se réimplémente pas.
• Décidez à l'avance de ce qui doit être signé — la réponse, l'assertion ou les deux — et rejetez tout ce qui ne respecte pas cette politique. Une assertion non signée à l'intérieur d'une réponse signée n'est pas sûre pour autant.
• Épinglez le certificat issu des métadonnées. Ne faites jamais confiance à un certificat embarqué dans le message entrant lui-même, et vérifiez que l'identifiant d'entité de l'émetteur correspond à la clé attendue.
• Désactivez la résolution des entités externes et les DTD dans le parseur. Le traitement des entités externes XML transforme un endpoint de connexion en primitive de lecture de fichiers ; le guide sur le traitement XML détaille les réglages de parseur concernés.
• Appliquez l'ensemble des conditions : audience, NotBefore, NotOnOrAfter, Recipient, InResponseTo et usage unique de l'identifiant d'assertion.
• Exigez SHA-256 ou plus fort. Rejetez les algorithmes de signature SHA-1 et les clés RSA de moins de 2048 bits.

Single logout et mapping des attributs

Le single logout propage une déconnexion d'une application à l'ensemble du cercle de confiance : la partie qui l'initie envoie une LogoutRequest indiquant le SessionIndex, et l'IdP la relaie à chacun des autres SP. En pratique, le mécanisme est fragile — il suffit d'un SP injoignable ou d'un navigateur qui bloque une chaîne de redirections pour que la séquence s'arrête à mi-chemin. Beaucoup de déploiements se contentent donc d'une déconnexion locale, redirigent vers l'IdP pour clore la session centrale et acceptent que les autres applications expirent d'elles-mêmes. Si une déconnexion globale fiable est une exigence, traitez-la comme une contrainte de conception dès le départ, et non comme une case à cocher.

Le mapping des attributs est la partie ingrate de toute intégration. L'IdP transmet ce que la politique de l'organisation autorise, sous des noms que vous ne choisissez pas, et votre application doit les traduire en ses propres rôles. Deux règles épargnent bien des soucis : ne faites jamais d'un nom de groupe de l'annuaire du client une autorité codée en dur dans votre code — passez par la configuration — et traitez les valeurs d'attributs comme des chaînes non fiables, qui méritent la même validation et le même encodage en sortie que n'importe quelle autre entrée.

SAML ou OpenID Connect ?

Pour une nouvelle intégration où vous avez le choix, prenez OpenID Connect : la cryptographie est plus facile à maîtriser, la même infrastructure sécurise vos API via OAuth 2.0, et les clients mobiles sont pris en charge nativement. Choisissez SAML quand votre interlocuteur ne parle que SAML, ce qui, en entreprise et dans le monde académique, résume souvent toute la question. Beaucoup de produits prennent en charge les deux, et un fournisseur d'identité moderne jouera volontiers le rôle d'IdP SAML pour une application et d'OpenID Provider pour la suivante.

Points clés à retenir

• SAML fédère l'authentification : un fournisseur de service fait confiance à une assertion XML signée émise par un fournisseur d'identité, la confiance reposant sur l'échange de métadonnées.
• Les conditions d'une assertion — audience, fenêtre de validité, destinataire et InResponseTo — sont des contrôles de sécurité que le consommateur doit appliquer, pas de la documentation.
• Les flux initiés par le SP, avec le binding HTTP-POST pour les réponses, sont le choix sûr par défaut ; les assertions non sollicitées initiées par l'IdP perdent la protection contre le rejeu.
• Des métadonnées servies en HTTPS et rafraîchies à intervalles réguliers, avec des certificats qui se recouvrent, font de la rotation des clés un changement de routine.
• Validez la signature avec une vraie bibliothèque SAML, ne lisez que l'élément signé, épinglez les certificats issus des métadonnées et désactivez les entités externes.
• Préférez OpenID Connect pour les nouveaux projets ; prenez en charge SAML quand votre interlocuteur l'exige, et attendez-vous à ce que le single logout demande une conception réfléchie.