Security Assertion Markup Language (SAML) 2.0 est un protocole basé sur XML qui permet la fédération des identités entre des domaines de sécurité distincts afin d’assurer l’authentification unique (SSO). SAML permet aux utilisateurs de s’authentifier une fois auprès d’un fournisseur d’identité (IdP) et d’accéder ensuite à plusieurs fournisseurs de services sans avoir à saisir à nouveau leurs identifiants.

SAML 2.0 a été ratifié en tant que standard ouvert OASIS en 2005. Il reste largement utilisé pour la fédération des identités des grandes entreprises et des organismes publics, bien que OpenID Connect (OIDC) soit devenu de plus en plus courant pour les applications modernes.

Exemple : lorsque vous vous connectez au hub interne de votre entreprise, SAML vous permet d’accéder immédiatement aux référentiels GitHub Enterprise, aux tickets Jira et à la documentation Confluence tout au long de la journée sans avoir à fournir à nouveau vos identifiants pour chaque outil. Le portail agit comme un fournisseur de services ou un lanceur d’applications hébergé par un IdP, et les outils en aval (Jira, GitHub Enterprise) sont des fournisseurs de services supplémentaires qui font confiance au même IdP.

SAML prend en charge deux modèles d’initiation, qui aboutissent tous deux à un SSO.

Flux initié par fournisseur de services (standard pour le SaaS B2B)

Lorsqu’un utilisateur tente d’accéder directement à l’application :

1. L’utilisateur tente d’accéder à l’application (fournisseur de services).
2. L’application redirige l’utilisateur vers la page de connexion de l’IdP.
3. L’utilisateur s’authentifie auprès de l’IdP.
4. L’IdP génère une assertion SAML signée.
5. L’IdP redirige l’utilisateur vers l’application avec l’assertion.
6. L’application valide la signature de l’assertion et crée une session.
7. L’utilisateur accède à votre application.

Flux initié par l’IdP (courant dans les environnements d’entreprise)

Lorsqu’un utilisateur démarre à partir du tableau de bord de son entreprise :

1. L’utilisateur se connecte au portail de son entreprise (IdP).
2. L’utilisateur clique sur l’application dans son tableau de bord.
3. L’IdP génère une assertion SAML signée.
4. L’IdP redirige automatiquement l’utilisateur vers l’application (fournisseur de services) avec l’assertion.
5. L’application valide l’assertion et crée une session.
6. L’utilisateur accède à l’application.

Les deux flux vérifient l’identité sans qu’il soit nécessaire de partager les mots de passe entre les systèmes. L’IdP peut exiger une authentification MFA avant d’émettre l’assertion, ce qui ajoute une couche de sécurité supplémentaire.

Le SSO initié par l’IdP n’inclut pas de valeur InResponseTo de la part du fournisseur de services. Les fournisseurs de services s’appuient davantage sur les horodatages des assertions (NotBefore/NotOnOrAfter) et sur la protection contre la relecture lorsqu’ils valident les assertions initiées par l’IdP.

SAML permet la fédération des identités grâce à trois composants principaux :

• IdP : système qui authentifie les utilisateurs et stocke les identifiants.
• Fournisseur de services : application s’appuyant sur l’IdP pour l’authentification et l’octroi d’accès.
• Assertion SAML : document XML signé numériquement contenant des données d’identité vérifiées, transmises par l’IdP au fournisseur de services.

L’assertion confirme l’identité de l’utilisateur et l’accès qu’il est autorisé à avoir, ce qui permet au fournisseur de services d’accorder ou de refuser l’accès sans avoir à manipuler directement les identifiants de l’utilisateur.

Une assertion SAML est un document XML structuré avec trois types de déclarations :

• Déclarations d’authentification : confirment que l’utilisateur est authentifié et enregistrent l’heure à laquelle l’événement s’est produit.
• Déclarations d’attributs : contiennent les données et les revendications des utilisateurs (e‑mail, nom, groupes, rôles). La plupart des déploiements transmettent des données d’autorisation (telles que des rôles ou des groupes) par le biais de déclarations d’attributs. Dans les déploiements SAML pour collaborateurs, les déclarations d’attributs comprennent généralement des données liées à l’autorisation, telles que des groupes ou des rôles.
• Déclarations de décision d’autorisation : définies dans la spécification SAML, mais rarement utilisées dans les implémentations SSO actuelles.

L’assertion comprend :

• Émetteur : l’IdP qui l’a créé
• Sujet : l’utilisateur
• Conditions : fenêtre temporelle de validité (par exemple NotBefore et NotOnOrAfter) et audience prévue.
• Signature : preuve cryptographique d’authenticité. Le fournisseur de services doit vérifier que l’élément traité est le même élément référencé par l’ID de la signature afin d’éviter les attaques par enveloppement de signature XML.

L’assertion peut être cryptée, généralement l’élément <Assertion> plutôt que l’ensemble <Response>, bien que des attributs individuels puissent également être cryptés pour les données sensibles. Le fournisseur de services doit être en mesure de décrypter les éléments cryptés si nécessaire.

Les développeurs confondent souvent SAML avec OAuth 2.0 et OIDC. Voici une comparaison utile à cet égard :

Aspect	SAML 2.0	OAuth 2.0	OpenID Connect
Utilisation principale	Authentication SSO en entreprise	Autorisation déléguée	Authentification moderne
Format	XML (analyse complexe ; risque d’attaques par enveloppement de signature XML)	Le format des tokens n’est pas pris en compte dans la spécification, bien que de nombreuses implémentations utilisent des tokens d’accès JWT.	Basé sur JSON (token d’identification JWT)
Type de token	Assertion SAML	Jeton d'accès	Token d’identification et token d’accès
Transport	Les demandes d’authentification utilisent généralement HTTP-Redirect ; les assertions sont presque toujours transmises via HTTP-POST.	Généralement via header d’autorisation HTTP (tokens au porteur), bien que d’autres transports (form_post/query) existent en fonction du flux.	Header d’autorisation HTTP
Support mobile	Prise en charge médiocre pour les applications natives (nécessite souvent WebView ou une application de courtage)	Excellent	Excellent
Profils cibles	Entreprises, organismes publics	Applications grand public, API	Applications grand public, entreprises modernes
Cas d’usage	SSO d’entreprise, authentification des collaborateurs	Délégation d’accès API, intégrations tierces	Applications modernes, authentification mobile, SSO grand public

OAuth 2.0 gère l’autorisation (ce que vous pouvez faire), pas l’authentification (qui vous êtes). OAuth 2.0 n’est pas à lui seul un protocole d’authentification. Les fournisseurs utilisent souvent des méthodes propriétaires pour superposer des informations d’identité, mais ces méthodes ne sont pas standardisées. OpenID Connect est le standard qui permet d’ajouter l’authentification à OAuth 2.0.

SAML gère l’authentification et peut inclure des attributs d’autorisation, mais il ne s’agit pas d’un framework d’autorisation. Les décisions d’autorisation sont prises dans votre application une fois l’authentification SAML terminée.

Les protocoles ne s’excluent pas mutuellement. De nombreuses plateformes d’identité prennent en charge les trois, ce qui vous permet de choisir en fonction des besoins de vos utilisateurs.

Validation de la signature XML

SAML s’appuie sur des signatures XML pour la sécurité. L’implémentation correcte de la validation est complexe :

• Valider l’algorithme de signature (rejeter les algorithmes faibles comme SHA-1).
• Vérifier la chaîne de certificats de signature.
• Vérifier l’état d’expiration et de révocation des certificats.
• S’assurer que l’élément signé correspond au contenu analysé.
• Les fournisseurs de services doivent valider au moins une signature de confiance (sur <Response> ou <Assertion>, en fonction de la configuration) et s’assurer que seul l’élément attendu est traité.
• Les fournisseurs de services doivent s’assurer que la signature couvre la référence correcte afin d’éviter l’enveloppement XML. Certaines bibliothèques peuvent ne pas imposer la couverture des références. Vérifiez que la signature fait référence à l’identifiant correct de l’élément.

Une seule erreur dans la validation de la signature crée des vulnérabilités de sécurité. Les attaquants peuvent exploiter l’enveloppement de signature XML pour contourner l’authentification.

Envisagez d’utiliser une bibliothèque SAML testée plutôt que d’en créer une à partir de zéro.

Validation du décalage de l’horloge et de l’horodatage

Les assertions SAML comprennent des conditions (NotBefore) et (NotOnOrAfter). Les différences d’horloge entre l’IdP et le fournisseur de services peuvent entraîner le rejet d’assertions valides.

Bonnes pratiques :

• Autoriser une tolérance de 2 à 5 minutes pour le décalage temporel.
• Implémenter une configuration NTP adéquate sur vos serveurs.
• Enregistrer séparément les échecs de validation de l’horodatage pour le débogage.

Échange de métadonnées

SAML utilise généralement l’échange de métadonnées entre l’IdP et le fournisseur de services, bien que cela ne soit pas strictement requis par la spécification :

• Métadonnées de l’IdP : contiennent les certificats de signature, les endpoints et l’identifiant de l’entité.
• Métadonnées du fournisseur de services : décrivent les critères et les URL Assertion Consumer Service (ACS) de votre application.

Les changements de métadonnées interrompent le SSO. Lorsque les IdP changent de certificat, vous devez mettre à jour la configuration. Certaines entreprises exigent une approbation manuelle pour les changements de métadonnées du fournisseur de services, ce qui peut retarder les déploiements.

Stockez les métadonnées IdP dans votre base de données, et non dans les fichiers de configuration. Tous les IdP ne prennent pas en charge les URL de métadonnées dynamiques. Lorsqu’elle est disponible, l’actualisation automatique est la bonne pratique.

Incohérences de mappage d’attributs

Différents IdP envoient des noms d’attributs différents. L’application a besoin d’un mappage d’attributs flexible pour gérer ces variations. Permettez aux clients de configurer les attributs SAML qui correspondent aux champs utilisateurs de votre application.

Lors de l’utilisation du contrôle d’accès basé sur les rôles (RBAC), les IdP peuvent envoyer des informations sur les rôles dans les attributs SAML. L’application doit associer ces rôles IdP avec le système de permission interne.

Toujours valider la signature

Chaque assertion SAML doit être validée cryptographiquement de façon à confirmer les éléments suivants :

1. La signature existe.
2. La signature est valide pour le contenu de l’assertion.
3. Le certificat de signature est lié à une racine de confiance.
4. L’élément signé correspond au contenu analysé. Les fournisseurs de services doivent s’assurer que la signature couvre la référence correcte afin d’éviter l’enveloppement XML.

N’omettez jamais la validation des signatures, même en cours de développement. C’est la base de la sécurité SAML.

Valider toutes les conditions d’assertion

Au-delà des signatures, validez les éléments suivants :

• Émetteur : correspond à l’IdP configuré.
• Audience : contient l’identifiant de l’entité de l’application.
• NotBefore/NotOnOrAfter : l’heure actuelle se situe dans la fenêtre valide.
• Destinataire : correspond à l’URL Assertion Consumer Service (le cas échéant).
• InResponseTo : correspond à l’ID de votre demande d’authentification (pour les flux initiés par le fournisseur de services).

Prévenir les attaques par relecture et l’enveloppement de signature

La spécification SAML n’impose pas l’utilisation unique d’assertions, ce qui fait que la protection contre la relecture relève de la responsabilité du fournisseur de services.

1. Stockez l’ID de l’assertion (pas l’ID de la réponse), utilisé comme un nonce pour empêcher la relecture, dans un cache dont le TTL correspond à la fenêtre de validité de l’assertion.
   Bonne pratique : réglez le TTL du cache au moins sur la fenêtre NotOnOrAfter de l’assertion, idéalement avec une petite marge (quelques secondes) pour tenir compte de la latence du réseau.
2. Rejetez toute assertion dont l’ID a déjà été vue.
3. Effacez régulièrement les identifiants expirés pour gérer la taille du cache.

En guise de première défense, le fournisseur de services doit valider les horodatages NotBefore et NotOnOrAfter. La mise en cache des identifiants d’assertions est secondaire.

Toujours utiliser HTTPS

Les assertions SAML ne doivent être transmises que par HTTPS. Même si elles sont signées, leur transmission par HTTP expose les utilisateurs à des attaques de type Man-in-the-Middle.

Configurez l’URL Assertion Consumer Service (ACS) avec HTTPS uniquement. La plupart des IdP avertissent ou bloquent les endpoints HTTP.

Implémenter correctement la déconnexion

SAML prend en charge la déconnexion unique (SLO), ce qui permet aux utilisateurs de se déconnecter simultanément de toutes les applications connectées. L’implémentation est facultative, mais elle est recommandée pour les applications sensibles sur le plan de la sécurité.

La déconnexion unique peut être de type frontal (redirection du navigateur) ou de type dorsal (de serveur à serveur). La déconnexion unique sur le canal frontal est largement prise en charge, mais instable. La déconnexion par canal dorsal existe, mais elle est complexe et rarement implémentée. L’interopérabilité varie dans la mesure où les IdP et les fournisseurs de services implémentent le SLO de manière différente ; il est donc conseillé de tester plusieurs fournisseurs.

La mise en place d’une implémentation SAML sécurisée à partir de zéro nécessite une expertise approfondie en matière de sécurité XML et n’est généralement recommandée que pour les implémentations IdP ou les cas d’usage très spécialisés.

Envisagez les options possibles :

Plateformes d’identité

Certaines plateformes d’identité aident à gérer la complexité de SAML en proposant des éléments tels que :

• Implémentations SAML prédéfinies pour IdP et fournisseur de services
• Gestion automatique des métadonnées
• Gestion de la rotation des certificats
• Support pour plusieurs IdP par application
• Journaux d’audit détaillés

Cette approche fournit un support SAML aux entreprises clientes tout en utilisant des protocoles modernes (OIDC, OAuth 2.0) pour les applications grand public. Certaines plateformes traduisent les protocoles de manière transparente.

Bibliothèques SAML

Pour les équipes qui ont besoin de plus de contrôle, des bibliothèques SAML matures gèrent l’analyse XML, la validation des signatures et les détails du protocole de bas niveau :

• Node.js : passport-saml, samlify
• Python : python3-saml, pysaml2
• Java : Spring Security SAML, OpenSAML
• .NET : Sustainsys.Saml2, ITfoxtec.Identity.Saml2
• Ruby : ruby-saml
• PHP : SimpleSAMLphp

Même les bibliothèques SAML les plus abouties ne gèrent pas automatiquement les attaques par relecture ou les assertions cryptées. Les développeurs doivent mettre en place la mise en cache/les nonces et le décryptage si nécessaire et s’assurer que la référence de la signature est vérifiée.

Choisissez SAML dans les cas suivants :

• Entreprises clientes dotées d’une infrastructure SAML existante
• Création d’un SaaS B2B nécessitant un SSO d’entreprise
• Intégration avec les systèmes d’organismes publics
• Réponses aux appels d’offres exigeant la prise en charge de SAML

Choisissez OIDC ou OAuth 2.0 dans les cas suivants :

• Développement d’applications grand public
• Authentification des applications mobiles requise
• Implémentation de l’autorisation d’API
• Préférence donnée aux protocoles JSON plus simples
• Nouveau départ sans exigences héritées

De nombreuses applications prennent en charge plusieurs protocoles. Votre IdP doit supporter à la fois SAML pour les entreprises et OIDC pour tous les autres utilisateurs. Pour une meilleure expérience utilisateur, envisagez l’utilisation de méthodes d’authentification sans mot de passe, telles que WebAuthn et les passkeys.

Avant de lancer la prise en charge de SAML, procédez à des tests approfondis :

Test avec plusieurs IdP

Chaque fournisseur d’identité (IdP) implémente SAML de manière légèrement différente. Ne supposez pas que le comportement d’un IdP s’applique aux autres. Les noms des attributs, les formats des métadonnées et la gestion des certificats varient.

Cas limites de test

• Décalage d’horloge (ajustement de l’heure de votre serveur d’environ 5 minutes)
• Rotation des certificats (mise à jour des certificats IdP et vérification de l’absence de temps d’arrêt)
• Signatures invalides (falsification des assertions et confirmation du rejet)
• Assertions expirées (utilisation d’anciennes assertions de test)
• Attaques par relecture (nouvelle soumission d’assertions valides et confirmation du rejet)

Surveillance des défaillances de validation

Enregistrez tous les échecs de validation SAML avec l’ID de l’assertion, la raison, l’entité IdP et l’horodatage pour le débogage. Ces journaux sont essentiels pour résoudre les problèmes des clients. Les échecs de SAML sont souvent dus à des problèmes de configuration plutôt qu’à des bugs dans le code.

Quel problème SAML résout-il ?

SAML assure le SSO en permettant la fédération des identités pour les utilisateurs de l’entreprise. Son principal avantage est de simplifier la sécurité des applications en transférant la responsabilité du stockage et de la gestion des mots de passe des utilisateurs à un IdP dédié. Cela réduit la surface d’attaque de l’application, diminue les appels au service d’assistance pour réinitialiser les mots de passe et centralise l’application des politiques.

SAML relève-t-il de l’authentification ou de l’autorisation ?

SAML est avant tout un protocole d’authentification et de fédération, conçu pour vérifier l’identité de l’utilisateur. Il ne s’agit pas, en soi, d’un framework d’autorisation comme OAuth 2.0. SAML répond à la question « Qui est cet utilisateur ? » en transmettant une assertion signée (une déclaration d’identité) d’un IdP à un fournisseur de services. L’autorisation (déterminer ce que l’utilisateur peut faire) intervient une fois l’authentification SAML terminée, généralement via les attributs de l’utilisateur (par exemple le rôle ou le service) trouvés dans l’assertion SAML.

En quoi SAML diffère-t-il d’OAuth 2.0 et d’OpenID Connect ?

SAML est un standard plus ancien, basé sur XML, conçu pour la fédération des identités d’entreprise et le SSO pour les collaborateurs. OAuth 2.0 est un framework d’autorisation qui émet des tokens d’accès pour accorder un accès délégué et limité aux API. OIDC est une couche d’identités fonctionnant par-dessus OAuth 2.0 qui ajoute une authentification standardisée via des tokens d’identification (JWT), optimisée pour les applications web, mobiles et basées sur des API. Les trois permettent l’accès, mais SAML se concentre sur le SSO d’entreprise, tandis qu’OAuth et OIDC sont mieux adaptés à l’authentification des applications et à l’autorisation des API modernes.

SAML est-il toujours utilisé ?

Oui. SAML reste un protocole dominant pour le SSO d’entreprise, en particulier dans les grandes entreprises et les organismes publics disposant d’une infrastructure d’identités existante. Alors qu’OIDC a gagné en popularité pour les applications, l’adoption généralisée de SAML par les entreprises signifie qu’il continue d’être activement utilisé et pris en charge.

SAML est-il sûr ? Quels sont les risques de sécurité ?

SAML est sûr lorsqu’il est implémenté correctement. Le protocole utilise des signatures numériques XML et le chiffrement pour protéger les données d’identité. Les risques peuvent provenir d’une mauvaise validation des assertions. Les fournisseurs de services doivent vérifier les signatures XML, valider les conditions d’assertion (y compris l’émetteur, l’audience et les horodatages) et implémenter une protection contre la relecture.

Auth0 aide les développeurs à implémenter SAML rapidement et en toute sécurité, permettant un SSO d’entreprise sans créer ou maintenir une infrastructure SAML à partir de zéro.

Explorez notre série d’articles « Introduction à l’IAM » sur la gestion des identités et des accès.

En savoir plus

Le contenu de ce document revêt un caractère purement informatif. Il vous revient de vous adresser à des conseillers professionnels pour obtenir des conseils en matière de sécurité, confidentialité, conformité ou conduite des affaires, et de ne pas vous en remettre aux recommandations formulées dans le présent document.