La première fois que j’ai vu le mot « claim », j’ai ressenti un certain inconfort, je n’arrivais pas à m’en faire une représentation claire. Bien sûr, c’était dans le contexte de la gestion des permissions utilisateurs, et je le traduisais donc par « droit ». Je suppose que c’est ce que font la plupart des gens dans le même contexte, et pas seulement les français. Mais je me suis alors souvent demandé pourquoi ne pas avoir utilisé le mot « right » ou « permission »?

En tant que développeur, la conceptualisation est un aspect essentiel de notre travail, et il me paraît important que notre mode de pensée soit le mieux aligné sur les modèles extérieurs. Quel développeur n’est jamais tombé sur du code qui trahissait une logique biaisée, où les modèles prévus étaient contournés (voire détournés), et où les contraintes de l’application étaient (re)travaillées, ou plutôt tordues, afin de s’aligner sur le mode de pensée de leur auteur ? Le bon sens devrait nous entraîner à chercher l’inverse (j’insiste sur les acteurs dans cette affirmation – si on parle du domaine métier, évidemment que l’application doit être alignée sur le modèle métier, aussi distant soit-il du modèle du « monde réel ou naturel » – c’est un autre sujet).

Avec cet article qui n’est pas vraiment technique, j’espère aider à mieux appréhender la gestion des autorisations d’accès basées sur les claims. En me documentant, j’ai découvert des choses que je n’aurai sans doute pas apprises sans cet article. J’espère que vous aurez aussi plaisir à les découvrir à travers celui-ci.

Quel sens plus abouti le mot “claim” transporte-t-il par rapport à un droit ?

Dans un premier temps, je m’intéresserai au sens général du mot « claim ». Dans un second temps, je détaillerai celui-ci dans le contexte des autorisations d’accès. Enfin, je ferai une comparaison rapide entre les principaux modèles d’autorisations.

D’abord, son sens général…

Le terme Claim en lui même est largement utilisé dans d’autres domaines, comme le droit juridique et la finance.

Un amalgame: claim = droit

Cette traduction simplifiée masque une partie du sens. Et ça devient un non sens quand on cherche à traduire des expressions comme « claim right« .

Certains dictionnaires donnent cette définition plus exacte, mais pour le moins ambigue dans le contexte des autorisations d’accès: « demander ou affirmer un droit ». On peut trouver curieuse cette ambiguïté entre demander et affirmer, qui sont quelque peu opposés dans la finalité d’utilisation du droit.

Une claim est une revendication

J’ai été à la fois surpris et finalement pas tant que cela, en apprenant que le mot claim est d’origine française, du verbe “clamer”, lui même originaire du latin clamare, qui veut dire “crier” quelque chose (dans sa définition la plus ancienne et aussi la plus rare), ou en tout cas l’exprimer de manière « violente », « extériorisée ». Par extension, il peut s’agir d’exprimer quelque chose à voix haute, de le revendiquer.

Quand on cherche la définition d’une revendication, cela concerne le plus souvent un dû, un droit. Un synonyme de revendiquer est réclamer. Inutile de donner l’origine du mot réclamer… (vient du latin reclamare).

La traduction de « claim right » devient plus facile: c’est la revendication d’un droit. Et finalement, c’est ce sens développé qui se cache derrière le seul nom commun “claim”, utilisé comme un objet abstrait.

Quand on parle de « user claim », cela implique que l’utilisateur revendique un droit. Le terme insiste sur cette notion de revendication, tandis que si on parle de “droit utilisateur”, la notion est plus généraliste. Un droit utilisateur est un… droit. Alors qu’une « user claim » n’est pas nécessairement un droit, mais quelque chose que l’utilisateur présente. Les choses seront rapidement plus claires dans le contexte des autorisations d’accès.

Les Claims au sens des autorisations d’accès

Les Claims ne sont pas apparues avec OAuth…

Il est intéressant de noter que le mot “claim” n’apparait nul part dans la spécification d’OAuth, que ce soit dans sa version 1 ou 2. Il apparaît bien, en revanche, dans la spécification de son extension OpenID Connect centrée sur l’authentification d’un utilisateur.

…mais avec Microsoft

Le nom « claim » dans le contexte des autorisations d’accès semble être une initiative de Microsoft. Cependant, je n’ai pas trouvé de référence permettant de l’affirmer avec certitude.La spécification de Microsoft Active Directory basée sur Kerberos en fait largement usage, au moins depuis 2013 (les spécifications plus anciennes, de 2007 à 2013, ne sont plus publiées par Microsoft).

…ou pas…

La révélation dans ma quête personnelle pour me créer ma représentation la plus claire du concept des claims a été la découverte de cet article du NIST (National Institute of Standards and Technology): Attribute Based Access Control (ABAC).

In November 2009, the Federal Chief Information Officers Council […] published the Federal Identity, Credential, and Access Management (FICAM) Roadmap […], which provided guidance to federal organizations to evolve their logical access control architectures to include the evaluation of attributes as a way to enable access within and between organizations across the […] enterprise. In December 2011, the FICAM Roadmap […] took the next step of calling out ABAC as a recommended access control model for promoting information sharing between diverse and disparate organizations.

Cela n’indique pas que le concept ait été inventé en 2009, mais il semble en tout cas que ce soit sa première formalisation.

Outre la similarité de sens entre « claim » et « attribute », on notera la proximité de la dernière partie de la citation avec la délégation d’accès démocratisée par OAuth.

Attribute-Based Access Control (ABAC) et Claim-Based Access Control (CBAC)

Au cas où l’on douterait du bien fondé de la comparaison du modèle ABAC avec le modèle CBAC, voici quelques autres extraits de l’article du NIST mentionné plus haut, qui sont eux-même généralement extraits du Guide to Attribute Based Access Control (publication 800-162 du NIST):

ABAC is a logical access control model that is distinguishable because it controls access to objects by evaluating rules against the attributes of the entities (subject and object) actions and the environment relevant to a request. Attributes may be considered characteristics of anything that may be defined and to which a value may be assigned. In its most basic form, ABAC relies upon the evaluation of attributes of the subject, attributes of the object, environment conditions, and a formal relationship or access control rule defining the allowable operations for subject-object attribute and environment condition combinations.

Ce qui distingue le modèle ABAC du modèle CBAC est que les Claims sont généralement centrées sur l’utilisateur (d’où le modèle CBAC parfois exprimé sous l’expression The Claims-Based Identity Model). Alors que le modèle ABAC décrit les concepts:

• d’une part, d’attributs d’un sujet (des caractéristiques de l’identité de l’utilisateur) mais aussi d’un objet (des caractéristiques de la ressource) ou même de l’environnement dans lequel l’accès est effectué,
• et d’autre part, de l’autorisation d’accès basée sur la relation entre ces deux entités (utilisateur et ressource) et le contexte de l’accès; La relation est décrite par des règles basées sur leurs attributs.

Dans l’absolu, le modèle ABAC va donc plus loin et est donc plus souple dans l’expression des autorisations d’accès. Voici un dernier extrait qui aborde cette souplesse:

The rules or policies that can be implemented in an ABAC model are limited only to the degree imposed by the computational language. This flexibility enables the greatest breadth of subjects to access the greatest breadth of objects without specifying individual relationships between each subject and each object.

Mais fondamentalement, CBAC (les claims) est clairement inspiré du modèle ABAC (les attributs). Il s’agit pour moi d’une spécialisation de celui-ci. Cette comparaison m’a aidé à bien me représenter les Claims comme des attributs de l’utilisateur et non comme des droits.

Une autre différence qui distingue cette fois le modèle CBAC du modèle ABAC est qu’une Claim inclut la notion d’Autorité responsable de la « signer ». Cette autorité est généralement appelée « issuer ». Cela a lieu dans la phase d’authentification de l’utilisateur. Le modèle ABAC ne s’intéresse pas à cette phase d’authentification, seulement à la représentation des règles basées sur un contexte d’attributs.

Par conséquent, tous les acteurs qui utilisent la notion de Claim, que ce soit l’utilisateur qui les consomme ou une application qui les valide, doivent s’accorder pour faire confiance à l’Autorité qui délivre ces claims (ou qui les signe). Pour OAuth, il s’agit de l’Authorization Server (dont, disont le en passant, le nom est trompeur car il n’est pas responsable des autorisations d’accès dont nous parlons ici, mais – en résumant – de l’autorisation que l’utilisateur donne à l’application qui y fait appel). C’est avant tout parce qu’une application fait confiance à l’Authorization Server (qui a fourni sa signature) qu’elle accepte d’autoriser un utilisateur qui présente ses claims (signées) à accéder à des ressources restreintes.

Bien que le concept d’autorité de confiance ne semble pas être formalisé par le modèle ABAC, il me paraît évident que toute implémentation de ce modèle aura besoin d’un tel concept. Aussi, cette seconde différence entre ABAC et CBAC est surtout dans la formalisation de ce concept.

RBAC, CBAC et ABAC: du modèle le plus concret (simple et limité) au plus abstrait (coûteux et souple)

Pour clarifier la suite:

• RBAC est basé sur des rôles utilisateurs,
• CBAC sur des attributs d’un utilisateur,
• ABAC est basé sur des attributs d’entités.

RBAC

RBAC est une évolution d’un ancien modèle IBAC (Identity-Based Access Control), qui date probablement d’une époque où la gestion des accès concernait surtout des mainframes.On gérait ces autorisations en définissant, pour chaque ressource (des fichiers), la liste des utilisateurs ayant un droit de lecture ou de modification.

De nos jours, RBAC est probablement le modèle le plus connu et le plus couramment implémenté parce qu’il est simple. C’est donc un modèle de choix pour les entreprises telles que Microsoft, Oracle, IBM et autres, lorsque leur priorité est surtout de démontrer à quel point leurs technologies sont faciles à mettre en oeuvre rapidement, tout en étant sécurisées.

C’est aussi le modèle le plus archaïque (parmi ceux encore utilisés) et le moins flexible au changement.

Un exemple typique est lorsqu’on nous demande de développer une application, et de définir des autorisations spéciales pour un groupe « administrateurs ». « Les administrateurs devront pouvoir faire telles actions », par opposition aux « utilisateurs simples » ayant des droits limités. Il pourra y avoir plusieurs groupes d’utilisateurs limités, mais vous avez compris l’idée. Ces « groupes » sont alors codés en dur (en tant que « rôles »), attachés aux ressources (actions ou fonctionnalités), et font partie intégrante de l’application. Pour utiliser un terme qui nous est cher, ils sont fortement couplés à l’application. Que se passe-t-il, six mois plus tard, lorsqu’on nous demande de créer une autre notion d’administrateur, on crée des « super administrateurs » ? On identifie vite les limitations de ce modèle. Le problème est que le choix des groupes est arbitraire et n’a aucun alignement naturel avec les autorisations sous-jacentes (les actions effectuées par ces groupes d’utilisateurs).

Une bien meilleure approche est celle basée sur les activités. Elle est aussi un peu plus élaborée (donc plus longue à mettre en place) que les rôles puisqu’on ajoute un niveau d’indirection. Cette approche permet de découpler les groupes d’utilisateurs (les rôles) de l’application.

Le modèle basé sur les activités est beaucoup moins connu que celui des rôles, pour autant il s’agit d’un modèle bien reconnu. Je l’ai découvert il y a quelques années à travers cet article très très bien écrit, mais on en trouve d’autres, avec des exemples d’implémentation. C’est un modèle qui reste très simple à utiliser.

CBAC

Le modèle CBAC ajoute un niveau d’indirection entre la ressource et l’utilisateur: les attributs de l’utilisateur (ou ses « claims »).

Le modèle basé sur les claims est encore plus abstrait. Cependant, les claims permettent d’exprimer, parmi d’autres attributs, des rôles. On peut très bien assimiler les « claims » à des rôles, et continuer à implémenter la gestion des droits de la même façon qu’on le fait avec des rôles. Techniquement, cela marchera. Il s’agit plus d’exprimer un modèle, une représentation, une théorie (pour reprendre les termes de George Fairbanks): quand on parle de rôle, on se limite à des groupes utilisateurs. Quand on parle de claim, on change de mode de pensée en se laissant beaucoup plus de libertés dans le modèle d’accès.
Cette question sur SO (différence entre claims et rôles) illustre bien cela (notamment un commentaire de Emran Hussain à la fin de sa réponse).

Les autorisations d’accès basées sur les activités, bien que je n’ai pas trouvé de formalisation de ce modèle, sont dans mon interprétation personnelle à mi-chemin entre RBAC/CBAC et ABAC. En fait, l’implémentation des autorisations basées sur des activités est équivalente qu’on utilise les modèles RBAC ou CBAC: la seule différence est que l’autorisation est donnée en fonction de l’appartenance à un rôle pour RBAC ou de la possession d’une claim pour CBAC (claim qui peut représenter un rôle). Dans un certain sens, on peut dire que RBAC et CBAC ont en commun une chose: ils concentrent l’autorisation sur la ressource (ou l’activité) à autoriser. A contrario, le modèle ABAC se concentre davantage sur les relations entre les différentes entités (notamment l’utilisateur et la ressource accédée).

Exprimer les fonctionnalités de l’application sous forme d’activités permet de découpler celles-ci de la gestion des autorisations: on ne marque pas une ressource avec une claim ou un rôle, mais on implémente une couche intermédiaire, la couche responsable de contrôler les accès, qui vérifie la relation entre la ressource (exprimée sous forme d’activité) et les attributs dont l’utilisateur doit disposer.

ABAC

Enfin, le modèle ABAC ajoute encore une indirection puisqu’il permet d’associer des attributs aux ressources, et non plus seulement aux utilisateurs. Le contrôle d’accès est alors une règle entre, d’un côté, les attributs de la ressource, et de l’autre, les attributs requis de l’utilisateur. Et plus généralement, le modèle ABAC permet de donner des attributs au contexte et à l’environnement lui-même. Par exemple, la date et l’heure du jour sont des attributs du contexte au moment où l’autorisation d’accès a lieu.

Cela rend le concept d’activité inutile puisqu’une ressource, du point de vue de la gestion d’accès, est exprimée non plus comme « une activité » mais comme « un ensemble d’attributs ».

On devine que c’est encore plus souple, sans doute plus élégant, mais aussi (beaucoup) plus coûteux à mettre en oeuvre. Les règles permises par le modèle ABAC sont encore plus précises que celles du modèle CBAC.

Conclusions

Pour conclure, une claim est un attribut qui caractérise l’utilisateur. Cette caractéristique n’est pas un droit en soi, mais elle peut éventuellement faire l’objet d’une règle d’accès à une ressource. Cette relation est ce qui permet de découpler l’application (l’ensemble de ses ressources ou fonctionnalités) des droits utilisateurs. Un bon choix de claim est par exemple un attribut LDAP: l’idée est que l’on ne devrait pas avoir à créer de claims pour la gestion des droits d’une application mais utiliser les attributs utilisateur dont on dispose, à partir de leur profil existant.

La spécification d’OAuth, qui ne s’intéresse pas tant à l’utilisateur qu’à la délégation du processus d’authentification (effectivement le plus souvent d’un utilisateur), ne fait pas mention de Claims mais de Scopes. C’est pour cela que la frontière entre scopes et claims est parfois floue dans l’implémentation de ce framework: on demande généralement des « scopes » pour obtenir des « claims » (et seulement lorsqu’on utilise un flow d’authentification qui implique un utilisateur).

Cette notion de « claim » est portée par la spécification d’OpenID Connect, extension d’OAuth 2 spécifiquement conçue pour l’authentification d’un utilisateur.

Enfin, une claim implique trois acteurs:

• l’utilisateur caractérisé par celle-ci,
• l’application qui contrôle l’accès à une ressource
• une Autorité qui certifie la validité de la claim (en la signant).

L’utilisateur et l’application doivent tous deux faire confiance à l’Autorité qui signe les claims. Cet article de MSDN propose une métaphore très parlante sur cette notion de confiance envers l’Autorité qui a signé la claim, en prenant l’exemple d’un aéroport: pour un vol domestique, une carte d’identité nationale suffit généralement parce que celle-ci est signée par une autorité locale du pays. En revanche, pour un vol international, on a besoin d’un passeport, signé par une autorité différente. Lorsqu’on l’on présente la bonne pièce d’identité (celle issue d’une autorité de confiance) à la douane, on effectue la phase d’authentification. Lorsque l’on présente son billet d’avion à l’embarquement (billet qui vient d’une autre autorité que la pièce d’identité, à savoir la compagnie aérienne), on effectue la phase d’autorisation. Dans tous ces contrôles d’accès, on a présenté des attributs que l’on possède à différents acteurs qui n’ont pas de lien direct entre eux. L’important est la confiance qu’ont ces acteurs dans l’autorité (appelée « issuer ») qui a signé les attributs qu’ils ont évalué pour prendre leur décision.

Références

The OAuth 1.0 Protocol (RFC 5849)
The OAuth 2.0 Authorization Framework (RFC 6749)
OpenID Connect Core 1.0
The Kerberos Network Authentication Service (V5, RFC 1510)
Active Directory Technical Specification (MSDN)
An Introduction to Claims (MSDN)