CIAM 102: Autorizzazione & Controllo degli Accessi basato sui Ruoli

Sfondo#

Nell'articolo precedente, abbiamo introdotto il concetto di autenticazione (AuthN) e autorizzazione (AuthZ), insieme ad alcuni termini ostici: Identità, Organizzazione, Tenant, ecc.

Organizzazione e Tenant sono ottimi per raggruppare le Identità, ma portano a una democrazia assoluta: tutti possono fare qualsiasi cosa in questo sistema. Mentre l'utopia rimane ancora un mistero, diamo un'occhiata alla governance degli accessi: Autorizzazione (AuthZ).

Perché abbiamo bisogno di autorizzazione?#

Notion è un ottimo esempio. Per ogni pagina di cui sei proprietario, puoi scegliere di mantenerla privata, accessibile solo a te, o condividerla con gli amici, o anche con il pubblico.

O, per una libreria online, vuoi che tutti possano visualizzare tutti i libri, ma che i clienti possano vedere solo i loro ordini, e i venditori gestire solo i libri nei loro negozi.

AuthZ e AuthN sono componenti essenziali di un modello di business complesso. Spesso vanno mano nella mano; AuthZ verifica l'accesso di un utente, mentre AuthN autentica le identità. Entrambi sono necessari per un sistema sicuro.

Il modello di autorizzazione base#

Ecco uno dei modelli AuthZ più comuni: Se IDENTITÀ esegue AZIONE su RISORSA, allora ACCETTA o NEGA.

Nell'esempio di Notion, il modello è PERSONA esegue VISTA su PAGINA.

Se la pagina è privata:

• Riceverai ACCETTA quando esegui VISTA sulla tua PAGINA.
• Tutti gli altri dovrebbero ricevere NEGA quando eseguono VISTA sulla tua PAGINA.

Sulla base del consenso, l'industria ha sviluppato varie tecnologie di autorizzazione, come il Controllo degli Accessi basato sui Ruoli (RBAC), il Controllo degli Accessi basato sugli Attributi (ABAC). Oggi, ci concentreremo sul modello RBAC NIST Livello 1: RBACFlat.

Controllo degli Accessi basato sui Ruoli#

Estendiamo l'esempio della libreria. Supponiamo di avere molti clienti, ma solo un venditore:

• I clienti possono visualizzare e ordinare libri, oltre a visualizzare i propri ordini.
• Il venditore può visualizzare, creare e eliminare libri, e gestire gli ordini dei clienti.

Definire le risorse#

In Logto, una risorsa (cioè Risorsa API) rappresenta di solito un insieme di entità o oggetti, dato che è necessario utilizzare un URL valido come indicatore. Quindi definiamo due risorse:

• Libri: https://api.bookstore.io/books
• Ordini: https://api.bookstore.io/orders

Uno dei vantaggi dell'applicazione del formato URL è che può mappare a un indirizzo reale del tuo servizio API, migliorando la leggibilità e riconoscibilità quando si integra con altri componenti nel sistema.

Definire i permessi#

Dato che abbiamo introdotto il concetto di risorsa, in Logto, imponiamo anche che i permessi devono appartenere a una risorsa, al contrario, le risorse possono avere permessi.

Aggiungiamo alcuni permessi alle risorse:

• Libri: read, create, delete
• Ordini: read, read:self, create:self, delete

Nonostante non ci sia un requisito per il nome di un permesso, abbiamo la convenzione di seguito:

Mentre <azione> è necessaria per descrivere un permesso, :<target> può essere ignorato per descrivere un target generale, cioè a tutte le entità o oggetti nella risorsa. Per esempio:

• Il permesso read nella risorsa Libri significa l'azione di leggere libri arbitrari.
• Il permesso create:self nella risorsa Ordini significa l'azione di creare ordini che appartengono all'utente corrente.

Definire i ruoli#

In sintesi, un ruolo è un gruppo di permessi. Creiamo due ruoli cliente e venditore e assegniamo loro i permessi come di seguito:

Potresti notare che l'assegnazione permessi-ruolo è una relazione molti-a-molti.

Assegnare ruoli agli utenti#

Proprio come l'assegnazione ruolo-permesso, l'assegnazione utente-ruolo è anch'essa una relazione molti-a-molti. Pertanto, è possibile assegnare più ruoli a un singolo utente, e un singolo ruolo può essere assegnato a più utenti.

Collegare i punti#

Ecco un diagramma di relazione completo per il modello RBAC di Livello 1 in Logto:

Nel modello RBAC, i permessi sono sempre "positivi", il che significa che il giudizio di autorizzazione è semplice: se un utente ha il permesso, allora accetta; altrimenti, rifiuta.

Diciamo che Alice ha il ruolo di venditore, Bob e Carol hanno il ruolo di cliente. Descriveremo le azioni in linguaggio naturale prima e le trascriveremo nel formato di autorizzazione standard: IDENTITÀ esegue AZIONE su RISORSA, dando infine la conclusione.

• Alice vuole aggiungere un nuovo libro in vendita:
  • Utente Alice esegue create sulla risorsa Libri (https://api.bookstore.io/books).
  • Dato che ad Alice è stato assegnato il permesso create su Libri secondo il loro ruolo di venditore, il risultato è ✅ ACCETTA.
• Alice vuole visualizzare tutti gli ordini per vedere se la vendita risponde alle loro aspettative:
  • Utente Alice esegue read sulla risorsa Ordini (https://api.bookstore.io/orders).
  • Dato che ad Alice è stato assegnato il permesso read su Ordini secondo il loro ruolo di venditore, il risultato è ✅ ACCETTA.
• Bob vuole sfogliare l'elenco dei libri per vedere se c'è qualche libro che vogliono acquistare.
  • Utente Bob esegue read sulla risorsa Libri (https://api.bookstore.io/books).
  • Dato che a Bob è stato assegnato il permesso read su Libri secondo il loro ruolo di cliente, il risultato è ✅ ACCETTA.
• Bob vuole vedere l'ordine di Carol.
  • Dato che è l'ordine di qualcun altro, il permesso read:self di Ordini non funziona qui.
  • Utente Bob esegue read sulla risorsa Ordini (https://api.bookstore.io/ordine).
  • Dato che a Bob non è stato assegnato il permesso read su Ordini, il risultato è ❌ NEGA.

Altri livelli RBAC#

Ci sono quattro livelli nel modello RBAC NIST:

• RBACFlat
• RBACHerarchical
• RBACConstrained
• RBACSymmetric

Vedi il documento per i dettagli se sei interessato.

Logto ha ora l'implementazione di Livello 1 e progredirà a livelli più alti in base ai feedback della comunità. Non esitare a farci sapere se un livello superiore si adatta alle tue esigenze!

Nella pratica#

Oltre alla teoria, abbiamo ancora pesanti lavori tecnici da completare per far funzionare il modello come previsto:

• Sviluppo del client e del server di autenticazione
• Progettazione del database per RBAC
• Validazione tra diversi servizi
• Sicurezza e conformità agli standard aperti
• Gestione e assegnazione dei ruoli, permessi, risorse

Non preoccuparti. Abbiamo preso in considerazione tutto questo e aggiunto il supporto chiavi in mano per coprire tutti gli aspetti sopra citati. Controlla la 🔐 Ricetta RBAC per imparare come usare RBAC in Logto.

Note finali#

RBAC è un potente modello di gestione degli accessi per la maggior parte dei casi, ma non esiste una soluzione universale. Abbiamo ancora alcune domande:

• Ho bisogno di livelli alti di RBAC?
• Come si confronta RBAC con altri modelli di autorizzazione?
• Come definire il modello di autorizzazione tra diverse Organizzazioni?