Gestion des identités : les clés pour comprendre

La gestion des identités et des autorisations est un sujet aussi ancien que l’informatique de gestion. Pourtant ce sujet délicat reste encore trop souvent mal compris. Entre articles académiques et tutoriels qui font l'impasse sur les concepts, les sources d'information de qualité sur ce sujet restent rares.

SSO, fédération d’identité et toute cette sorte de choses

Définir quels utilisateurs d’un système informatique ont accès à quelles ressources et contrôler l’application de ces règles, voilà en quelques mots ce qu’on entend par IAM, acronyme anglais pour Identity and Access Management. Pour mieux cerner cette problématique, envisageons-la selon les points de vue de quatre acteurs directement concernés : (1) celui d’un utilisateur métier tout d’abord, (2) celui d’un administrateur système ensuite, (3) celui d’un architecte logiciel et, enfin, (4) celui d’un responsable sécurité du SI. Les termes en gras dans le texte sont définis dans le glossaire en appendice.

1. 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.
2. 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é.
3. 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