Dans le monde de l’authentification et des SSO, SAML (Security Assertion Markup Language), est incontestablement la star. Convergence de plusieurs tentatives issues de différents acteurs du domaine (WS-*, Liberty Alliance…), SAML est devenu incontournable, non seulement pour traiter les problèmes de fédération d’identités, quand il s’agit de permettre à un usager d’un autre domaine de sécurité, de venir activer les ressources d’un autre domaine, il constitue maintenant une pierre de base pour le montage des SSO (Single Sign On) internes et apparaît à ce titre, dans la plupart des appels d’offres courants.

Normalisé par l’OASIS et universellement reconnu, SAML a été adopté par tous les éditeurs qui ont un rapport avec l’authentification, mais aussi par les entreprises qui développent des applications, grâce entre autres à l’importante bibliothèque d’API disponibles, quel que soit le langage.

La question de son positionnement par rapport aux autres standards ne se pose même plus, Kerberos étant une « usine à gaz » difficile à comprendre et à exploiter, MS-Federation étant trop marqué Microsoft, voire SCIM (Simple Cloud Identity Management), plus récent, destiné à l’authentification des usagers de services Cloud. Cette dernière étant une version légère, qui peut être « bindée » en XML, autrement dit, encapsulée dans une assertion XML, voire OAuth ou OpenID Connect (construit sur OAuth), très marqué sécurité.

SAML est un peu le « grand frère » de tout ce qui existe aujourd’hui. Il est fondé sur des échanges de fichiers XML, qui rythment les demandes et les contrôles effectués par les 3 interlocuteurs du système : le client qui demande une connexion, le fournisseur de services SP (Service Provider) qui propose cette ressource et le fournisseur d’identités IdP (Identity Provider).

C’est à une plongée dans l’univers des mécanismes SAML que nous convions notre lecteur.