Padroneggiare RBAC in Logto: Un esempio completo del mondo reale

Introduzione#

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:

1. Navigazione e Acquisto di Libri: gli utenti possono facilmente cercare e acquistare libri da una collezione diversificata, che copre vari generi e autori.
2. Gestione degli Ordini e Tracciamento della Logistica: i clienti registrati possono gestire i loro ordini, monitorare la spedizione e ricevere aggiornamenti sui loro acquisti.
3. 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.
4. 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.
5. 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.

Ruoli#

Nell'ecosistema BookHarber, possiamo identificare diversi ruoli utente chiave, come:

1. Ospite: Utenti on registrati che possono avigare el sito web, cercare libri e visualizzare offerte speciali.
2. Cliente: Utenti registrati che possono acquistare libri, gestire ordini, monitorare la logistica e aprire ticket di supporto.
3. Amministratore del Negozio: Membri dello staff responsabili della supervisione della gestione e delle operazioni della piattaforma. Con accesso completo.
4. Gestore Libri: Membri dello staff incaricati della gestione dei libri e delle categorie.
5. Agente di Servizio Clienti: Membri dello staff incaricati di rispondere ai ticket di supporto.
6. Fornitore di Logistica di Terze Parti: Partner esterni responsabili della gestione e del tracciamento della spedizione e della consegna degli ordini.
7. 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:

1. API delle Categorie:
   • create:categories: POST /categorie
   • write:categories: PUT /categorie/:id
   • delete:categories: DELETE /categorie/:id
   • list:categories: GET /categorie
2. 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
3. API dei Clienti:
   • list:customers: GET /clienti
   • write:customers: PUT /clienti/:id
   • delete:customers: DELETE /clienti/:id
   • read:customers: GET /clienti/:id
4. API degli Ordini:
   • create:orders: POST /ordini
   • list:orders: GET /ordini
   • read:orders: GET /ordini/:id
   • write:orders: PUT /ordini/:id
5. API degli Eventi:
   • create:events: POST /eventi
   • write:events: PUT /eventi/:id
   • list:events: GET /eventi
   • delete:events: DELETE /eventi/:id
6. API dei Tracciamenti degli Ordini:
   • read:orderTracks: GET /ordini/:id/tracciamenti
   • create:orderTracks: POST /ordini/:id/tracciamenti
   • write:orderTracks: PUT /ordini/:id/tracciamenti/:trackId
7. API dei Ticket:
   • create:tickets: POST /tickets
   • list:tickets: GET /tickets
   • read:tickets: GET /tickets/:id
   • write:tickets: PUT /tickets/:id

Assegnazione delle aree di competenza ai ruoli#

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:

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.

1. 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.
2. 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.

Comprendere la proprietà: Perché i clienti#

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:

1. 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.
2. 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.

Configurazione delle impostazioni#

ella console Logto

Per completare la configurazione ella console di Logto, segui questi passaggi:

1. Crea una singola applicazione Pagina (SPA) per React: Configura un SPA ella console di Logto per la tua applicazione React.
2. Crea una risorsa API: Aggiungi una uova risorsa API con l'identificatore https://api.bookharber.com.
3. Definire le aree di competenza per la risorsa: Crea le aree di competenza ecessarie sotto la uova risorsa API creata.
4. 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.
5. 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.

Proteggi l'API utilizzando aree di competenza#

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 documento completo: https://docs.logto.io/docs/recipes/rbac/protect-resource

Frontend#

Per inizializzare Logto ella tua applicazione React, segui la documentazione fornita qui:: https://docs.logto.io/docs/recipes/integrate-logto/react/

Oltre alla configurazione di base, avrai bisogno di specificare la "risorsa" e le "aree di competenza" ella configurazione:

Ecco un esempio di come effettuare una richiesta API utilizzando Logto:

Backend#

Per proteggere l'API, seguire: https://docs.logto.io/docs/recipes/protect-your-api/

Oltre al codice di esempio (https://docs.logto.io/docs/recipes/protect-your-api/node), dovremo aggiungere la validazione dell'area di competenza:

Conclusione#

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.