Exemples de cas d’utilisation : Contrôle d'accès basé sur les rôles (RBAC)
Examinons un exemple des raisons pour lesquelles vous pourriez avoir besoin du contrôle d'accès basé sur les rôles (RBAC) dans votre flux d’autorisation et comment vous pourriez l’utiliser.
Supposons que vous soyez une entreprise qui fournit un logiciel-service interentreprises à des organizations à but non lucratif. Votre produit permet aux organizations à but non lucratif de créer, de gérer et de commercialiser des produits auprès de donateurs potentiels. Votre application contient plusieurs modules différents, dont deux sont :
Un module de point de vente pour les boutiques de cadeaux, qui permet aux organisations à but non lucratif de créer efficacement des boutiques de t-shirts et de gérer leurs ventes.
Un module de marketing qui permet aux associations de créer et de distribuer des lettres d’information à leurs donateurs.
Vous souhaitez utiliser Auth0 pour contrôler l’accès de vos clients à but non lucratif aux différentes parties de votre application. Sans autorisation basée sur les rôles, tous les employés et bénévoles de l’association auront accès à toutes les fonctionnalités de votre application, ce qui n’est pas idéal, d’autant plus que l’une d’entre elles est un refuge pour animaux qui dispose d’une grande variété de bénévoles ne connaissant que le domaine dans lequel ils sont bénévoles.
Au lieu de cela, vous mettez en œuvre l’autorisation basée sur les rôles, en créant quelques permissions dont les utilisateurs de votre module de point de vente de boutique de cadeaux auront besoin :
read:catalog-itemread:customer-profilecreate:invoice
Pour faciliter la gestion de ces autorisations, vous créez un rôle appelé Gift Shop Manager et ajoutez ces autorisations à ce rôle.
De même, vous créez des autorisations pour les utilisateurs de votre module de marketing, qui comprennent :
create:newsletteredit:newsletterdelete:newslettersend:newsletteredit:distribution-list
Vous créez un rôle appelé Newsletter Admin et ajoutez ces autorisations à ce rôle.
Lorsque votre association de protection des animaux fait appel à une bénévole (Astrid) pour gérer sa boutique de t-shirts, Astrid peut se voir attribuer le rôle de Gift Shop Manager. Lorsque vous attribuez ce rôle à Astrid, elle se voit accorder toutes les autorisations que vous avez attribuées au rôle. Comme Astrid ne s’y connait pas beaucoup en lettres d’information (et qu’elle n’est pas très douée pour le courriel), vous ne lui avez jamais attribué le rôle Newsletter Admin, de sorte qu’elle n’a jamais accès au module de marketing.
D’un point de vue plus technique, lorsqu’Astrid se connecte à votre produit, Auth0 l’authentifie et l’autorise et inclut les permissions dans le jeton d’accès renvoyé. Ensuite, votre produit inspecte le jeton pour savoir quel module afficher à Astrid.
En utilisant le système d’autorisation basée sur les rôles d’Auth0, vous évitez de créer et de maintenir des systèmes d’autorisation distincts; au lieu de cela, vous utilisez le jeton que vous recevez lors de l’autorisation. Et lorsqu’Astrid déménage ou décide qu’elle en a assez de gérer la boutique de cadeaux et préfère coordonner le programme d’accueil, vous pouvez facilement lui retirer le rôle de Gift Shop Manager et lui attribuer un nouveau rôle.
Et si la gestion des rôles et des autorisations de tous vos clients devient trop lourde, vous pouvez également utiliser l’API Auth0 pour créer un module au sein de votre produit qui permet aux clients de gérer leur propre autorisation basée sur les rôles, réduisant ainsi la responsabilité et les coûts de personnel.