Le SAML (Security Assertion Markup Language) est le protocole d’authentification le plus répandu et la solution SSO (Single Sign-On) utilisée dans les entreprises.
Qu’est-ce que le SSO ?
En termes simples, le SSO est l’équivalent en entreprise des boutons « Se connecter avec Google » ou « Se connecter avec Facebook » que l’on trouve sur de nombreuses applications en ligne. L’utilisateur crée d’abord un compte sur Google ou Facebook, puis utilise ce compte pour se connecter à d’autres applications comme Spotify, Netflix ou Zoom. Cela permet d’éviter de gérer plusieurs identifiants et mots de passe. De la même manière, les entreprises utilisent un système de gestion des utilisateurs unique, permettant à leurs employés de se connecter à des services tiers tels que Salesforce, Workday ou Expensify sans avoir à créer des comptes séparés ou à mémoriser plusieurs mots de passe. Ce processus est connu sous le nom de SSO, et le SAML est la solution SSO de facto pour les entreprises.
Acteurs
Trois acteurs principaux interviennent dans le flux d’authentification SAML :
Fournisseur d’identité (IdP)
C’est le système centralisé de gestion des utilisateurs mentionné précédemment. Ce serveur est chargé d’authentifier l’utilisateur et de transmettre des informations telles que l’adresse e-mail, le nom, le département, etc., au fournisseur de services. Parmi les fournisseurs d’identité populaires, on trouve Azure AD, Auth0, Onelogin, Okta et G Suite.
Fournisseur de services (SP)
Il s’agit de l’application qui fait confiance à l’IdP et souhaite l’utiliser pour l’authentification. Exemples : Salesforce, Workday, Expensify, votre application préférée, etc.
Utilisateur
C’est la personne qui tente de se connecter au SP via l’IdP.
Flux d’authentification
Il existe deux méthodes courantes pour qu’un utilisateur accède au SP :
Connexion initiée par l’IdP :
L’utilisateur se rend d’abord sur l’IdP et voit une liste des SP auxquels il a accès. En choisissant un SP dans cette liste, il est redirigé vers ce dernier.
Connexion initiée par le SP :
Dans ce flux, l’utilisateur commence par visiter le site du SP. Si l’utilisateur n’a pas de session active avec le SP, il est redirigé vers l’IdP pour s’authentifier. Après une connexion réussie, l’utilisateur est renvoyé vers le SP. Nous allons examiner ce flux en détail.
Flux initié par le SP :
Examinons le processus du point de vue de l’utilisateur.
- L’utilisateur accède au site du SP. S’il n’est pas connecté, un bouton « Se connecter avec SSO » s’affiche.
- En cliquant sur le bouton de connexion, l’utilisateur est redirigé vers le site de l’IdP où il doit soumettre ses identifiants.
- Après une connexion réussie, l’utilisateur est redirigé vers le site du SP où il peut effectuer son travail.
Analysons maintenant ce qui se passe en coulisses :
- Le SP vérifie la présence d’une session active.
- Le SP envoie une AuthnRequest à l’IdP.
- L’IdP authentifie l’utilisateur.
- L’IdP envoie une assertion SAML au SP.
- Le SP crée une session et connecte l’utilisateur.
Vérification de la session active par le SP
Le SAML ne gère pas les sessions, donc le SP doit maintenir des sessions pour chaque utilisateur authentifié. Lorsque l’utilisateur visite le site du SP, celui-ci vérifie si l’utilisateur a une session active. Si une session active existe, l’utilisateur peut accéder au site, sinon un bouton « Se connecter avec SSO » est affiché.
Envoi de l’AuthRequest par le SP
Lorsque l’utilisateur clique sur le bouton « Se connecter avec SSO », le SP génère un message XML appelé « AuthnRequest » contenant des informations sur l’expéditeur (Issuer), l’URL de redirection après l’authentification (Assertion Consumer Service url) et des mesures de sécurité (ID, IssueInstant). Voici un exemple de XML AuthnRequest.
Ce XML est encodé en une chaîne sécurisée pour l’URL, intégrée comme paramètre de requête dans une demande à l’IdP, et l’utilisateur est redirigé vers cette URL de l’IdP :
https://idp.com/SAML2/SSO/Redirect?SAMLRequest=EncodedAuthnRequest
Authentification de l’utilisateur par l’IdP
L’IdP maintient sa propre session pour l’utilisateur et, si une session active existe, l’utilisateur est redirigé vers le SP. Si aucune session n’existe, l’utilisateur est invité à entrer ses identifiants. L’IdP peut choisir la méthode d’authentification – cela peut être un nom d’utilisateur/mot de passe, TOTP, MFA, etc.
Envoi de l’assertion SAML par l’IdP
Une fois l’utilisateur authentifié avec succès, l’IdP renvoie un message XML appelé « SAML Assertion » à l’URL de service de consommation d’assertion du SP. Ce message contient les détails de l’utilisateur tels que le nom, l’e-mail, le département, etc., ainsi que des mesures de sécurité (InResponseTo, IssueInstant). Il est également signé numériquement, permettant au SP de vérifier que le message provient bien de l’IdP et d’authentifier l’utilisateur dans son système.
Création de la session et connexion de l’utilisateur par le SP
L’utilisateur est maintenant connecté avec succès au site du SP ! Le SP crée une session pour l’utilisateur afin qu’il puisse être automatiquement connecté lors de sa prochaine visite sur le site.
Conclusion
Nous espérons que cet article vous a permis d’obtenir une vue d’ensemble du fonctionnement de l’authentification SAML et du SSO.
Merci de votre lecture ! :)
