Exemples de cas d'utilisation : contrôle d’accès basé sur les rôles

Découvrez comment mettre en œuvre le contrôle d’accès basé sur les rôles (RBAC) dans différents scénarios et comment utiliser les Rules avec le RBAC.

Examinons un exemple pour voir pourquoi vous pourriez avoir besoin du contrôle d’accès basé sur les rôles (RBAC) et comment vous pourriez l’utiliser dans votre flux d’autorisation.

Supposons que vous êtes une entreprise qui fournit un logiciel-service interentreprises à des organismes sans but lucratif. Votre produit permet à ces organismes de créer, gérer et commercialiser des produits auprès de donateurs potentiels. Votre application contient plusieurs modules distincts, dont les deux suivants :

• un module de point de vente (POS) pour boutique-cadeaux qui permet aux organismes sans but lucratif de créer efficacement des boutiques éphémères de t-shirts et de gérer leurs ventes.
• un module de marketing qui permet aux organismes sans but lucratif de créer et de distribuer des infolettres à leurs donateurs.

Vous souhaitez utiliser Auth0 pour contrôler l’accès de vos clients sans but lucratif aux différentes parties de votre application. Sans RBAC, tous les employés et bénévoles de ces organismes auraient accès à toutes les fonctionnalités de votre application, ce qui n’est pas idéal, surtout si l’un d’eux est un refuge animalier qui compte des bénévoles aux connaissances limitées au domaine dans lequel ils font du bénévolat.

Vous mettez donc en œuvre le RBAC en créant certaines autorisations dont les utilisateurs de votre module POS de boutique-cadeaux auraient besoin :

• read:catalog-item
• read:customer-profile
• create:invoice

Et pour en faciliter la gestion, vous créez un rôle nommé 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, notamment :

• create:newsletter
• edit:newsletter
• delete:newsletter
• send:newsletter
• edit:distribution-list

Et vous créez un rôle nommé Newsletter Admin et y ajoutez ces autorisations.

Ainsi, lorsque votre refuge animalier confie à sa bénévole, Astrid, la gestion de sa boutique éphémère de t-shirts, Astrid peut se voir attribuer le rôle Gift Shop Manager. Lorsque vous attribuez ce rôle à Astrid, toutes les autorisations associées à ce rôle lui sont accordées. Comme Astrid ne connaît rien à la publication d’infolettres (et n’est pas très à l’aise avec le courriel), vous ne lui avez jamais attribué le rôle Newsletter Admin, donc elle n’a pas accès au module de marketing.

D’un point de vue plus technique, lorsque Astrid se connecte à votre produit, Auth0 l’authentifie et l’autorise, puis inclut les autorisations dans le Jeton d’accès renvoyé. Votre produit inspecte ensuite le jeton pour déterminer quel module afficher à Astrid.

En utilisant le RBAC d’Auth0, vous évitez de créer et de maintenir des systèmes d’autorisation distincts; vous utilisez plutôt le jeton que vous recevez déjà pendant le processus d’autorisation. Et lorsqu’Astrid déménage ou décide qu’elle en a assez de gérer la boutique-cadeaux et préfère coordonner le programme de familles d’accueil, vous pouvez facilement lui retirer le rôle Gift Shop Manager et lui attribuer un nouveau rôle.

Et si la gestion des rôles et des autorisations pour l’ensemble de vos clients devient trop complexe, vous pouvez également utiliser l’API Auth0 pour créer un module dans votre produit permettant aux clients de gérer leur propre RBAC, réduisant ainsi la responsabilité et les coûts en personnel.