SAML : aperçu du framework XML pour SSO (SAML) et d’autres procédures

Le Federated Identity Management (FIM) fait partie des principales solutions permettant d’accéder à des applications Web et à des structures Cloud en dehors de l’entreprise, sans pour autant négliger la sécurité. Cette approche prévoit des directives et des protocoles standardisés veillant à ce que les utilisateurs individuels aient accès aux différents services sans utiliser aucune base de données locale commune. C’est d’ailleurs de cette façon que le très apprécié single sign-on (SSO), une procédure de connexion unique qui permet d’utiliser simultanément plusieurs applications, peut être intégré. Pour parvenir à mettre en œuvre un concept de sécurité de ce type, de nombreuses entreprises ont recours au framework XML SAML (Security Assertion Markup Language).

Security Assertion Markup Language, abrégé en SAML, est un framework open source basé sur XML, permettant d’échanger des informations d’authentification et d’autorisation. Il a été développé à partir de 2001 par le Security Services Technical Committee du consortium OASIS (Organisation for the Advancement of Structured Information Standards) qui en a publié la première version (SAML v1.0) en novembre 2002. Au fil du temps, l’équipe de projet a procédé à divers ajustements que l’on retrouve dans les versions révisées SAML 2.0 et 2.1 (également 1.1). Le standard SAML comprend plusieurs composantes mettant à disposition toutes les fonctionnalités utiles pour décrire et transmettre des informations liées à la sécurité. SAML constitue ainsi une base idéale pour le Federated Identity Management (FIM).

SAML peut notamment être utilisé pour effectuer des déclarations sur les propriétés ainsi que sur les autorisations d’un utilisateur vis-à-vis des autres utilisateurs et des entreprises partenaires, mais surtout vis-à-vis des applications (dans le concept SAML, ces dernières sont également appelées fournisseurs de services). Pour ce faire, le fournisseur d’identité (la base de données utilisateur centralisée), qui enregistre les informations utilisateur correspondantes, utilise des assertions au format XML. Un environnement de vérification basé sur le standard SAML dispose également d’autres composantes telles que six protocoles différents ainsi que des bindings et des profils.

Une assertion SAML peut contenir une ou plusieurs déclaration(s) sur les propriétés (identité, attributs) et les autorisations d’un utilisateur. Elle est créée par le fournisseur d’identité concerné, c’est-à-dire la base de données utilisateur responsable, en utilisant XML comme langage de balisage. Chaque assertion reçoit également une signature numérique qui est dans un premier temps contrôlée par le fournisseur de services procédant à l’accès, à savoir l’application concernée. Ceci permet de garantir l’intégrité et l’authenticité de l’assertion, que l’on nomme également jeton SAML sous sa forme signée. Une fois la vérification réussie, le fournisseur de services analyse le contenu à proprement parler avant de prendre une décision sur un éventuel accès à accorder à l’utilisateur.

Les trois types d’assertions suivants sont spécifiés dans le standard SAML 2.0 :

• Authentication Statements : les Authentication Statements permettent au fournisseur d’identité d’informer l’application du fait que l’utilisateur a été authentifié. D’autre part, ce type de déclaration dans une assertion fournit également des informations sur le moment de l’authentification et sur la méthode utilisée pour y procéder.
• Attribute Statements : les Attribute Statements sont des attributs associés à l’utilisateur concerné, pouvant être communiqués à l’application via le jeton SAML correspondant.
• Authorization Decision Statements : lorsqu’une assertion SAML contient des Authorization Decision Statements, cela implique que l’utilisateur concerné s’est vu autoriser ou refuser l’accès à des ressources spécifiques.

La spécification SAML 2.0 définit une série de protocoles de requête/réponse devant notamment permettre à l’application de demander une assertion ou de prier un utilisateur de s’authentifier. Dans le détail, il s’agit des protocoles suivants :

• Authentication Request Protocol : l’Authentication Request Protocol définit des messages de type <AuthnRequest> nécessaires pour demander à un utilisateur précis des assertions avec Authentication Statements. Sur la base de ce protocole, les informations sont donc transmises par la base de données au fournisseur de services. On utilise généralement à cet effet le très répandu SAML 2.0 Web Browser SSO Profile (vous en apprendrez plus à ce sujet à la section « Profils »).
• Assertion Query and Request Protocol : pour les requêtes permettant de consulter les assertions SAML existantes de façon générale, le framework dispose de l’Assertion Query and Request Protocol. Dans le cadre de ce protocole, la demande des assertions peut être effectuée sur la base de différents paramètres, tels que les types de déclarations contenus.
• Single Logout Protocol : le Single Logout Protocol définit les requêtes initiant une déconnexion quasi simultanée de toutes les sessions actives d’un utilisateur. De tels messages peuvent être envoyés par l’utilisateur, mais aussi par le fournisseur d’identité ou de services. Ce dernier cas survient principalement lorsqu’une session utilisateur a expiré.
• Artifact Resolution Protocol : l’Artifact Resolution Protocol est utilisé pour la transmission séparée de messages SAML via un canal sécurisé ou une entité économe en ressources. Il permet l’envoi de références sur les assertions, qu’on appelle également artefacts et qui sont nettement moins volumineuses que le message à proprement parler. Ce protocole permet en outre de supprimer ces références pour obtenir le message original.
• Name Identifier Management Protocol : ce protocole met à disposition des moyens pour modifier la valeur ou le format du nom d’une id
• entité utilisateur. L’auteur de la requête peut être le fournisseur de services ou d’identité. Par ailleurs, le Name Identifier Management Protocol permet de supprimer les associations correspondantes entre le fournisseur de services et le fournisseur d’identité qui avaient été générées pour l’authentification de l’identité utilisateur initiale.
• Name Identifier Mapping Protocol : le Name Identifier Mapping Protocol définit des messages de requête et de réponse pour la communication entre deux fournisseurs de services. En s’appuyant sur ce type de messages, une application peut demander au fournisseur d’identité un identifiant pour un utilisateur afin de lui permettre d’accéder à une autre application.

Les mappages de la correspondance SAML dans les protocoles de messagerie standard ou de communication sont appelés Bindings de protocole SAML ou simplement bindings. Le SOAP Binding définit par exemple comment les messages SAML sont transmis au sein d’environnements SOAP tandis que le HTTP Redirect Binding fixe la façon dont les messages du protocole SAML sont transmis via la procédure de transmission HTTP. Parmi les autres bindings utilisés dans le standard SAML 2.0, on trouve :

• Reverse SOAP Binding
• HTTP POST Binding
• HTTP Artifact Binding
• SAML URI Binding

En tant que standard général, le SAML se démarque par sa flexibilité qui fait de ce framework un candidat idéal pour de nombreux scénarios d’application. Toutefois, pour que certaines applications soient en mesure d’utiliser SAML, il est nécessaire de limiter partiellement cette flexibilité. On utilise à cet effet des profils qui regroupent une sélection d’assertions, de protocoles et de bindings pour des cas d’application spécifiques. L’un des profils les plus utilisés est le SAML 2.0 Web Browser SSO Profile déjà évoqué qui spécifie le cadre pour la réalisation d’une authentification SSO SAML. Il contient ainsi tous les éléments essentiels pour définir la communication des garanties d’authentification SAML entre le fournisseur d’identité et le fournisseur de services, cette communication étant nécessaire pour procéder à une connexion unique via n’importe quel navigateur web. Par ailleurs, le framework fournit les profils supplémentaires suivants :

• Enhanced Client and Proxy (ECP) Profile
• Identity Provider Discovery Profile
• Single Logout Profile
• Name Identifier Management Profile
• Artifact Resolution Profile
• Assertion Query/Request Profile
• Name Identifier Mapping Profile

Plus de 24 entreprises et organisations ont participé à la conception et à l’élaboration de la version SAML 2.0 avant qu’elle ne succède officiellement à la version SAML 1.0 ou 1.1 en mars 2005. Outre de nombreuses améliorations de fonctionnalités existantes, le framework a également été doté de fonctionnalités entièrement nouvelles reprises du Liberty Alliance Identity Federation Framework (ID-FF) 1.2 et de l’architecture Shibboleth développée par Internet2.

La liste suivante présente les principales modifications apportées au framework dans sa deuxième révision « majeure » :

• suppression de certains éléments obsolètes tels que <AuthorityBinding> ou<RespondWith> ainsi que du format d’identifiant obsolète
• implémentation de la signature et du cryptage XML (d’après le standard W3C)
• remplacement de l’attribut AssertionID par un attribut XML ID général
• introduction de la gestion de session afin de permettre une déconnexion automatique de toutes les applications (par exemple en cas d’absence prolongée)
• modification des métadonnées pour faciliter l’utilisation de SAML (les instances impliquées, telles que le fournisseur d’identité et le fournisseur de services, sont désormais indiquées dans les métadonnées)
• implémentation de mécanismes permettant aux fournisseurs de communiquer des directives et des paramètres sur la vie privée
• amélioration de la compatibilité avec les appareils mobiles
• implémentation des protocoles déjà listés (seule l’assertion Assertion Query and Request Protocol existait dans SAML 1.0 et 1.1)
• optimisation des profils (par ex. fusionnement des profils « Browser/Artifact » et « Browser/Post » dans « SAML 2.0 Web Browser SSO Profile »)

Une liste détaillée des divergences entre SAML 2.0 et SAML 1.1 est mise à disposition sur la page de la communauté SAML SAML.xml.org.

Le domaine d’application du framework SAML peut être rapidement défini : avec le savoir-faire approprié, il est possible d’implémenter une instance d’authentification centralisée basée sur le langage de balisage qui se démarquera par son efficacité et son haut niveau de sécurité. Ce niveau de sécurité peut notamment être atteint, car les données utilisateurs ne sont pas enregistrées ou synchronisées par les différentes applications. Cela réduit considérablement le nombre de failles de sécurité possibles. Le but principal de ce framework est d’associer ce haut niveau de sécurité à la meilleure convivialité possible. C’est la raison pour laquelle il supporte la procédure Single Sign-on déjà évoquée à plusieurs reprises grâce aux protocoles et aux formats de messages correspondants.

La procédure SSO SAML, qui permet l’utilisation de diverses applications à l’aide d’une connexion unique, n’est pas uniquement appréciée dans les processus d’application internes des entreprises : cette connexion unique pratique est aujourd’hui ancrée dans les concepts de différents services Web, notamment dans les domaines de la banque en ligne et des applications mobiles. Il n’est pas rare que l’utilisateur n’ait plus conscience d’être confronté à plusieurs applications différentes en utilisant de tels services. Par exemple, un client se connectant une seule fois sur le site Internet de sa banque accédera probablement à plus d’un système en arrière-plan lorsqu’il ouvrira successivement son compte épargne, son compte de dépôt et son compte de carte de crédit. Grâce à la technologie SAML, il a toutefois l’impression d’utiliser un seul programme.