Tout ce qu'il faut savoir sur SAML

Dans une démarche d’uniformisation de l'authentification, les entreprises demandent souvent aux SAAS d’être SSO-ready. Tel “Sam” Gamegie aidant Frodon Sacquet dans sa quête le SAML sera un allié de choix dans votre quête pour devenir SSO-ready. On vous en dit plus sur celui-ci dans notre article.

Qu'est-ce que le SAML ?

Le langage SAML (Security Assertion Markup Language) est utilisé pour la communication entre les fournisseurs d’identités et les fournisseurs de services. Apparu en 2005, celui-ci à été développé par l’Organization for the Advancement of Structured Information Standards (OASIS). Cette organisation travaille pour la standardisation de formats de fichiers ouverts. Basé sur le XML (EXtensible Markup Language), il est utilisé pour communiquer des données entre plusieurs parties. Le SAML est de plus en plus omniprésent mais certaines alternatives existent. Ceux-ci permettent la mise en place de SSO (Single Sign-On). Ils offrent une expérience d’authentification simplifiée et plus fluide.

Une communication entre les différents acteurs de l’Authentification

Le SAML est principalement utilisé par les entreprises et gouvernements pour la mise en place de SSO. En effet, il permet d’échanger des données d’authentification entre différents acteurs. Pour ce faire il crée une relation dite de confiance entre un fournisseur d’identité (en anglais : Identity Provider ou IDP) et un prestataire de services (en anglais : services provider ou SP). C’est cette relation de confiance qui va permettre l’utilisation du SAML et donc de sécuriser la communication des identités.

Le SAML un langage basé sur le XML

Le** XML (EXtensible Markup Language) est un langage de balisage tout comme l’HTML (Hypertext Markup Language). Mais contrairement à celui-ci le XML a été pensé et conçu pour stocker et transporter des données. L'objectif initial de XML est de faciliter l'échange automatisé de contenus entre les systèmes d’informations. De plus depuis 1998 et sa version 1.0 il est devenu une recommandation W3C (World Wide Web Consortium).**

Dans le cas du SAML les données d’identités sont donc transposé dans le format XML

XML Schema Definition (XSD)

Les XSD permettent de décrire la structure d’un document XML. En SAML les spécifications des protocoles et des assertions sont réalisées à l'aide d'un XSD. 

Un échange reposant sur le SOAP et le HTML

Le HTTP et le SOAP (Simple Object Access Protocol) sont les protocoles de communications utilisés principalement par le SAML. Les transit des données entre les différents parties (prestataires de services, fournisseurs d’identités et parti de confiance) utilisent donc ces deux protocoles.

Le SAML, plusieurs parties pour plusieurs communications

Dans le cas d’un SSO plusieurs communications sont nécessaires. Ces communications seront alors réalisées la plupart du temps via le SAML. En effet les données d'identités seront dans un premier temps converties dans le format XML. Puis ces données au format XML vont transiter entre les différents acteurs via les protocoles HTML ou SOAP. Leur combinaison forment le SAML.

Dans un premier temps l’utilisateur tente d'accéder à une ressource qui nécessite une authentification (Service Provider). Si l’utilisateur n’est pas authentifié, le prestataire de service le redirige vers le fournisseur d’identité (IdP) avec une requête SAML. Suite à quoi celui-ci est invité à s’identifier. Ses identifiants sont alors vérifiés auprès du service de confiance, qui enverra une réponse au fournisseur d’identité. Dans le cas où les informations fournies par l’utilisateur sont correctes, celui-ci est alors redirigé et authentifié par l’IdP  vers le service demandé.

SAML et OAuth des protocoles avec des similitudes

Quand on parle de SSO, SAML et OAuth sont les deux alternatives qui ressortent le plus. Néanmoins, ce n’est pas parce qu’ils sont utilisés dans le même but qu’ils sont identiques. 

En effet une différence majeure existe entre le SAML et OAuth. Celle-ci réside dans le fait que le SAML est avant tout utilisé pour de l’authentification tandis qu’OAuth est utilisé pour de l’autorisation.

Pour illustrer ce propos, prenons l’exemple d’un événement sportif, musical ou tout autre événement de grande ampleur. Pour pouvoir rentrer vous devez présenter votre carte d’identité. Celle-ci va servir à prouver que vous êtes bien la personne que vous prétendez être. Votre ticket quant à lui va servir à déterminer à quelle place vous devez vous placez (numéro de place, fosse, carré VIP…). 

Dans cet exemple nous avons donc une authentification, par le biais de votre carte d’identité (SAML). Cette authentification vous permet d’accéder à l’événement. Puis une autorisation d’accès à certains services par le biais de votre ticket (OAuth). Cette autorisation vous permet d’accéder à certains services si vos privilèges le permettent.

Un allié de taille pour les différents acteurs

Le SAML permet l’utilisation d’un SSO. Par l'intermédiaire de celui-ci on supprime alors tous les mots de passe des utilisateurs pour chaque service. On les remplace alors par un seul et unique mot de passe. 

Pour l’utilisateur l'expérience d’authentification est simplifiée. A partir d’un seul couple identifiant / mot de passe il accède à tous ses services en quelques clics. Le SAML apporte gain de temps et simplicité.

Pour l’Identity Provider cela représente une réduction des demandes de réinitialisation de mot de passe conséquente. De plus, la gestion des identifications est centralisée en un seul et même point ce qui garantit une sécurité renforcée. Enfin cela réduit la complexité liée à la multiplication des SaaS (Software as a Service) dans les entreprises. Les utilisateurs peuvent être définis par un identifiant unique grâce au SAML. En cas de mise à jour d’une identité, celle-ci peut alors être répercutée simplement sur tous les autres services.

Enfin pour le fournisseur de services, la gestion des identités n’est plus un problème. Et ceux-ci seront plus attractifs et compétitifs en étant compatibles avec tous types de SSO. 

Le SAML plus en détails

Il existe, dans un premier temps, un prérequis à l’utilisation du SAML. Un échange de métadonnées doit avoir lieu entre le parti de confiance et le fournisseur d’identité. Sans celui-ci les différentes parties ne pourront pas communiquer entre elles. Cet échange de métadonnées se fera au format XML et servira à spécifier les informations nécessaires au bon fonctionnement de la communication (format des attributs, méthode de connexion…). De cette manière les deux parties pourront s’accorder et configurer leur systèmes avec les informations requises.

Une fois cette étape effectuée, les utilisateurs vont pouvoir commencer à s’authentifier. Pour ce faire le parti de confiance envoie une requête d’authentification (SAML AuthnRequest) au fournisseur d’identité. Celle-ci peut prendre soit la forme d’un formulaire HTTP POST (qui permet la transmission de messages de protocole SAML au format HTML codé en base64). Soit la forme d’une redirection HTTP avec une requête (qui permet aux messages du protocole SAML d'être transmis via les paramètres d'URL). 

Elles permettent aux deux parties de communiquer en utilisant un user-agent HTTP comme intermédiaire. Dans les deux cas, ces requêtes sont vérifiées et signées par le parti de confiance.

Suite à quoi le fournisseur d’identité vérifie la requête. Puis il identifie l’utilisateur et renvoie une réponse SAML contenant une Assertion SAML. Cette assertion SAML est un document XML contenant l'autorisation utilisateur que le fournisseur d'identité envoie au fournisseur de service ou au parti de confiance. Elle est renvoyée via un formulaire POST.

Les réponses et assertions SAML sont signées par le fournisseur d’identité, cela permet de garantir leur authenticité. 

Le SAML : une réponse simple et évidente à l’implémentation d’un SSO.

Le SAML est la méthode la plus répandue dans les entreprises pour mettre en place un SSO. La mise en place d’une comptabilité avec les SSOs peut freiner plus d’un SaaS car cela représente un coût de développement plus élevé. Néanmoins le fait pour un fournisseur de service d’être compatible avec les SSO est souvent une nécessité. Dès lors, un des enjeux pour les SAAS est de devenir “SSO ready”, c'est-à-dire d’avoir la capacité à se connecter aux différents types de SSO et d’identity providers qu’ils peuvent rencontrer chez leurs clients ou prospects entreprises. Satisfaire cette exigence est donc à la fois un enjeu de sécurité mais également un enjeu business pour étendre son marché et contractualiser avec des clients ayant cette attente. Avec quelques lignes de code, Cryptr peut rendre votre authentification compatible avec tous types de SSO (SAML, ADFS, OIDC) et les identity providers (Okta, Ping Identity, Auth0, OneLogin, Google,...) que vous pourriez rencontrer.

Alors prêt à devenir SSO-compatible ? On vous en dit plus chez Cryptr.