SSO, fédération d’identité et toute cette sorte de choses
- Un utilisateur, ou plus généralement une entité, aura généralement besoin accéder à plusieurs applications[1] avec des habilitations spécifiques pour chacune d’elles, qu’il s’agisse d’applications web ou d’applications locales. En règle générale ces habilitations dépendent de l’identité de cet utilisateur et du contexte dans lequel il s’est authentifié. Pour lui, la procédure d’authentification doit rester transparente et, idéalement, n’impliquer qu’une étape de validation lui ouvrant l’accès aux services dont il a l’usage pour sa mission. C’est ce qu’il est convenu d’appeler une procédure de type SSO. Un utilisateur plus scrupuleux pourrait avoir encore d’autres exigences. Celle par exemple d’avoir la garantie qu’aucune corrélation ne puisse être établie entre ses activités auprès des différents services qu’il a utilisés.
- Afin de protéger l’accès aux ressources d’un SI, la première préoccupation d’un administrateur système est de pouvoir créer et gérer aisément de nouveaux comptes dotées des habilitations adéquates. Différentes stratégies existent pour cela. Certaines procèdent indirectement en attribuant des habilitation à des rôles plutôt qu’à des entités. Pour certains services particulièrement sensibles un administrateur doit également pouvoir exiger une procédure d’authentification plus rigoureuse. L’administrateur système devra s’assurer enfin de la sécurité et de l’intégrité des données d’authentification pour empêcher toute usurpation d’identité.
- L’une des responsabilités d’un architecte logiciel est de concevoir des systèmes évolutifs. Découpler les mécanismes d’authentification du code applicatif est pour lui un impératif, d’autant plus que les contraintes de sécurité propres à ces mécanismes requièrent un code hautement spécialisé qu’il est inconcevable de réinventer à chaque nouveau développement. Ces mécanismes contiennent deux composantes. La première est un annuaire externe, souvent propre à une organisation, qui regroupe en lieu sûr les informations des comptes utilisateurs. On l’appelle fournisseur d’identité (ou IdP). La seconde, installée en frontal du service proprement dit, est chargée d’intercepter les demandes d’accès d’entités non encore authentifiées, de transmettre les requêtes d’authentification à l’IdP puis enfin d’interpréter la réponse obtenue pour en extraire les habilitations qui permettront de personnaliser le fonctionnement du service. L’application ainsi protégée est appelée un fournisseur de service (SP).
- (4)Lorsque les applications qui doivent bénéficier d’un SSO appartiennent à des domaines d’identité différents, c.-à-d. qu’elles utilisent plusieurs IdP, le RSSI devra prévoir la mise en place d’un mécanisme de fédération d’identité chargé de propager de manière anonyme les identités locales entre les différents domaines.
Les bénéfices d’un SSO vont au-delà du confort et de la productivité d’utilisateurs à qui l’on évite de fastidieuses réauthentifications. La gestion de comptes utilisateurs par l’administrateur se trouve elle aussi simplifiée. Si l’on tient compte par ailleurs de la faillibilité humaine, les chances de dissémination des mots de passe sont réduites, car chaque utilisateur n’en a qu’un à retenir.
SAML 2.0 : et la lumière fut !
SAML 2.0 est un standard basé sur XML qui formalise une sémantique et une syntaxe précise pour l’échange d’informations de sécurité entre plusieurs participants qui souhaitent établir des liens de confiance cryptographiques. Il a été publié en 2005 par le consortium OASIS[2].
Dans le cadre de la mise en œuvre d’un SSO, la norme SAML définit les deux rôles que peuvent assumer ces participants ainsi que les messages qu’ils sont susceptibles de transmettre et de recevoir : le fournisseur de service (SP) et le fournisseur d’identité (IdP), déjà évoqués plus haut. Lorsqu’une entité souhaite accéder à une ressource protégée mise à disposition par un SP, celui-ci intercepte cette demande et transmet une requête d’authentification de cette entité à un IdP avec lequel il a établi un lien de confiance, lequel renvoie alors une assertion à propos de l’entité qui contient des informations du type « Jean Dupond a été authentifié à 11 heures 09 au moyen de son empreinte digitale. Il possède la liste d’attributs que voici. » Assertions sur la base desquelles le SP prendra la décision d’accorder ou non l’accès à la ressource demandée par l’entité.
Aux assertions, SAML ajoute trois autres concepts, logiquement imbriqués, qui spécifient comment doivent être orchestrés les échanges entre participants pour réaliser telle ou telle tâche. Des protocoles SAML définissent l’ordre, la structure et le contenu valides de requêtes et de réponses, sous forme d’assertions, pour réaliser certaines tâches. Les bindings SAML spécifient comment ces successions de requêtes-réponses doivent être implémentées techniquement[3]. Enfin, des profils SAML spécifient des contraintes supplémentaires à respecter sur les éléments précédents lorsqu’il s’agit de réaliser certains cas d’utilisation spécifiques. Le profil SSO, mentionné précédemment en guise d’illustration, n’est qu’un exemple parmi d’autres.
Il est important de noter toutefois que SAML ne prescrit rien sur la manière de construire des habilitations ! C’est probablement la partie la plus délicate d’IAM. Elle est du ressort d’un RSSI. L’un des modèles actuellement en vogue est RBAC (Role-Based Access Control) qui procède par définition de rôles. Dans une approche bottom-up ces rôles sont définis à partir d’habilitations existantes alors que dans une approche top-down on part plutôt des fonctions métiers pour définir des rôles.
Impossible de parler de SAML sans évoquer Shibboleth. Il s’agit d’un middleware open source constitué de deux composantes qui permettent de construire des IdP et des SP conformes au standard SAML. L’une des composantes vient se greffer devant une ressource à protéger pour en faire un SP (interception de demande, transmission de requête et interprétation des réponses). L’autre vient encapsuler un annuaire LDAP ou une base de données pour en faire un IdP. Des mécanismes de fédération d’identité comme Kerberos peuvent être utilisés conjointement.
Pour ne pas s’égarer
La gestion des identités et des autorisations est un sujet aussi ancien que l’informatique de gestion. Quiconque souhaite aujourd’hui se former sur le sujet trouvera sur le web pléthore de tutoriaux, d’introductions « pour les nuls » et de livres blancs. Hélas, nombre d’auteurs mélangent allègrement procédures d’installation, concepts IAM et folklore IT au détriment de toute clarté conceptuelle. Voilà qui ravira sans doute les consultants friands de « numéros de claquettes ». En revanche ceux qui n’ont pas encore renié leur éthique d’ingénieur et sont en quête d’une authentique compréhension de ce sujet complexe resteront sur leur faim. Le meilleur conseil que nous puissions leur donner pour aborder ce sujet est de combiner deux types de sources. Pour ce qui est de la clarté conceptuelle, on la trouvera par exemple dans des textes à caractère scientifique comme cette publication du CNRS. Il faudra cependant passer outre le caractère un peu « bourbakiste » de cette prose. Pour ce qui est du pragmatisme, une approche anglo-saxonne de type « hands-on » qui consiste à installer un outil comme Shibboleth et à le tester permettra de faire atterrir les concepts dans la réalité opérationnelle. Hélas, pour établir les liens entre ces deux aspects, le néophyte autodidacte ne pourra compter pour l’instant que sur ses propres ressources.
Glossaire
- Assertion [SAML] : Un ensemble d’informations à propos d’une entité fournies par une autorité SAML comme un IdP par exemple et consommée par un SP. Sa structure est définie par la norme SAML.
- Authentification : Le processus qui permet de vérifier que l’identité revendiquée par une entité est légitime. Il existe trois mécanismes de reconnaissance basés sur ce que l’entité connait (un mot de passe), sur ce qu’elle possède (un téléphone) ou sur l’une de ses caractéristiques physiques (biométrie).
- Autorisation : C’est le processus qui établit les habilitations d’une entité à partir des informations contenue dans son compte utilisateur. Il existe différents modèles d’autorisation comme RBAC p.ex.
- Binding [SAML] : Un transcodage prescrit par SAML d’un échange de requêtes-réponses vers l’un des protocoles de communication usuels comme SAOP ou HTTP.
- Compte : Il associe un identifiant, un justificatif d’identité ainsi que d’autres attributs. Il peut être la représentation informatique d’une ou de plusieurs identités. Il existe plusieurs types de comptes : utilisateur, global ou administrateur (non associé à une identité).
- Domaine d’identité (=contexte) : L’ensemble composé d’un fournisseur d’identité et des consommateurs d’identités pour lesquels une identité est connue.
- Entité (=principal=subject) : Une personne physique ou morale, une ressource ou un groupe d’entités. Une entité peut posséder plusieurs identités. Chaque identité permet alors d’exposer des informations en fonction du domaine d’identité.
- Fédération d’identité : Un accord entre plusieurs domaines d’identité qui spécifie comment les différentes parties prenantes peuvent échanger des informations relatives aux identités. L’établissement d’un tel accord peut nécessité l’assentiment de l’utilisateur.
- Fournisseur d’identité (= Identity Provier = IdP) : Le système qui fournit des assertions à propos d’une entité.
- Fournisseur de service (= Service Provider = SP) : Sur le plan conceptuel c’est un système qui propose un service à une entité authentifiée par un IdP. Dans le cadre de Shibboleth désigne l’implémentation du gestionnaire de requêtes compatible SAML.
- Habilitation : Un droit d’effectuer une action sur une ressource accordé à une entité. Il dépend d’un périmètre fonctionnel, temporel et géographique. Les habilitations constituent l’une des contraintes qui limitent l’accès à une ressource tout comme le mode d’authentification ou le périmètre d’accès.
- Identité : Un ensemble de caractéristiques par lesquelles une entité est reconnue dans un certain contexte. Une entité peut posséder plusieurs identités selon le contexte.
- Identifiant : Une information qui permet de distinguer sans ambiguïté une identité d’une autre pour un contexte donné.
- Protocole [SAML] : La définition de l’ordre, de la structure et d’un contenu valides de requêtes et de réponses, (sous forme d’assertions), pour réaliser certaines tâches liées à la sécurité.
- Profile [SAML] : Un cas d’utilisation lié à la sécurité. WebSSO est un exemple.
- Rôle (profil, groupe) : Un ensemble d’habilitations nécessaires à l’accomplissement d’une mission. Rarement associés à un compte, ils sont le plus souvent attribués au travers de profils métiers.
- SSO (Single Sign On) : L’acception la plus courante de ce terme est informelle et désigne la possibilité pour un utilisateur de s’authentifier une seule fois pour avoir accès à plusieurs services. Dans un SAML, Web Browser SSO désigne l’un profil prédéfinit par ce standard.
- RSSI : L’abréviation de responsable de la sécurité des systèmes d’information.
Téléchargez l’article
[1] On parle le plus souvent de fournisseur de services dans un contexte IAM.
[2] Avant son avènement ces informations étaient échangées au moyen des cookies de navigateurs lorsqu’elles étaient confinées à un seul domaine DNS et au moyen de mécanismes propriétaires dans les situations impliquant plusieurs domaines.
[3] Au niveau des protocoles de communication comme SOAP ou HTTP par exemple.