Padroneggiare RBAC in Logto: Un esempio completo del mondo reale
Questo articolo offre una guida completa su come padroneggiare il controllo degli accessi basato sui ruoli (RBAC) in Logto, utilizzando un esempio del mondo reale di una libreria online per esplorare i ruoli degli utenti chiave, le aree di competenza e l'integrazione delle funzionalità RBAC di Logto
elle applicazioni frontend e backend per una sicurezza e un controllo degli accessi migliorati.
SijieDeveloper
Smetti di sprecare settimane sull'autenticazione degli utenti
Lancia app sicure più velocemente con Logto. Integra l'autenticazione degli utenti in pochi minuti e concentrati sul tuo prodotto principale.
Il controllo degli accessi e la sicurezza sono aspetti essenziali delle applicazioni moderne, garantendo che gli utenti abbiano accesso appropriato alle risorse. Il controllo degli accessi basato sui ruoli (RBAC) di Logto offre agli sviluppatori un modo efficiente per gestire il controllo degli accessi e la sicurezza
elle loro applicazioni. In questo articolo, esploreremo le potenti caratteristiche dell'implementazione RBAC di Logto utilizzando un esempio del mondo reale, aiutandoti a capire e applicare questi concetti ai tuoi progetti.
Esaminando sia i frammenti di codice frontend che backend, otterrai una prospettiva completa sull'integrazione del RBAC di Logto
el tuo stack di applicazioni. Alla fine di questo articolo, sarai ben attrezzato per sfruttare le funzionalità RBAC di Logto per migliorare la sicurezza e il controllo degli accessi del tuo progetto.
Presentazione di BookHarber: Un caso d'uso della libreria online#
Per dimostrare efficacemente le funzionalità RBAC di Logto, utilizzeremo un esempio del mondo reale: BookHarber, una libreria online. BookHarber offre una vasta gamma di funzionalità per i clienti e il personale, garantendo un'esperienza di acquisto fluida e sicura.
Le caratteristiche chiave di BookHarber includono:
Navigazione e Acquisto di Libri: gli utenti possono facilmente cercare e acquistare libri da una collezione diversificata, che copre vari generi e autori.
Gestione degli Ordini e Tracciamento della Logistica: i clienti registrati possono gestire i loro ordini, monitorare la spedizione e ricevere aggiornamenti sui loro acquisti.
Offerte Speciali e Attività Festive: BookHarber offre sconti esclusivi e promozioni durante eventi speciali e festività per coinvolgere e premiare la sua base di clienti.
Assistenza Clienti: i clienti possono aprire ticket di supporto per affrontare eventuali preoccupazioni o problemi che possono incontrare, ricevendo pronta assistenza dal personale di BookHarber.
Gestione dei Clienti: i membri del personale con ruoli diversi hanno la capacità di gestire vari aspetti della piattaforma, come gli account dei clienti, l'elaborazione degli ordini e la risoluzione dei problemi.
Nell'ecosistema BookHarber, possiamo identificare diversi ruoli utente chiave, come:
Ospite: Utenti
on registrati che possono
avigare
el sito web, cercare libri e visualizzare offerte speciali.
Cliente: Utenti registrati che possono acquistare libri, gestire ordini, monitorare la logistica e aprire ticket di supporto.
Amministratore del Negozio: Membri dello staff responsabili della supervisione della gestione e delle operazioni della piattaforma. Con accesso completo.
Gestore Libri: Membri dello staff incaricati della gestione dei libri e delle categorie.
Agente di Servizio Clienti: Membri dello staff incaricati di rispondere ai ticket di supporto.
Fornitore di Logistica di Terze Parti: Partner esterni responsabili della gestione e del tracciamento della spedizione e della consegna degli ordini.
Personale di Marketing: Membri dello staff responsabili della promozione di BookHarber, responsabili della gestione di offerte speciali e eventi.
Progettazione delle aree di competenza per le REST API di BookHarber#
Per implementare efficacemente il sistema RBAC di Logto per BookHarber, dobbiamo progettare aree di competenza che corrispondano alle varie REST API. Le aree di competenza sono permessi che definiscono il livello di accesso che un ruolo specifico ha per ogni endpoint API. Assegnando le aree di competenza appropriate a ciascun ruolo utente, possiamo garantire che gli utenti abbiano solo accesso alle azioni e alle risorse pertinenti al loro ruolo.
Progettiamo le aree di competenza per le seguenti REST API:
API delle Categorie:
create:categories: POST /categorie
write:categories: PUT /categorie/:id
delete:categories: DELETE /categorie/:id
list:categories: GET /categorie
API dei Libri:
create:books: POST /libri
write:books: PUT /libri/:id
delete:books: DELETE /libri/:id
list:books: GET /libri
read:books: GET /libri/:id
API dei Clienti:
list:customers: GET /clienti
write:customers: PUT /clienti/:id
delete:customers: DELETE /clienti/:id
read:customers: GET /clienti/:id
API degli Ordini:
create:orders: POST /ordini
list:orders: GET /ordini
read:orders: GET /ordini/:id
write:orders: PUT /ordini/:id
API degli Eventi:
create:events: POST /eventi
write:events: PUT /eventi/:id
list:events: GET /eventi
delete:events: DELETE /eventi/:id
API dei Tracciamenti degli Ordini:
read:orderTracks: GET /ordini/:id/tracciamenti
create:orderTracks: POST /ordini/:id/tracciamenti
write:orderTracks: PUT /ordini/:id/tracciamenti/:trackId
Ora che abbiamo definito le aree di competenza appropriate per ciascuna REST API, possiamo assegnare queste aree di competenza ai rispettivi ruoli utente
ell'ecosistema BookHarber:
Aree di Competenza
Ospite
Cliente
Amministratore del Negozio
Gestore Libri
Agente di Servizio Clienti
Fornitore di Logistica di Terze Parti
Personale di 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
✓
✓
Comprendere le differenze tra "list" e "read" scope#
Per illustrare ulteriormente le differenze tra le aree di competenza "list" e "read"
el contesto della progettazione delle REST API e di RBAC, consideriamo un esempio del mondo reale che coinvolge una libreria online, BookHarber.
Supponiamo che BookHarber abbia due tipi di utenti: clienti e agenti di servizio clienti. I clienti possono creare ordini, mentre gli agenti di servizio clienti sono responsabili di aiutare i clienti con i loro ordini. Diamo un'occhiata a come si applicano le aree di competenza "list" e "read" alla risorsa API orders in questo scenario.
Aree di Competenza "List": Un'area di competenza "list" consente all'utente di accedere a una collezione di entità
el sistema. Ad esempio, l'area di competenza list:orders permette a un utente di recuperare un elenco di tutti gli ordini disponibili. Nel contesto di BookHarber, questa area di competenza potrebbe essere utile per gli amministratori del
egozio o altri membri dello staff che hanno bisogno di avere una panoramica di tutti gli ordini
el sistema. Tuttavia, gli agenti di servizio clienti
on dovrebbero essere in grado di accedere all'intero elenco di ordini, poiché il loro ruolo è quello di assistere i singoli clienti con i loro ordini specifici.
Aree di Competenza "Read": Un'area di competenza "read" concede all'utente il permesso di accedere a una singola entità con un dato ID. Ad esempio, l'area di competenza read:orders consente all'utente di visualizzare informazioni dettagliate su un ordine specifico per il suo ID. Nel caso di BookHarber, questa area di competenza è ideale per gli agenti di servizio clienti che hanno bisogno di accedere alle informazioni su un particolare ordine del cliente. Quando un cliente apre un ticket di supporto, l'agente di servizio clienti può utilizzare l'ID dell'ordine fornito
el ticket per accedere e visualizzare i dettagli di quell'ordine specifico.
on hanno bisogno di aree di competenza "read" o "list" per i loro ordini
In molte applicazioni, è comune che gli utenti abbiano accesso alle loro risorse senza concedere loro esplicitamente le corrispondenti aree di competenza "read" o "list". Questo perché gli utenti sono considerati i proprietari di queste risorse e dovrebbero
aturalmente avere accesso ad esse. Nel caso del
ostro esempio BookHarber, i clienti possono creare ordini, ma
on possiedono le aree di competenza "read:orders" o "list:orders".
Il concetto di proprietà gioca un ruolo cruciale
ella definizione del controllo degli accessi per risorse specifiche in una REST API. Riconoscendo che gli utenti possono sempre accedere alle loro risorse, possiamo implementare un controllo degli accessi più efficiente e sicuro senza concedere permessi inutili. Nel caso di BookHarber, ciò significa che i clienti possono comunque visualizzare e gestire i loro ordini senza bisogno di aree di competenza aggiuntive.
Per dimostrare come funziona, prendiamo in considerazione l'endpoint GET /orders:
Se un utente ha l'area di competenza list:orders (ad es., gli amministratori del
egozio o i membri dello staff), sarà in grado di visualizzare tutti gli ordini
el sistema. Questo gli fornisce una visione completa dei dati degli ordini
ecessari per il loro ruolo.
Se un utente
on ha l'area di competenza list:orders (ad es., i clienti regolari), il sistema restituirà solo gli ordini che appartengono all'utente. Ciò garantisce che i clienti possano ancora accedere alle loro informazioni sull'ordine senza essere concessi i permessi inutili.
Implementando questo controllo degli accessi basato sulla proprietà, l'API può fornire il livello appropriato di accesso a diversi ruoli utente mantenendo la sicurezza e un'esperienza utente su misura. Nello scenario di BookHarber, il modello di proprietà consente ai clienti di accedere alle loro informazioni sull'ordine senza la
ecessità delle aree di competenza "read:orders" o "list:orders", semplificando la progettazione del controllo degli accessi e migliorando l'esperienza utente complessiva.
Per completare la configurazione
ella console di Logto, segui questi passaggi:
Crea una singola applicazione Pagina (SPA) per React: Configura un SPA
ella console di Logto per la tua applicazione React.
Crea una risorsa API: Aggiungi una
uova risorsa API con l'identificatore https://api.bookharber.com.
Definire le aree di competenza per la risorsa: Crea le aree di competenza
ecessarie sotto la
uova risorsa API creata.
Creare ruoli e assegnare aree di competenza: Definisci i ruoli utente per la tua applicazione e assegna le aree di competenza appropriate a ciascun ruolo.
Assegna ruoli agli utenti: Assegna i ruoli pertinenti agli utenti
ella tua applicazione, garantendo che ciascun utente (soprattutto il personale) abbia le autorizzazioni corrette in base al loro ruolo.
Nel
ostro progetto di esempio, BookHarber, utilizziamo Express per il servizio backend e React per la pagina web frontend. Questa sezione fornirà una breve panoramica di come possiamo integrare le caratteristiche RBAC di Logto in queste tecnologie popolari per proteggere la
ostra applicazione.
Il sistema RBAC di Logto è uno strumento potente per la gestione del controllo degli accessi e della sicurezza
elle applicazioni moderne. Sfruttando le caratteristiche RBAC di Logto, puoi garantire che gli utenti abbiano un accesso appropriato alle risorse in base ai loro ruoli, proteggendo dati e funzionalità sensibili da accessi
on autorizzati.
In questo articolo, abbiamo esplorato un esempio del mondo reale di una libreria online, BookHarber, e abbiamo dimostrato come progettare aree di competenza, assegnarle a ruoli utente e implementare le caratteristiche RBAC di Logto sia
el frontend che
el backend dell'applicazione.
Applicando questi concetti e tecniche ai tuoi progetti, puoi migliorare la sicurezza e il controllo degli accessi delle tue applicazioni, offrendo un'esperienza utente fluida e sicura. Che tu stia lavorando su una piattaforma di e-commerce, un sistema di gestione dei contenuti o qualsiasi altro progetto che richieda un controllo degli accessi basato sui ruoli, il sistema RBAC di Logto offre una soluzione flessibile ed efficiente per soddisfare le tue esigenze di controllo degli accessi.
