Skip to main content
Voyons un exemple de pourquoi vous pourriez avoir besoin du contrôle d’accès basé sur les rôles (RBAC) et de la façon dont vous pourriez l’utiliser dans votre . Supposons que vous soyez une entreprise qui offre 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, 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 voulez utiliser Auth0 pour contrôler l’accès de vos clients sans but lucratif aux différentes parties de votre application. Sans le RBAC, tous les employés et bénévoles de ces organismes auront 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 pour animaux comptant plusieurs bénévoles qui ne connaissent que le secteur dans lequel ils font du bénévolat. Vous mettez donc en œuvre le RBAC en créant certaines permissions dont les utilisateurs de votre module de POS pour boutique-cadeaux auraient besoin :
  • read:catalog-item
  • read:customer-profile
  • create:invoice
Et pour en faciliter la gestion, vous créez un rôle appelé Gift Shop Manager et ajoutez ces permissions à ce rôle. De même, vous créez des permissions 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 appelé Newsletter Admin et vous y ajoutez ces permissions. Ainsi, lorsque votre refuge pour animaux fait appel à sa bénévole, Astrid, pour gérer 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 permissions attribuées à ce rôle lui sont accordées. Comme Astrid n’y connaît rien en 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; elle n’a donc jamais accès au module de marketing. D’un point de vue plus technique, quand Astrid se connecte à votre produit, Auth0 l’authentifie et l’autorise, puis inclut les permissions dans le retourné. Ensuite, votre produit inspecte le token pour déterminer quel module afficher à Astrid. En utilisant le RBAC d’Auth0, vous évitez de devoir créer et maintenir des systèmes d’autorisation distincts; vous utilisez plutôt le token que vous recevez déjà pendant l’autorisation. Et quand Astrid déménage ou décide qu’elle est fatiguée de gérer la boutique-cadeaux et qu’elle préférerait coordonner le programme de familles d’accueil, vous pouvez facilement retirer le rôle Gift Shop Manager de son compte et lui attribuer un nouveau rôle. Et si la gestion des rôles et des permissions pour tous vos clients devient trop lourde, vous pouvez aussi utiliser l’Auth0 API pour créer un module dans votre produit qui permet aux clients de gérer eux-mêmes leur RBAC, ce qui réduit la responsabilité et les coûts de personnel.