## Sfondo Nell'[articolo precedente](/ciam-101-intro-authn-sso/), 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? Autorizzazione (AuthZ) risponde alla domanda “Cosa puoi fare?” 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](https://csrc.nist.gov/CSRC/media/Publications/conference-paper/2000/07/26/the-nist-model-for-role-based-access-control-towards-a-unified-/documents/sandhu-ferraiolo-kuhn-00.pdf) Livello 1: RBACFlat. ## Controllo degli Accessi basato sui Ruoli Il modello RBAC NIST ha lasciato molte cose aperte per fornire flessibilità e adattabilità per vari scenari. Logto adotta ora la definizione del Livello 1 con un concetto aggiuntivo "Risorsa" (cioè Risorsa API). 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. Le risorse dovrebbero essere divise in base alle esigenze dell'azienda. Non esiste una soluzione universale; la decisione dovrebbe essere presa caso per caso. L'esempio in questo articolo che divide Libri e Ordini può essere adatto per i microservizi, ma non per un architettura monolitica. ### 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 `` è necessaria per descrivere un permesso, `:` 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: ```mermaid erDiagram Ruolo-Cliente { permesso Libri "read" permesso Ordini "read:self" permesso Ordini "create:self" } Ruolo-Venditore { permesso Libri "read" permesso Libri "create" permesso Libri "delete" permesso Ordini "read" permesso Ordini "delete" } ``` 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: ```mermaid erDiagram Utente }|--|{ Ruolo : mappe Ruolo }|--|{ Permesso : mappe "API Risorsa" ||--|{ Permesso : contiene ``` 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](https://csrc.nist.gov/CSRC/media/Publications/conference-paper/2000/07/26/the-nist-model-for-role-based-access-control-towards-a-unified-/documents/sandhu-ferraiolo-kuhn-00.pdf) 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](https://docs.logto.io/docs/recipes/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? 🔥 Rimani sintonizzato. Ci vediamo in CIAM 103!