Comprendre SAML

SAML en 3 minutes

SAML permet de se connecter à une application avec le compte de son organisation, sans que l'application ne voie jamais le mot de passe.

Voir aussi : la frise de l’histoire de SAML · celle d’OAuth et d’OpenID Connect

Une image pour comprendre

Imaginez un concert. L'application, c'est la salle : elle veut savoir qui entre, mais elle ne vérifie pas vos papiers elle-même. Le fournisseur d'identité, c'est le guichet d'accréditation de votre entreprise : lui connaît vraiment votre identité. À l'entrée, la salle vous renvoie au guichet, qui vous remet un badge scellé portant votre nom. La salle ne fait confiance qu'au sceau, qu'elle sait reconnaître.

Ce badge scellé, c'est l'assertion SAML. Le sceau, c'est la signature.

Les trois acteurs

Une connexion en cinq étapes

1. Vous ouvrez l'application. Elle voit que vous n'êtes pas connecté.
2. Elle vous renvoie vers votre fournisseur d'identité avec une demande : « identifie cette personne et renvoie-la-moi à telle adresse ».
3. Le fournisseur d'identité vous authentifie (mot de passe, validation sur téléphone…). Cette étape n'a lieu que chez lui.
4. Il vous renvoie vers l'application avec un message signé : l'assertion (qui vous êtes, pour quelle application, jusqu'à quand).
5. L'application vérifie la signature et les conditions, puis vous ouvre une session.

Ce que contient l'assertion

• Qui : l'identifiant de la personne (le NameID, souvent son e-mail).
• Pour qui : l'application destinataire (l'Audience) et l'adresse précise de réception (l'ACS).
• Jusqu'à quand : une durée de validité très courte, quelques minutes.
• Quoi d'autre : des informations sur la personne (nom, groupes…), appelées attributs.
• Le sceau : la signature, qui prouve que le message vient bien du fournisseur d'identité et n'a pas été modifié.

Pourquoi l'application fait confiance au message

Avant le premier test, l'application et le fournisseur d'identité s'échangent une sorte de carte d'identité technique : les métadonnées. On y trouve leurs noms (Entity ID), leurs adresses et surtout le certificat qui permet de reconnaître le sceau. C'est la partie « configuration », et c'est là que naissent presque tous les problèmes.

Ce qu'il faut configurer, de chaque côté

Côté fournisseur d'identité	Côté application
Le nom de l'application (Entity ID)	Le nom du fournisseur d'identité (Entity ID)
L'adresse où renvoyer la personne (URL ACS)	L'adresse où l'envoyer s'identifier (URL SSO)
Éventuellement le certificat de l'application	Le certificat du fournisseur d'identité

Une erreur d'un caractère (une barre finale, http au lieu de https) suffit à tout bloquer. ID-Kit vous dit exactement quelle valeur ne correspond pas.

Et ID-Kit dans tout ça ?

• Vous avez une application à tester ? ID-Kit joue le fournisseur d'identité.
• Vous avez un fournisseur d'identité à tester ? ID-Kit joue l'application.

Pour aller plus loin : le détail technique, ou les erreurs courantes.