Pour un modèle d’autorisation plus robuste, consultez Autorisation à granularité fine (FGA) pour l’autorisation basée sur les attributs et les relations.
Avantages du RBAC
Avec le RBAC, vous pouvez gérer les accès plus facilement, à condition de respecter à la lettre les exigences en matière de rôle. Le RBAC vous aide à :- créer une attribution systématique et reproductible des autorisations
- auditer facilement les privilèges des utilisateurs et à corriger les problèmes identifiés
- ajouter et modifier rapidement des rôles, ainsi qu’à les implémenter dans les API
- réduire les risques d’erreur lors de l’attribution des autorisations aux utilisateurs
- intégrer des utilisateurs tiers en leur attribuant des rôles prédéfinis
- mieux respecter les exigences réglementaires et légales en matière de confidentialité et de respect de la vie privée
Modèle RBAC
Rôles
Fondamentalement, un rôle est un ensemble d’autorisations que vous pouvez appliquer aux utilisateurs. L’utilisation de rôles facilite l’ajout, la suppression et l’ajustement des autorisations par rapport à l’attribution individuelle d’autorisations aux utilisateurs. Au fur et à mesure que votre base d’utilisateurs augmente en taille et en complexité, les rôles deviennent particulièrement utiles. Vous pouvez également utiliser les rôles pour collecter les autorisations définies pour diverses API. Par exemple, supposons que votre module de marketing permette aux utilisateurs de créer et distribuer des bulletins d’information à leurs clients. Votre spécialiste du contenu marketing crée tous les bulletins d’information et les prépare pour la distribution. De même, vous disposez d’un module d’événements qui permet aux utilisateurs de créer, de publier et de gérer l’inscription à des événements. Votre coordonnateur d’événements crée les événements. Une fois que le vice-président chargé du marketing a approuvé les bulletins d’information et les événements, son assistant publie les événements et distribue les bulletins d’information. Dans ce cas, votre API de bulletin d’information pourrait avoir une autorisationdistribute:newsletters
et votre API d’événements pourrait avoir une autorisation publish:events
. Ces autorisations pourraient ensuite être regroupées dans un rôle appelé Marketing Publisher
et affectées à l’assistant du vice-président du marketing.
En outre, des rôles spécifiques à l’organization peuvent être ajoutés aux membres de l’organization et utilisés pour autoriser l’accès dans votre application en fonction des organizations avec lesquelles un utilisateur final se connecte. Cela est particulièrement utile lors de la prise en charge de produits multi-locataires et SaaS, où un utilisateur particulier peut avoir un rôle privilégié dans une organization, mais pas dans d’autres.
Chevauchement des attributions de rôles
Le modèle RBAC est un modèle additif, par conséquent, si vos attributions de rôles se chevauchent, vos autorisations effectives correspondent à la somme de vos attributions de rôles. Par exemple, supposons que vous disposiez d’une API qui fournit des données pour une application événementielle. Vous créez un rôleOrganisateur
et lui attribuez des autorisations qui lui permettent de visualiser, créer et modifier des événements. Vous créez également un rôle de Titulaire de l’enregistrement
et lui attribuez des autorisations qui lui permettent d’afficher et de s’inscrire pour les événements. Tous les utilisateurs ayant des rôles Organisateur)
et Titulaire de l’enregistrement
pourront afficher, créer, modifier et s’inscrire aux événements.
Le contrôle d’accès basé sur les rôles (RBAC) dans Auth0
Actuellement, nous offrons actuellement deux façons d’intégrer le contrôle d’accès basé sur les rôles (RBAC) en remplacement ou en complément du système de contrôle d’accès intégré de votre API : Nous sommes en train d’étendre les fonctionnalités d’Authorization Core afin de les adapter à celles d’Authorization Extension. Notre nouvelle implémentation RBAC de base améliore les performances et l’évolutivité et fournira à terme un système RBAC plus flexible qu’Authorization Extension. Actuellement, les deux implémentent les fonctionnalités clés de RBAC et vous permettent de restreindre les permissions personnalisées définies pour une API à celles qui ont été attribuées à l’utilisateur en tant que permissions. Pour une comparaison, voir Authorization Core par rapport à Authorization Extension.L’ensemble des fonctionnalités de Authorization Core et Authorization Extension sont des fonctionnalités entièrement distinctes. Pour gérer les groupes, les rôles ou les autorisations, vous devez utiliser la fonctionnalité dans laquelle ils ont été créés à l’origine.
Bien que Delegated Administration Extension (DAE) (Extension d’administration déléguée) et l’ensemble de fonctionnalités Authorization Core soient des fonctionnalités complètement distinctes, vous pouvez utiliser l’ensemble de fonctionnalités Authorization Core pour créer et gérer des rôles pour la DAE à l’aide d’actions. Pour en savoir plus, consultez Exemples de cas d’utilisation : actions avec Authorization.