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 (Security Assertion Markup Language) est un framework XML open source permettant d’échanger des informations d’authentification et d’autorisation. Les différentes composantes de SAML, dont font notamment partie une base de données utilisateur centralisée et six protocoles différents, mettent à disposition toutes les fonctionnalités utiles pour décrire et transmettre des fonctionnalités de sécurité. C’est la raison pour laquelle SAML est considéré comme une solution complète convenant parfaitement au 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 :
Le nombre de statements dans une assertion dépend en premier lieu du domaine d’application du framework SAML. Par exemple, si un Single Sign-on doit être réalisé, le jeton SAML contient normalement un seul Authentication Statement et un seul Attribute Statement.
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 :
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 :
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 :
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 base de données d’authentification centralisée est uniquement nommée « fournisseur d’identité » depuis SAML 2.0, le terme ayant été repris de la terminologie de Liberty Alliance. Dans les versions précédentes, on appelait encore cette instance « autorité d’authentification ».
La liste suivante présente les principales modifications apportées au framework dans sa deuxième révision « majeure » :
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.
En pratique, on observe une distinction entre le « Service Provider initiated SAML » et le « Identity Provider initiated SAML ». La différence entre ces deux concepts réside dans l’instance à laquelle la requête d’authentification de l’utilisateur est envoyée (au fournisseur de services ou au fournisseur d’identité).
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.
E. Hammer-Lahav, qui a longtemps travaillé sur OAuth 2.0, a caractérisé ce protocole de « descente aux enfers ». Mais de nombreux analystes ont jugé que cette norme ouverte pour les applications de bureau, Web et mobiles jouait son rôle : permettre aux utilisateurs d’utiliser des données et des fonctionnalités sur de multiples plateformes. Mais comment fonctionne OAuth2 et est-il sécurisé ?
La vie en ligne serait si simple si l’on pouvait saisir une seule fois nos données d’accès, les enregistrer et rester connecté, au lieu de retenir une douzaine de mots de passe ! C’est chose faite avec le SSO, toujours plus populaire parmi les utilisateurs. Mais la commodité et la prétendue sécurité des données s’accompagnent de certains inconvénients sur lesquels les fournisseurs se gardent bien...
JSON Web Token (JWT) est un standard ouvert pour l’authentification flexible des utilisateurs. Les données sont échangées entre les interlocuteurs en toute sécurité et peuvent être vérifiées. Une signature numérique assure en outre la fiabilité des données. Découvrez ici ce qu’est un JWT, comment cela fonctionne et pourquoi il est judicieux d’utiliser cette technologie.
Offrez un service performant et fiable à vos clients avec l'hébergement web de IONOS.
Voir les packs
