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

Le Federated Identity Ma­na­ge­ment (FIM) fait partie des prin­ci­pales solutions per­met­tant d’accéder à des ap­pli­ca­tions Web et à des struc­tures Cloud en dehors de l’en­tre­prise, sans pour autant négliger la sécurité. Cette approche prévoit des di­rec­tives et des pro­to­coles stan­dar­di­sés veillant à ce que les uti­li­sa­teurs in­di­vi­duels aient accès aux dif­fé­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 si­mul­ta­né­ment plusieurs ap­pli­ca­tions, peut être intégré. Pour parvenir à mettre en œuvre un concept de sécurité de ce type, de nom­breuses en­tre­prises 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, per­met­tant d’échanger des in­for­ma­tions d’au­then­ti­fi­ca­tion et d’au­to­ri­sa­tion. Il a été développé à partir de 2001 par le Security Services Technical Committee du con­sor­tium OASIS (Orga­ni­sa­tion for the Advan­ce­ment of Structured Infor­ma­tion 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 ajus­te­ments que l’on retrouve dans les versions révisées SAML 2.0 et 2.1 (également 1.1). Le standard SAML comprend plusieurs com­po­santes mettant à dis­po­si­tion toutes les fonc­tion­na­li­tés utiles pour décrire et trans­mettre des in­for­ma­tions liées à la sécurité. SAML constitue ainsi une base idéale pour le Federated Identity Ma­na­ge­ment (FIM).

SAML peut notamment être utilisé pour effectuer des dé­cla­ra­tions sur les pro­prié­tés ainsi que sur les au­to­ri­sa­tions d’un uti­li­sa­teur vis-à-vis des autres uti­li­sa­teurs et des en­tre­prises par­te­naires, mais surtout vis-à-vis des ap­pli­ca­tions (dans le concept SAML, ces dernières sont également appelées four­nis­seurs de services). Pour ce faire, le four­nis­seur d’identité (la base de données uti­li­sa­teur cen­tra­li­sée), qui en­re­gistre les in­for­ma­tions uti­li­sa­teur cor­res­pon­dantes, utilise des as­ser­tions au format XML. Un en­vi­ron­ne­ment de vé­ri­fi­ca­tion basé sur le standard SAML dispose également d’autres com­po­santes telles que six pro­to­coles dif­fé­rents ainsi que des bindings et des profils.

Une assertion SAML peut contenir une ou plusieurs dé­cla­ra­tion(s) sur les pro­prié­tés (identité, attributs) et les au­to­ri­sa­tions d’un uti­li­sa­teur. Elle est créée par le four­nis­seur d’identité concerné, c’est-à-dire la base de données uti­li­sa­teur res­pon­sable, 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 four­nis­seur de services procédant à l’accès, à savoir l’ap­pli­ca­tion concernée. Ceci permet de garantir l’intégrité et l’au­then­ti­cité de l’assertion, que l’on nomme également jeton SAML sous sa forme signée. Une fois la vé­ri­fi­ca­tion réussie, le four­nis­seur de services analyse le contenu à pro­pre­ment parler avant de prendre une décision sur un éventuel accès à accorder à l’uti­li­sa­teur.

Les trois types d’as­ser­tions suivants sont spécifiés dans le standard SAML 2.0 :

• Au­then­ti­ca­tion Sta­te­ments : les Au­then­ti­ca­tion Sta­te­ments per­met­tent au four­nis­seur d’identité d’informer l’ap­pli­ca­tion du fait que l’uti­li­sa­teur a été au­then­ti­fié. D’autre part, ce type de dé­cla­ra­tion dans une assertion fournit également des in­for­ma­tions sur le moment de l’au­then­ti­fi­ca­tion et sur la méthode utilisée pour y procéder.
• Attribute Sta­te­ments : les Attribute Sta­te­ments sont des attributs associés à l’uti­li­sa­teur concerné, pouvant être com­mu­ni­qués à l’ap­pli­ca­tion via le jeton SAML cor­res­pon­dant.
• Au­tho­ri­za­tion Decision Sta­te­ments : lorsqu’une assertion SAML contient des Au­tho­ri­za­tion Decision Sta­te­ments, cela implique que l’uti­li­sa­teur concerné s’est vu autoriser ou refuser l’accès à des res­sources spé­ci­fiques.

La spé­ci­fi­ca­tion SAML 2.0 définit une série de pro­to­coles de requête/réponse devant notamment permettre à l’ap­pli­ca­tion de demander une assertion ou de prier un uti­li­sa­teur de s’au­then­ti­fier. Dans le détail, il s’agit des pro­to­coles suivants :

• Au­then­ti­ca­tion Request Protocol : l’Au­then­ti­ca­tion Request Protocol définit des messages de type <Authn­Re­quest> né­ces­saires pour demander à un uti­li­sa­teur précis des as­ser­tions avec Au­then­ti­ca­tion Sta­te­ments. Sur la base de ce protocole, les in­for­ma­tions sont donc trans­mises par la base de données au four­nis­seur de services. On utilise gé­né­ra­le­ment à cet effet le très répandu SAML 2.0 Web Browser SSO Profile (vous en ap­pren­drez plus à ce sujet à la section « Profils »).
• Assertion Query and Request Protocol : pour les requêtes per­met­tant de consulter les as­ser­tions SAML exis­tantes 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 as­ser­tions peut être effectuée sur la base de dif­fé­rents pa­ra­mètres, tels que les types de dé­cla­ra­tions contenus.
• Single Logout Protocol : le Single Logout Protocol définit les requêtes initiant une dé­con­nexion quasi si­mul­ta­née de toutes les sessions actives d’un uti­li­sa­teur. De tels messages peuvent être envoyés par l’uti­li­sa­teur, mais aussi par le four­nis­seur d’identité ou de services. Ce dernier cas survient prin­ci­pa­le­ment lorsqu’une session uti­li­sa­teur a expiré.
• Artifact Re­so­lu­tion Protocol : l’Artifact Re­so­lu­tion Protocol est utilisé pour la trans­mis­sion séparée de messages SAML via un canal sécurisé ou une entité économe en res­sources. Il permet l’envoi de ré­fé­rences sur les as­ser­tions, qu’on appelle également artefacts et qui sont nettement moins vo­lu­mi­neuses que le message à pro­pre­ment parler. Ce protocole permet en outre de supprimer ces ré­fé­rences pour obtenir le message original.
• Name Iden­ti­fier Ma­na­ge­ment Protocol : ce protocole met à dis­po­si­tion des moyens pour modifier la valeur ou le format du nom d’une id
• entité uti­li­sa­teur. L’auteur de la requête peut être le four­nis­seur de services ou d’identité. Par ailleurs, le Name Iden­ti­fier Ma­na­ge­ment Protocol permet de supprimer les as­so­cia­tions cor­res­pon­dantes entre le four­nis­seur de services et le four­nis­seur d’identité qui avaient été générées pour l’au­then­ti­fi­ca­tion de l’identité uti­li­sa­teur initiale.
• Name Iden­ti­fier Mapping Protocol : le Name Iden­ti­fier Mapping Protocol définit des messages de requête et de réponse pour la com­mu­ni­ca­tion entre deux four­nis­seurs de services. En s’appuyant sur ce type de messages, une ap­pli­ca­tion peut demander au four­nis­seur d’identité un iden­ti­fiant pour un uti­li­sa­teur afin de lui permettre d’accéder à une autre ap­pli­ca­tion.

Les mappages de la cor­res­pon­dance SAML dans les pro­to­coles de mes­sa­ge­rie standard ou de com­mu­ni­ca­tion sont appelés Bindings de protocole SAML ou sim­ple­ment bindings. Le SOAP Binding définit par exemple comment les messages SAML sont transmis au sein d’en­vi­ron­ne­ments SOAP tandis que le HTTP Redirect Binding fixe la façon dont les messages du protocole SAML sont transmis via la procédure de trans­mis­sion 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 flexi­bi­lité qui fait de ce framework un candidat idéal pour de nombreux scénarios d’ap­pli­ca­tion. Toutefois, pour que certaines ap­pli­ca­tions soient en mesure d’utiliser SAML, il est né­ces­saire de limiter par­tiel­le­ment cette flexi­bi­lité. On utilise à cet effet des profils qui re­grou­pent une sélection d’as­ser­tions, de pro­to­coles et de bindings pour des cas d’ap­pli­ca­tion spé­ci­fiques. 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éa­li­sa­tion d’une au­then­ti­fi­ca­tion SSO SAML. Il contient ainsi tous les éléments es­sen­tiels pour définir la com­mu­ni­ca­tion des garanties d’au­then­ti­fi­ca­tion SAML entre le four­nis­seur d’identité et le four­nis­seur de services, cette com­mu­ni­ca­tion étant né­ces­saire pour procéder à une connexion unique via n’importe quel na­vi­ga­teur web. Par ailleurs, le framework fournit les profils sup­plé­men­taires suivants :

• Enhanced Client and Proxy (ECP) Profile
• Identity Provider Discovery Profile
• Single Logout Profile
• Name Iden­ti­fier Ma­na­ge­ment Profile
• Artifact Re­so­lu­tion Profile
• Assertion Query/Request Profile
• Name Iden­ti­fier Mapping Profile

Plus de 24 en­tre­prises et or­ga­ni­sa­tions ont participé à la con­cep­tion et à l’éla­bo­ra­tion de la version SAML 2.0 avant qu’elle ne succède of­fi­ciel­le­ment à la version SAML 1.0 ou 1.1 en mars 2005. Outre de nom­breuses amé­lio­ra­tions de fonc­tion­na­li­tés exis­tantes, le framework a également été doté de fonc­tion­na­li­tés en­tiè­re­ment nouvelles reprises du Liberty Alliance Identity Fe­de­ra­tion Framework (ID-FF) 1.2 et de l’ar­chi­tec­ture Shib­bo­leth dé­ve­lop­pée par Internet2.

La liste suivante présente les prin­ci­pales mo­di­fi­ca­tions apportées au framework dans sa deuxième révision « majeure » :

• sup­pres­sion de certains éléments obsolètes tels que <Au­tho­ri­ty­Bin­ding> ou<Res­pond­With> ainsi que du format d’iden­ti­fiant obsolète
• im­plé­men­ta­tion de la signature et du cryptage XML (d’après le standard W3C)
• rem­pla­ce­ment de l’attribut As­ser­tio­nID par un attribut XML ID général
• in­tro­duc­tion de la gestion de session afin de permettre une dé­con­nexion au­to­ma­tique de toutes les ap­pli­ca­tions (par exemple en cas d’absence prolongée)
• mo­di­fi­ca­tion des mé­ta­don­nées pour faciliter l’uti­li­sa­tion de SAML (les instances im­pli­quées, telles que le four­nis­seur d’identité et le four­nis­seur de services, sont désormais indiquées dans les mé­ta­don­nées)
• im­plé­men­ta­tion de mé­ca­nismes per­met­tant aux four­nis­seurs de com­mu­ni­quer des di­rec­tives et des pa­ra­mètres sur la vie privée
• amé­lio­ra­tion de la com­pa­ti­bi­lité avec les appareils mobiles
• im­plé­men­ta­tion des pro­to­coles déjà listés (seule l’assertion Assertion Query and Request Protocol existait dans SAML 1.0 et 1.1)
• op­ti­mi­sa­tion des profils (par ex. fu­sion­ne­ment des profils « Browser/Artifact » et « Browser/Post » dans « SAML 2.0 Web Browser SSO Profile »)

Une liste détaillée des di­ver­gences entre SAML 2.0 et SAML 1.1 est mise à dis­po­si­tion sur la page de la com­mu­nauté SAML SAML.xml.org.

Le domaine d’ap­pli­ca­tion du framework SAML peut être ra­pi­de­ment défini : avec le savoir-faire approprié, il est possible d’im­plé­men­ter une instance d’au­then­ti­fi­ca­tion cen­tra­li­sée basée sur le langage de balisage qui se dé­mar­quera par son ef­fi­ca­cité et son haut niveau de sécurité. Ce niveau de sécurité peut notamment être atteint, car les données uti­li­sa­teurs ne sont pas en­re­gis­trées ou syn­chro­ni­sées par les dif­fé­rentes ap­pli­ca­tions. Cela réduit con­si­dé­ra­ble­ment 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 con­vi­via­lité possible. C’est la raison pour laquelle il supporte la procédure Single Sign-on déjà évoquée à plusieurs reprises grâce aux pro­to­coles et aux formats de messages cor­res­pon­dants.

La procédure SSO SAML, qui permet l’uti­li­sa­tion de diverses ap­pli­ca­tions à l’aide d’une connexion unique, n’est pas uni­que­ment appréciée dans les processus d’ap­pli­ca­tion internes des en­tre­prises : cette connexion unique pratique est aujourd’hui ancrée dans les concepts de dif­fé­rents services Web, notamment dans les domaines de la banque en ligne et des ap­pli­ca­tions mobiles. Il n’est pas rare que l’uti­li­sa­teur n’ait plus cons­cience d’être confronté à plusieurs ap­pli­ca­tions dif­fé­rentes en utilisant de tels services. Par exemple, un client se con­nec­tant une seule fois sur le site Internet de sa banque accédera pro­ba­ble­ment à plus d’un système en arrière-plan lorsqu’il ouvrira suc­ces­si­ve­ment son compte épargne, son compte de dépôt et son compte de carte de crédit. Grâce à la tech­no­lo­gie SAML, il a toutefois l’im­pres­sion d’utiliser un seul programme.