CIAM 102 : Autorisation et contrôle d'accès basé sur les rôles

Contexte#

Dans l'article précédent, nous avons introduit le concept d'authentification (AuthN) et d'autorisation (AuthZ), avec certains termes qui donnent mal à la tête : Identité, Organisation, Locataire, etc.

L'organisation et le locataire sont excellents pour regrouper les identités, mais ils aboutissent à une démocratie absolue : tout le monde peut faire n'importe quoi dans ce système. Alors que l'utopie reste un mystère, jetons un coup d'œil à la gouvernance de l'accès : l'autorisation (AuthZ).

Pourquoi avons-nous besoin d'autorisation ?#

Notion est un excellent exemple. Pour chaque page que vous possédez, vous pouvez choisir de la garder privée, accessible uniquement à vous, ou de la partager avec des amis, voire le public.

Ou, pour une librairie en ligne, vous voulez que tout le monde puisse voir tous les livres, mais que les clients ne puissent voir que leurs propres commandes, et que les vendeurs ne puissent gérer que les livres de leur magasin.

AuthZ et AuthN sont des composants essentiels d'un modèle d'entreprise complexe. Ils vont souvent de pair ; AuthZ vérifie l'accès d'un utilisateur, tandis qu'AuthN authentifie les identités. Les deux sont nécessaires pour un système sécurisé.

Le modèle d'autorisation de base#

Voici l'un des modèles AuthZ les plus courants : Si IDENTITÉ effectue ACTION sur RESSOURCE, alors ACCEPTER ou REFUSER.

Dans l'exemple de Notion, le modèle est PERSONNE effectue VUE sur PAGE.

Si la page est privée :

• Vous recevrez ACCEPTER lors de l'exécution de VUE sur votre PAGE.
• Tous les autres devraient recevoir REFUSER lors de l'exécution de VUE sur votre PAGE.

Sur la base d'un consensus, l'industrie a développé diverses technologies d'autorisation, telles que le contrôle d'accès basé sur les rôles (RBAC), le contrôle d'accès basé sur les attributs (ABAC). Aujourd'hui, nous allons nous concentrer sur le modèle RBAC NIST Niveau 1 : Flat RBAC.

Contrôle d'accès basé sur les rôles#

Étendons l'exemple de la librairie. Disons que nous avons de nombreux clients, mais un seul vendeur :

• Les clients peuvent voir et commander des livres, ainsi que voir leurs propres commandes.
• Le vendeur peut voir, créer et supprimer des livres, et gérer les commandes des clients.

Définir les ressources#

Dans Logto, une ressource (c'est-à-dire une ressource API) représente généralement un ensemble d'entités ou d'éléments, car il est nécessaire d'utiliser une URL valide comme indicateur. Nous définissons donc deux ressources :

• Livres : https://api.librairie.io/livres
• Commandes : https://api.librairie.io/commandes

L'un des avantages de l'application du format URL est qu'elle peut être mappée à une véritable adresse de votre service API, ce qui améliore la lisibilité et la reconnaissance lors de l'intégration avec d'autres composants du système.

Définir les permissions#

Étant donné que nous avons introduit le concept de ressource, dans Logto, nous imposons également que les permissions doivent appartenir à une ressource, en revanche, les ressources peuvent avoir des permissions.

Ajoutons quelques permissions aux ressources :

• Livres : lire, créer, supprimer
• Commandes : lire, lire : soi, créer : soi, supprimer

Bien qu’il n’y ait pas d’exigence sur le nom d’une permission, nous avons la convention ci-dessous :

Alors que <action> est nécessaire pour décrire une permission, :<cible> peut être ignorée pour décrire une cible générale, c'est-à-dire à toutes les entités ou articles de la ressource. Par exemple :

• La permission lire dans la ressource Livres signifie l'action de lire des livres arbitraires.
• La permission créer : soi dans la ressource Commandes signifie l'action de créer des commandes qui appartiennent à l'utilisateur actuel.

Définir les rôles#

En bref, un rôle est un groupe de permissions. Créons deux rôles client et vendeur et attribuons-leur des permissions comme suit :

Vous avez peut-être remarqué que l'attribution de la permission au rôle est en relation plusieurs à plusieurs.

Attribuer des rôles aux utilisateurs#

Tout comme l'attribution de rôles aux permissions, l'attribution de rôles aux utilisateurs est également une relation de plusieurs à plusieurs. Par conséquent, vous pouvez attribuer plusieurs rôles à un utilisateur unique, et un rôle unique peut être attribué à plusieurs utilisateurs.

Connecter les points#

Voici un diagramme de relation complet pour le modèle RBAC de niveau 1 dans Logto :

Dans le modèle RBAC, les permissions sont toujours "positives", ce qui signifie que le jugement d'autorisation est simple : si un utilisateur a la permission, alors il accepte ; sinon, il rejette.

Disons que Alice a le rôle de vendeur, Bob et Carol le rôle de client. Nous décrirons les actions en langage naturel d'abord, et les transposerons au format d'autorisation standard : IDENTITÉ effectue ACTION sur RESSOURCE, pour finalement donner la conclusion.

• Alice veut ajouter un nouveau livre à vendre :
  • L'utilisateur Alice effectue créer sur la ressource Livres (https://api.librairie.io/livres).
  • Comme Alice a été attribuée la permission créer des Livres selon leur rôle vendeur, le résultat est ✅ ACCEPTER.
• Alice veut voir toutes les commandes pour voir si la vente répond à ses attentes :
  • L'utilisateur Alice effectue lire sur la ressource Commandes (https://api.librairie.io/commandes).
  • Comme Alice a été attribué la permission lire des Commandes selon leur rôle vendeur, le résultat est ✅ ACCEPTER.
• Bob veut parcourir la liste des livres pour voir s'il y a des livres qu'il veut acheter.
  • L'utilisateur Bob effectue lire sur la ressource Livres (https://api.librairie.io/livres).
  • Comme Bob a été attribué la permission lire des Livres selon leur rôle client, le résultat est ✅ ACCEPTER.
• Bob veut voir la commande de Carol.
  • Comme c'est la commande de quelqu'un d'autre, la permission lire : soi des Commandes ne fonctionne pas ici.
  • L'utilisateur Bob effectue lire sur la ressource Commandes (https://api.librairie.io/commandes).
  • Comme Bob n'a aucune permission lire des Commandes, le résultat est ❌ REFUSER.

Autres niveaux RBAC#

Il existe quatre niveaux dans le modèle RBAC NIST :

• RBAC plat
• RBAC hiérarchique
• RBAC contraint
• RBAC symétrique

Voir le document pour plus de détails si vous êtes intéressé.

Logto a maintenant la mise en oeuvre du niveau 1 et progressera vers des niveaux supérieurs en fonction des commentaires de la communauté. N'hésitez pas à nous faire savoir si un niveau supérieur répond à vos besoins !

En pratique#

Outre la théorie, nous avons encore de nombreux travaux techniques à accomplir pour que le modèle fonctionne comme prévu :

• Développement du client et du serveur d'authentification
• Conception de la base de données pour le RBAC
• Validation à travers différents services
• Sécurité et conformité aux normes ouvertes
• Gestion des rôles, des permissions, des ressources et des attributions

Ne paniquez pas. Nous avons pris cela en compte et avons ajouté le support clé en main pour couvrir tout ce qui précède. Consultez la 🔐 recette RBAC pour apprendre comment utiliser le RBAC dans Logto.

Notes de clôture#

Le RBAC est un puissant modèle de gestion des accès pour la plupart des cas, mais il n'y a pas de solution miracle. Nous avons encore quelques questions :

• Ai-je besoin de niveaux élevés de RBAC ?
• Comment le RBAC se compare-t-il à d'autres modèles d'autorisation ?
• Comment définir le modèle d'autorisation entre différentes organisations ?