Maîtriser le RBAC dans Logto : Un exemple concret et complet
Cet article propose un guide complet sur la maîtrise du contrôle d'accès basé sur les rôles (RBAC) dans Logto, en utilisant un exemple concret d'une librairie en ligne pour explorer les rôles clés des utilisateurs, les portées et l'intégration des fonctionnalités RBAC de Logto dans les applications frontend et backend pour une sécurité et un contrôle d'accès améliorés.
SijieDeveloper
Arrêtez de perdre des semaines sur l'authentification des utilisateurs
Lancez des applications sécurisées plus rapidement avec Logto. Intégrez l'authentification des utilisateurs en quelques minutes et concentrez-vous sur votre produit principal.
Le contrôle d'accès et la sécurité sont des aspects essentiels des applications modernes, garantissant que les utilisateurs ont un accès approprié aux ressources. Le contrôle d'accès basé sur les rôles (RBAC) de Logto offre aux développeurs une manière efficace de gérer le contrôle d'accès et la sécurité dans leurs applications. Dans cet article,
ous allons explorer les fonctionnalités puissantes de l'implémentation RBAC de Logto en utilisant un exemple concret, pour vous aider à comprendre et à appliquer ces concepts à vos projets.
En examinant les extraits de code frontend et backend, vous obtiendrez une perspective complète sur l'intégration du RBAC de Logto dans votre pile d'applications. À la fin de cet article, vous serez bien équipé pour exploiter les fonctionnalités RBAC de Logto pour améliorer la sécurité et le contrôle d'accès de votre projet.
Présentation de BookHarber : Un cas d'utilisation de librairie en ligne#
Pour démontrer efficacement les fonctionnalités RBAC de Logto,
ous allons utiliser un exemple concret : BookHarber, une librairie en ligne. BookHarber offre une large gamme de fonctionnalités pour les clients et le personnel, garantissant une expérience d'achat fluide et sécurisée.
Les principales fonctionnalités de BookHarber incluent :
Parcourir et acheter des livres : Les utilisateurs peuvent facilement rechercher et acheter des livres parmi une collection diversifiée, couvrant divers genres et auteurs.
Gestion des commandes et suivi logistique : Les clients enregistrés peuvent gérer leurs commandes, suivre l'expédition et recevoir des mises à jour sur leurs achats.
Offres spéciales et activités de vacances : BookHarber propose des remises exclusives et des promotions lors d'événements spéciaux et de vacances pour engager et récompenser sa base de clients.
Support client : Les clients peuvent ouvrir des tickets de support pour résoudre tout problème ou préoccupation qu'ils pourraient rencontrer, en recevant une assistance rapide du personnel de BookHarber.
Gestion des clients : Les membres du personnel avec différents rôles ont la capacité de gérer divers aspects de la plateforme, tels que les comptes clients, le traitement des commandes et la résolution des problèmes.
Dans l'écosystème de BookHarber,
ous pouvons identifier plusieurs rôles clés d'utilisateurs, tels que :
Invité : Les utilisateurs
on enregistrés qui peuvent parcourir le site web, rechercher des livres et consulter les offres spéciales.
Client : Les utilisateurs enregistrés qui peuvent acheter des livres, gérer les commandes, suivre la logistique et ouvrir des tickets de support.
Admin du magasin : Les membres du personnel responsables de la supervision de la gestion et des opérations de la plateforme. Avec un accès complet.
Gestionnaire de livres : Les membres du personnel en charge de la gestion des livres et des catégories.
Agent de service client : Les membres du personnel chargés de répondre aux tickets de support.
Fournisseur de logistique tiers : Les partenaires externes responsables de la gestion et du suivi de l'expédition et de la livraison des commandes.
Personnel de marketing : Les membres du personnel responsables de la promotion de BookHarber, responsables de la gestion des offres spéciales et des événements.
Conception des portées pour les API REST de BookHarber#
Pour implémenter efficacement le système RBAC de Logto pour BookHarber,
ous devons concevoir des portées qui correspondent aux différentes API REST. Les portées sont des permissions qui définissent le
iveau d'accès qu'un rôle spécifique a pour chaque point de terminaison API. En attribuant les portées appropriées à chaque rôle d'utilisateur,
ous pouvons
ous assurer que les utilisateurs
'ont accès qu'aux actions et ressources pertinentes pour leur rôle.
Concevons des portées pour les API REST suivantes :
API des catégories :
create:categories : POST /categories
write:categories : PUT /categories/:id
delete:categories : DELETE /categories/:id
list:categories : GET /categories
API des livres :
create:books : POST /books
write:books : PUT /books/:id
delete:books : DELETE /books/:id
list:books : GET /books
read:books : GET /books/:id
API des clients :
list:customers : GET /customers
write:customers : PUT /customers/:id
delete:customers : DELETE /customers/:id
read:customers : GET /customers/:id
API des commandes :
create:orders : POST /orders
list:orders : GET /orders
read:orders : GET /orders/:id
write:orders : PUT /orders/:id
API des événements :
create:events : POST /events
write:events : PUT /events/:id
list:events : GET /events
delete:events : DELETE /events/:id
API de suivi des commandes :
read:orderTracks : GET /orders/:id/tracks
create:orderTracks : POST /orders/:id/tracks
write:orderTracks : PUT /orders/:id/tracks/:trackId
Maintenant que
ous avons défini les portées appropriées pour chaque API REST,
ous pouvons attribuer ces portées aux rôles d'utilisateur respectifs dans l'écosystème de BookHarber :
Portées
Invité
Client
Admin du magasin
Gestionnaire de livres
Agent de service client
Fournisseur de logistique tiers
Personnel de marketing
create:categories
✓
✓
write:categories
✓
✓
delete:categories
✓
✓
list:categories
✓
✓
✓
✓
✓
✓
✓
create:books
✓
✓
write:books
✓
✓
delete:books
✓
✓
list:books
✓
✓
✓
✓
✓
✓
✓
read:books
✓
✓
✓
✓
✓
✓
✓
list:customers
✓
✓
write:customers
✓
delete:customers
✓
read:customers
✓
✓
create:orders
✓
✓
✓
✓
✓
✓
list:orders
✓
read:orders
✓
✓
write:orders
✓
create:events
✓
✓
write:events
✓
✓
list:events
✓
✓
✓
✓
✓
✓
✓
delete:events
✓
✓
read:orderTracks
✓
✓
✓
create:orderTracks
✓
✓
write:orderTracks
✓
✓
create:tickets
✓
✓
✓
✓
✓
✓
list:tickets
✓
✓
read:tickets
✓
✓
write:tickets
✓
✓
Comprendre les différences entre les portées "list" et "read"#
Pour illustrer davantage les différences entre les portées "list" et "read" dans le cadre de la conception d'API REST et du RBAC, considérons un exemple concret impliquant une librairie en ligne, BookHarber.
Supposons que BookHarber a deux types d'utilisateurs : les clients et les agents de service client. Les clients peuvent créer des commandes, tandis que les agents de service client sont responsables d'aider les clients avec leurs commandes. Examinons comment les portées "list" et "read" s'appliquent à la ressource API orders dans ce scénario.
Portées de liste : Une portée "list" permet à l'utilisateur d'accéder à une collection d'entités dans le système. Par exemple, la portée list:orders permet à un utilisateur de récupérer une liste de toutes les commandes disponibles. Dans le contexte de BookHarber, cette portée pourrait être utile pour les administrateurs du magasin ou d'autres membres du personnel qui ont besoin d'avoir un aperçu de toutes les commandes dans le système. Cependant, les agents de service client
e devraient pas pouvoir accéder à la liste complète des commandes, car leur rôle est d'assister les clients individuels avec leurs commandes spécifiques.
Portées de lecture : Une portée "read" accorde à l'utilisateur la permission d'accéder à une seule entité avec un ID donné. Par exemple, la portée read:orders permet à l'utilisateur de consulter des informations détaillées sur une commande spécifique par son ID. Dans le cas de BookHarber, cette portée est idéale pour les agents du service client qui ont besoin d'accéder à l'information sur une commande particulière d'un client. Lorsqu'un client ouvre un ticket de support, l'agent du service client peut utiliser l'ID de commande fourni dans le ticket pour accéder et consulter les détails de cette commande spécifique.
Compréhension de la propriété : Pourquoi les clients#
'ont pas besoin de portées "read" ou "list" pour leurs propres commandes
Dans de
ombreuses applications, il est courant que les utilisateurs aient accès à leurs propres ressources sans leur accorder explicitement les portées "read" ou "list" correspondantes. C'est parce que les utilisateurs sont considérés comme les propriétaires de ces ressources et devraient
aturellement y avoir accès. Dans le cas de
otre exemple BookHarber, les clients peuvent créer des commandes mais
e possèdent pas les portées "read:orders"
i "list:orders".
Le concept de propriété joue un rôle crucial dans la définition du contrôle d'accès pour les ressources spécifiques dans une API REST. En reconnaissant que les utilisateurs peuvent toujours accéder à leurs propres ressources,
ous pouvons mettre en place un contrôle d'accès plus efficace et sécurisé sans accorder de permissions inutiles. Dans le cas de BookHarber, cela signifie que les clients peuvent toujours voir et gérer leurs commandes sans avoir besoin de portées supplémentaires.
Pour démontrer comment cela fonctionne, considérons le point de terminaison GET /orders :
Si un utilisateur a la portée list:orders (par exemple, les administrateurs du magasin ou les membres du personnel), ils pourront voir toutes les commandes dans le système. Cela leur donne une vue complète des données de commande
écessaires pour leur rôle.
Si un utilisateur
'a pas la portée list:orders (par exemple, les clients réguliers), le système
e renverra que les commandes qui appartiennent à l'utilisateur. Cela garantit que les clients peuvent toujours accéder à leurs informations de commande sans se voir accorder des autorisations inutiles.
En mettant en œuvre ce contrôle d'accès basé sur la propriété, l'API peut fournir le
iveau d'accès approprié à différents rôles d'utilisateurs tout en maintenant la sécurité et une expérience utilisateur adaptée. Dans le scénario de BookHarber, le modèle de propriété permet aux clients d'accéder à leurs informations de commande sans besoin des portées "read:orders" ou "list:orders", simplifiant ainsi la conception du contrôle d'accès et améliorant l'expérience utilisateur globale.
Configuration des paramètres dans la console Logto#
Pour terminer la configuration dans la console de Logto, suivez ces étapes :
Créer une application monopage (SPA) pour React : Configurer une SPA dans la console de Logto pour votre application React.
Créer une ressource API : Ajouter une
ouvelle ressource API avec l'identifiant https://api.bookharber.com.
Définir les portées pour la ressource : Créer les portées
écessaires sous la
ouvelle ressource API créée.
Créer des rôles et attribuer des portées : Définir les rôles d'utilisateur pour votre application, et attribuer les portées appropriées à chaque rôle.
Attribuer des rôles aux utilisateurs : Attribuer les rôles pertinents aux utilisateurs de votre application, en garantissant que chaque utilisateur (en particulier les membres du personnel) dispose des bonnes permissions en fonction de leur rôle.
Dans
otre projet d'exemple, BookHarber,
ous utilisons Express pour le service backend et React pour la page web frontend. Cette section fournira un aperçu de la manière dont
ous pouvons intégrer les fonctionnalités RBAC de Logto dans ces technologies populaires pour sécuriser
otre application.
Le système RBAC de Logto est un outil puissant pour gérer le contrôle d'accès et la sécurité dans les applications modernes. En utilisant les fonctionnalités RBAC de Logto, vous pouvez vous assurer que les utilisateurs ont un accès approprié aux ressources en fonction de leurs rôles, en protégeant les données sensibles et les fonctionnalités contre l'accès
on autorisé.
Dans cet article,
ous avons exploré un exemple concret d'une librairie en ligne, BookHarber, et montré comment concevoir des portées, les attribuer à des rôles d'utilisateur, et mettre en œuvre les fonctionnalités RBAC de Logto dans le frontend et le backend de l'application.
En appliquant ces concepts et techniques à vos projets, vous pouvez améliorer la sécurité et le contrôle d'accès de vos applications, en offrant une expérience utilisateur fluide et sécurisée. Que vous travailliez sur une plateforme de commerce électronique, un système de gestion de contenu, ou tout autre projet
écessitant un contrôle d'accès basé sur les rôles, le système RBAC de Logto offre une solution flexible et efficace pour répondre à vos besoins de contrôle d'accès.
