Qu'est-ce que SAML (Security Assertion Markup Language) ?

Qu'est-ce que SAML ?

SAML (Security Assertion Markup Language) est un standard basé sur XML pour transmettre des informations d'authentification et des attributs d'un utilisateur d'un fournisseur d'identité (IdP) à un fournisseur de service (SP). SAML V2.0 est devenu un standard OASIS le 15 mars 2005. Il est très utilisé pour l'authentification unique (SSO) en entreprise : l'utilisateur se connecte une fois auprès de l'IdP, et l'IdP se porte garant de lui auprès de chaque application avec une assertion signée.

Les deux rôles

• Fournisseur d'identité (IdP) : authentifie l'utilisateur et émet les assertions. C'est le système qui détient les comptes et applique des règles comme la MFA. Il relève du sujet plus large de la gestion des identités et des accès.
• Fournisseur de service (SP) : l'application que l'utilisateur veut atteindre. Elle consomme l'assertion et décide d'accorder ou non l'accès.

Comment fonctionne le flux SAML (initié par le SP)

1. L'utilisateur ouvre le SP et choisit de se connecter par SSO.
2. Le SP redirige le navigateur vers l'IdP avec une demande d'authentification (AuthnRequest).
3. L'IdP authentifie l'utilisateur ou réutilise une session IdP existante.
4. L'IdP construit une réponse SAML contenant une assertion signée sur l'utilisateur.
5. Le navigateur remet la réponse au point de terminaison Assertion Consumer Service (ACS) du SP, normalement par HTTP POST.
6. Le SP valide la signature et les conditions, puis crée sa propre session locale.

Dans un flux initié par l'IdP, l'utilisateur commence chez l'IdP, par exemple depuis un tableau de bord d'applications, et l'IdP envoie une assertion sans AuthnRequest. Le aperçu technique d'OASIS décrit les deux. Les messages transitent par des bindings comme HTTP Redirect, HTTP POST et HTTP Artifact.

Ce que contient une assertion

Une assertion porte un sujet, des conditions et des déclarations. On y trouve en général :

• Émetteur et signature : qui l'a émise, et la preuve que rien n'a été modifié.
• Sujet : la personne concernée, souvent sous forme de NameID, par exemple une adresse e-mail ou un identifiant opaque.
• Conditions : une fenêtre de validité (NotBefore et NotOnOrAfter) et une AudienceRestriction qui désigne le fournisseur de service auquel l'assertion est destinée.
• Déclaration d'authentification : comment et quand l'utilisateur s'est authentifié.
• Déclaration d'attributs : des informations comme le nom, l'e-mail ou les groupes, que le SP peut utiliser pour autoriser.

Exemple

Une employée ouvre l'outil de gestion de projet de son entreprise. L'outil redirige vers l'IdP de l'entreprise, elle valide une notification push, et l'IdP renvoie une assertion avec son e-mail, l'outil de projet comme audience et une fenêtre de validité de quelques minutes. L'outil vérifie la signature avec le certificat de l'IdP qu'il a en mémoire, confirme que l'audience est bien lui, contrôle la fenêtre de temps, associe l'attribut de groupe à un rôle et la connecte.

Erreurs courantes avec SAML

• Décalage d'horloge. Si les horloges de l'IdP et du SP diffèrent plus que la tolérance, la vérification de la fenêtre de validité échoue. Gardez les deux synchronisées par NTP.
• Certificats de signature expirés. Quand le certificat de l'IdP expire ou est remplacé alors que le SP garde l'ancien, toutes les connexions SSO échouent d'un coup. Suivez les dates d'expiration.
• Audience ou ACS qui ne correspondent pas. L'entity ID et l'URL d'ACS configurés chez l'IdP doivent correspondre exactement à ce qu'attend le SP.
• Format du NameID. Si l'IdP envoie un identifiant dans un autre format que celui sur lequel le SP fait la correspondance, les utilisateurs sont introuvables ou dupliqués.
• Correspondance des groupes. Un nom ou une valeur d'attribut erroné laisse les utilisateurs sans leur rôle.
• Validation de signature faible ou absence de protection contre le rejeu. Utilisez une bibliothèque SAML maintenue, vérifiez la signature sur le bon élément et rejetez les assertions déjà utilisées. La spécification définit aussi une condition OneTimeUse.

SAML, OAuth 2.0 et OpenID Connect

• SAML 2.0 : messages XML, conçu pour le SSO par navigateur entre organisations et applications.
• OAuth 2.0 : un cadre d'autorisation qui permet à une application d'accéder à des ressources au nom d'un utilisateur. Ce n'est pas un protocole de connexion en soi. Les jetons comme le bearer token sont courants dans les appels d'API.
• OpenID Connect : une couche d'identité au-dessus d'OAuth 2.0, qui utilise JSON et des JWT.

SAML, API et tests

SAML est un protocole de redirection par navigateur : il protège la page de connexion, pas les appels d'API. Les API d'un produit protégé par SSO acceptent généralement un jeton, et c'est ce que l'on teste : voir sécurité des API et le guide des tests de charge avec OAuth2. Le monitoring d'API LoadFocus peut authentifier les API qu'il contrôle avec des bearer tokens OAuth. LoadFocus lui-même ne propose pas d'authentification unique SAML ni OIDC : on se connecte à LoadFocus par e-mail et mot de passe ou avec Google.

Questions fréquentes : SAML

Que signifie SAML ?

Security Assertion Markup Language. Une assertion est une déclaration sur un utilisateur que la partie émettrice affirme vraie, par exemple qui il est et comment il s'est connecté.

Quelle est la différence entre SAML et OAuth ?

SAML dit à une application qui est l'utilisateur. OAuth 2.0 permet à une application d'agir au nom d'un utilisateur. Ils résolvent des problèmes différents, et OpenID Connect ajoute l'identité par-dessus OAuth.

Pourquoi SAML utilise-t-il XML ?

SAML 2.0 a été finalisé en 2005, quand XML était le format habituel pour ce type d'échange. Les protocoles plus récents comme OpenID Connect utilisent JSON.

SAML est-il sûr ?

Le protocole est bien spécifié, mais la plupart des défaillances viennent de l'implémentation : vérifications de signature faibles, contrôles d'audience ou de temps manquants, absence de protection contre le rejeu. Utilisez une bibliothèque maintenue et n'analysez pas le XML vous-même.

Comment déboguer une connexion SAML qui échoue ?

Capturez la réponse SAML dans le navigateur, décodez la charge base64 et lisez l'émetteur, l'audience, la fenêtre de validité et le NameID. Comparez-les avec la configuration du SP et vérifiez les deux horloges. Les problèmes de signature, d'audience, d'horloge et de certificat expliquent la plupart des échecs.

LoadFocus prend-il en charge l'authentification unique SAML ?

Non. On se connecte à LoadFocus par e-mail et mot de passe ou avec Google. LoadFocus peut tester et surveiller des applications et des API protégées par SAML en utilisant le jeton que ces API acceptent.