RBAC in pratica: Implementare un'autorizzazione sicura per la tua applicazione
Guida completa al Controllo di Accesso Basato su Ruoli (RBAC): padroneggiare la progettazione dei permessi, la gestione dei ruoli e l'autorizzazione sicura con un'implementazione pratica CMS.
YijunDeveloper
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.
Hai difficoltà a implementare un sistema di autorizzazione sicuro e scalabile per la tua applicazione? Il Controllo di Accesso Basato su Ruoli (RBAC) è lo standard del settore per gestire i permessi degli utenti, ma implementarlo correttamente può essere una sfida. Questo tutorial ti mostrerà come costruire un sistema RBAC robusto utilizzando un esempio reale di Sistema di Gestione dei Contenuti (CMS).
Seguendo questa guida, imparerai:
✨ Come progettare e implementare permessi dettagliati che ti diano un controllo preciso
🔒 Best practices per organizzare i permessi in ruoli significativi
👤 Tecniche per gestire efficacemente la proprietà delle risorse
🚀 Modi per rendere il tuo sistema di autorizzazione scalabile e manutenibile
💡 Implementazione pratica utilizzando un esempio reale di CMS
Il codice sorgente completo di questo tutorial è disponibile su GitHub.
Il Controllo di Accesso Basato su Ruoli è più di un semplice assegnare permessi agli utenti. Si tratta di creare un approccio strutturato all'autorizzazione che bilancia sicurezza e manutenibilità.
Puoi saperne di più su Cosa è RBAC nel Wiki dell'autenticazione.
Ecco i principi chiave che seguiremo nella nostra implementazione:
I permessi dettagliati ti danno un controllo preciso su ciò che gli utenti possono fare nel tuo sistema. Invece di livelli di accesso ampi come "admin" o "utente", definiamo azioni specifiche che gli utenti possono eseguire sulle risorse. Per esempio:
read:articles - Visualizzare qualsiasi articolo nel sistema
create:articles - Creare nuovi articoli
update:articles - Modificare gli articoli esistenti
publish:articles - Modificare lo stato di pubblicazione degli articoli
Proprietà delle risorse e controllo degli accessi#
La proprietà delle risorse è un concetto fondamentale nel design dell'autorizzazione del nostro CMS. Mentre l'RBAC definisce quali azioni possono eseguire diversi ruoli, la proprietà aggiunge una dimensione personale al controllo degli accessi:
Gli autori hanno automaticamente accesso agli articoli che hanno creato
Questo modello di proprietà naturale significa che gli autori possono sempre visualizzare e modificare i propri contenuti
Il sistema controlla sia i permessi di ruolo O la proprietà quando si gestiscono le operazioni sugli articoli
Per esempio, anche senza il permesso update:articles, un autore può ancora modificare i propri articoli
Questo design riduce la necessità di permessi di ruolo extra mantenendo la sicurezza
Questo approccio a due livelli (ruoli + proprietà) crea un sistema più intuitivo e sicuro. Editori e amministratori possono comunque gestire tutti i contenuti attraverso i loro permessi di ruolo, mentre gli autori mantengono il controllo sul loro lavoro.
Ora che abbiamo configurato RBAC in Logto, possiamo iniziare a integrarlo nel nostro frontend.
Innanzitutto, segui le Guide Rapide di Logto per integrare Logto nella tua applicazione.
Nel nostro esempio, usiamo React per la dimostrazione.
Dopo aver configurato Logto nella tua applicazione, dobbiamo aggiungere le configurazioni RBAC per far funzionare Logto.
Ricorda di disconnetterti e accedere nuovamente per far sì che questa modifica abbia effetto se sei già connesso.
Quando l'utente accede con Logto e richiede un token di accesso per le risorse API specificate sopra, Logto aggiungerà ambiti (permessi) relativi al ruolo dell'utente al token di accesso.
Puoi utilizzare getAccessTokenClaims dall'hook useLogto per ottenere gli ambiti dal token di accesso.
E puoi utilizzare userScopes per verificare se l'utente ha il permesso di accedere alla risorsa.
Innanzitutto, dobbiamo aggiungere un middleware nel backend per controllare i permessi degli utenti, verificare se l'utente è loggato e determinare se hanno i permessi necessari per accedere a determinate API.
Come puoi vedere, in questo middleware, verifichiamo se la richiesta frontend contiene un token di accesso valido e controlliamo se l'audience del token di accesso corrisponde alla risorsa API che abbiamo creato nel Logto Console.
Il motivo per verificare la risorsa API è che la nostra risorsa API rappresenta in realtà le risorse del nostro backend CMS, e tutti i nostri permessi CMS sono associati a questa risorsa API.
Poiché questa risorsa API rappresenta le risorse CMS in Logto, nel nostro codice frontend, includiamo il corrispondente token di accesso quando facciamo richieste API al backend:
Ora possiamo usare il middleware requireAuth per proteggere i nostri endpoint API.
Per le API che dovrebbero essere accessibili solo agli utenti con permessi specifici, possiamo aggiungere restrizioni direttamente nel middleware. Per esempio, l'API di creazione degli articoli dovrebbe essere accessibile solo agli utenti con il permesso create:articles:
Per API che devono controllare sia i permessi che la proprietà delle risorse, possiamo utilizzare la funzione hasScopes. Per esempio, nell'API di elencazione degli articoli, gli utenti con il permesso list:articles possono accedere a tutti gli articoli, mentre gli autori possono accedere ai propri articoli creati:
A questo punto, abbiamo completato l'implementazione di RBAC. Puoi controllare il codice sorgente completo per vedere l'implementazione completa.
Ora, testiamo la nostra implementazione RBAC CMS utilizzando i tre utenti che abbiamo appena creato.
Innanzitutto, accediamo rispettivamente come Alex e Charles e creiamo alcuni articoli.
Poiché Alex ha il ruolo Admin, può creare, eliminare, aggiornare, pubblicare e visualizzare tutti gli articoli.
Charlie, avendo il ruolo Author, può solo creare i propri articoli e può solo visualizzare, aggiornare ed eliminare gli articoli di cui è proprietario.
Bob, con il ruolo Publisher, può visualizzare e pubblicare tutti gli articoli ma non può crearli, aggiornarli o eliminarli.
