- ARTICLE -

SAML 2.0 : principe de fonctionnement

SAML est un protocole basé sur XML, ce qui le rend extrêmement flexible. Deux partenaires de fédération peuvent choisir de partager n’importe quel attribut d’identité de leur choix dans une assertion (c’est-à-dire un message) SAML, à condition que ces attributs puissent être représentés dans XML. Cette flexibilité a conduit à ce que des éléments du standard SAML, telles que le format d’assertion SAML, soient intégrées à d’autres standards dont WS-Federation.

Cette interopérabilité donne également au SAML un énorme avantage sur les mécanismes de SSO propriétaire. Pour une entreprise, le SSO propriétaire signifie que chaque nouvelle connexion nécessite potentiellement d’installer un nouveau logiciel différent ou des connecteurs d’intégration propriétaires. Avec SAML, une seule implémentation peut prendre en charge des connexions SSO avec de nombreux partenaires de fédération différents. Certaines grandes organisations, en particulier celles qui ont déjà dû supporter plusieurs installations de SSO propriétaires, requièrent désormais l’utilisation du SAML pour le SSO sur Internet avec des applications Identity-as-a-Service (IDaaS) et d’autres prestataires de services externes.

L’initiative Kantara a mis en place un programme de test d’interopérabilité très performant où les fournisseurs SAML démontrent une interopérabilité originale avec d’autres installations SAML. L’interopérabilité du serveur de fédération d’entreprise de Ping, PingFederate, a été largement testée avec un certain nombre d’autres installations SAML, à la fois au moyen de tests d’interopérabilité formels et sur de nombreuses années d’utilisation dans le monde réel par certaines des plus grandes entreprises. Un produit certifié peut traduire la différence entre une configuration simple en deux heures avec des tests, et un cauchemar de débogage distribué s’étalant sur plusieurs mois.

Il existe deux cas de figure courants pour SAML. Le premier est une SSO initiée par le fournisseur d’identité, le second est une SSO initiée par le prestataire de services.

SSO initiée par le fournisseur d’identité avec authentification SAML

La SSO initiée par le fournisseur d’identité est généralement utilisée dans les solutions SSO des employés, comme PingOne for Enterprise par exemple. Dans ce cas de figure, les utilisateurs se connectent au système, lequel présente un catalogue d’applications. Ce catalogue contient des icônes visuelles de toutes les applications internes et externes pour lesquelles l’entreprise a configuré une SSO et les utilisateurs disposent d’un accès autorisé.

Les applications les plus souvent utilisées sont généralement classées en haut pour un accès rapide. Voici à quoi cela ressemble dans PingOne for Enterprise :

Lorsque l’utilisateur clique sur l’une des images, le flux SAML se présente comme suit :

• Le fournisseur d’identité SAML prend l’identité de l’utilisateur ainsi que tout autre attribut que les deux parties acceptent de communiquer.
• Il génère une assertion SAML au format XML.
• Il enregistre cette assertion avec une clé privée issue d’une paire de clés publique/privée qui a été échangée entre le fournisseur d’identité et le prestataire de services lors de la configuration du partenariat SSO.
• Il envoie ensuite cette assertion au prestataire de services via le navigateur de l’utilisateur ou il envoie une référence de cette assertion que le prestataire de services peut utiliser en toute sécurité pour récupérer l’assertion.

Une fois l’assertion SAML reçue par le prestataire de services, celui-ci valide la signature avec la clé publique afin de s’assurer que l’assertion SAML provient bien d’un fournisseur d’identité fiable et qu’aucune des valeurs de l’assertion n’a été modifiée. Le prestataire de services peut alors extraire l’identité de l’utilisateur de l’assertion SAML avec tout autre attribut requis. À ce stade, l’utilisateur se trouve sur la page d’accueil du prestataire de services, comme s’il s’était connecté manuellement au site.

Ce schéma représente les étapes dans un flux SSO initié par un fournisseur d’identité avec SAML :
 

SSO initiée par un prestataire de services avec l’authentification SAML

L’authentification SSO initiée par un prestataire de services commence lorsqu’un utilisateur essaie d’accéder à une ressource du prestataire de services mais ne s’est pas encore authentifié auprès du prestataire de services. Il est possible qu’un utilisateur accède directement au site Web ou qu’il ait enregistré un lien vers une ressource spécifique du prestataire de services. Lorsque le prestataire de services remarque que l’utilisateur n’a pas de session active, il le redirige alors vers le fournisseur d’identité afin qu’il s’authentifie. Le fournisseur d’identité authentifie l’utilisateur, crée l’assertion et redirige l’utilisateur de nouveau vers le prestataire de services, comme dans le cas d’une authentification initiée par un fournisseur d’identité, sauf qu’il renvoie également l’URL de la ressource à laquelle l’utilisateur tentait d’accéder, si celle-ci était fournie par le prestataire de services.

Vous vous demandez peut-être comment le prestataire de services sait vers quel fournisseur d’identité rediriger l’utilisateur s’il prend en charge l’authentification SSO de plusieurs fournisseurs d’identité distincts. La réponse est : cela dépend. Le prestataire de services peut déterminer vers quel fournisseur d’identité rediriger l’utilisateur suivant ces quelques méthodes courantes :

• Le prestataire de services peut demander à l’utilisateur son adresse e-mail et utiliser le domaine de l’e-mail, par exemple : bill@pingidentity.com, afin de déterminer quel fournisseur d’identité utiliser.
• Le prestataire de services peut afficher une liste des fournisseurs d’identité qu’il prend en charge et demander à l’utilisateur de choisir celui qui convient.
• L’URL de la ressource peut être spécifique à un fournisseur d’identité.
• Le prestataire de services peut avoir créé un cookie contenant les informations du fournisseur d’identité dans le navigateur de l’utilisateur lors de la première connexion effective de l’utilisateur et utilisera ces informations lors des connexions suivantes.

Une fois l’assertion SAML reçue par le prestataire de services, celui-ci valide la signature avec la clé publique afin de s’assurer que l’assertion SAML provient bien d’un fournisseur d’identité fiable et qu’aucune des valeurs de l’assertion n’a été modifiée. Le prestataire de services peut alors extraire l’identité de l’utilisateur de l’assertion SAML avec tout autre attribut requis. À ce stade, l’utilisateur se trouve sur la page d’accueil du prestataire de services, comme s’il s’était connecté manuellement au site.

Ce schéma représente les étapes dans un flux SSO initié par un prestataire de services avec SAML :