Aller au contenu principal

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

Le contrôle d’accès basé sur les rôles (RBAC) est une méthode d'attribution de Permissions aux utilisateurs en fonction de leurs Rôles. Envisagez d'utiliser le RBAC dans les scénarios suivants :

  • Vous avez plusieurs utilisateurs avec des besoins d'accès différents : Le RBAC est idéal lorsque les utilisateurs ont besoin de Permissions variées en fonction des Rôles, tels que administrateur, éditeur ou spectateur.
  • Vous devez simplifier la gestion des Permissions : Il est efficace pour gérer de grands groupes d'utilisateurs en attribuant des Rôles plutôt qu'en définissant des Permissions individuellement.
  • Votre application dessert différents départements ou équipes : Il est utile dans les scénarios où différents groupes nécessitent des niveaux d'accès distincts aux ressources.

Comprendre comment fonctionne le contrôle d’accès basé sur les rôles

Permissions (Portées)

Permission fait référence à l'Autorisation (Authorization) d'accéder à une [ressource API]. Dans le monde réel, des entités telles que les commandes, les produits et les documents peuvent être désignées comme des ressources, et diverses actions peuvent être attribuées.

Exemples de Permissions, y compris la capacité de modifier une commande, lire un document et supprimer un produit, sont les suivants :

  • write:orders
  • read:documents
  • delete:products
Permissions

La figure ci-dessus montre que la Permission read:item dans la ressource https://api-1.store.io est différente de la Permission read:item dans la ressource https://api-2.store.io.

Si aucune ressource API n'est fournie, la Permission sera considérée comme "pour OIDC". Habituellement, ce n'est pas ce que vous voulez dans le RBAC.

Rôles

Les Rôles sont un regroupement de Permissions qui peuvent être attribuées aux utilisateurs. Ils fournissent également un moyen d'agréger les Permissions définies pour différentes APIs, rendant l'ajout, la suppression ou l'ajustement des Permissions plus efficace que de les attribuer individuellement aux utilisateurs.

Voici un exemple de Rôle order_admin avec plusieurs Permissions pour deux ressources :

Order Admin Role

Il est acceptable d'avoir un chevauchement de Permissions entre les Rôles.

Exemple : Une librairie en ligne

Disons que vous avez une librairie en ligne à gérer. Ici, nous simplifions grandement le modèle de contrôle d'accès à des fins de démonstration.

Le modèle est divisé en deux grandes Ressources API (Ressources API) : commandes et produits. Ils ont différents indicateurs de ressource comme ci-dessous :

  • Commandes : https://api.store.io/orders
  • Produits : https://api.store.io/products

Pour chaque ressource, vous souhaitez séparer les Permissions en lecture, écriture et suppression. Vous définissez donc six Permissions au total :

  • https://api.store.io/orders
    • Permission read:order
    • Permission write:order
    • Permission delete:order
  • https://api.store.io/products
    • Permission read:product
    • Permission write:product
    • Permission delete:product

Voici l'illustration de ce modèle :

Bookstore API and Permissions

Vous souhaitez avoir deux types d'administrateurs, administrateur des commandes et administrateur des produits :

  • Administrateur des commandes peut gérer les commandes et voir les produits (car les commandes se composent de produits), mais ne peut pas gérer les produits.
  • Administrateur des produits peut gérer les produits, et ils ne devraient pas être au courant de toutes les commandes.

Vous créez donc deux Rôles, order_admin et product_admin, avec les Permissions :

  • order_admin
    • https://api.store.io/orders
      • read:order, write:order, delete:order
    • https://api.store.io/products
      • read:product
  • product_admin
    • https://api.store.io/products
      • read:product, write:product, delete:product

Voici l'illustration de ces deux Rôles :

Bookstore Roles

Il est acceptable d'attribuer à la fois order_admin et product_admin à un utilisateur, puis ils auront toutes les six Permissions que vous venez de définir.

Notez que l'administrateur des commandes partage la Permission read:product avec l'administrateur des produits, et les Permissions finales qu'un utilisateur détient sont l'union de toutes les Permissions des Rôles qui lui ont été attribués.