## Contexte Dans [l'article précédent](/ciam-101-intro-authn-sso/), 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 ? L'autorisation (AuthZ) répond à la question “Que pouvez-vous faire ?” 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](https://csrc.nist.gov/CSRC/media/Publications/conference-paper/2000/07/26/the-nist-model-for-role-based-access-control-towards-a-unified-/documents/sandhu-ferraiolo-kuhn-00.pdf) Niveau 1 : Flat RBAC. ## Contrôle d'accès basé sur les rôles Le modèle RBAC NIST a laissé de nombreuses choses ouvertes pour fournir de la flexibilité et de l'adaptabilité pour divers scénarios. Logto adopte maintenant la définition de niveau 1 avec un concept supplémentaire "Ressource" (c'est-à-dire API Resource). É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. 🤔 Les ressources doivent être divisées en fonction des besoins de l'entreprise. Il n'y a pas de approche universelle ; la décision doit être prise au cas par cas. L'exemple dans cet article qui divise les livres et les commandes peut convenir pour les microservices, mais pas pour une architecture monolithique. ### 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 `` est nécessaire pour décrire une permission, `:` 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 : ```mermaid erDiagram Role-Client { permission Livres "lire" permission Commandes "lire : soi" permission Commandes "créer : soi" } Role-Vendeur { permission Livres "lire" permission Livres "créer" permission Livres "supprimer" permission Commandes "lire" permission Commandes "supprimer" } ``` 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 : ```mermaid erDiagram Utilisateur }|--|{ Role : maps Role }|--|{ Permission : maps "API Resource" ||--|{ Permission : contains ``` 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](https://csrc.nist.gov/CSRC/media/Publications/conference-paper/2000/07/26/the-nist-model-for-role-based-access-control-towards-a-unified-/documents/sandhu-ferraiolo-kuhn-00.pdf) 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](https://docs.logto.io/docs/recipes/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 ? 🔥 Restez à l'écoute. On se retrouve dans CIAM 103 !