Meccanismi di Autorizzazione: Il Caso di Keycloak

Keycloak: Una Panoramica

Keycloak è un sistema di gestione dell’identità e dell’accesso, focalizzato sulla centralizzazione dell’autenticazione per applicazioni web e servizi. Consente agli utenti di accedere a diverse applicazioni e servizi con un unico set di credenziali, semplificando così il processo di autenticazione e migliorando la sicurezza. Supporta protocolli standard come OpenID Connect, OAuth 2.0 e SAML 2.0, offrendo flessibilità e compatibilità con vari sistemi. La documentazione e i dettagli di implementazione possono essere trovati nella guida ufficiale di Keycloak, disponibile sul sito web di Keycloak.

Keycloak by RedHat

User-Managed Access (UMA)

User-Managed Access (UMA) è uno standard di protocollo per la gestione dell’accesso basato su OAuth, specificamente OAuth 2.0, che consente la condivisione di risorse tra diverse parti in modo controllato dal proprietario della risorsa (​1, ​​2)​. UMA è stato approvato dalla Kantara Initiative ed è particolarmente utile per rafforzare la privacy dei dati e per conformarsi alle normative sulla privacy come il GDPR e il CCPA (​2)​.

La particolarità di UMA è che il proprietario della risorsa, che controlla l’accesso, non deve necessariamente essere online al momento dell’accesso, poiché la condivisione tra le parti è guidata da politiche predefinite. Questo permette, ad esempio, a un paziente di condividere selettivamente i propri dati sanitari con medici, membri della famiglia o compagnie assicurative, concedendo permessi specifici come “visualizzare” ma non “modificare” (​2)​.

Il funzionamento di UMA prevede un flusso di lavoro che stabilisce politiche di autorizzazione su un server di autorizzazione centralizzato. Ci sono cinque ruoli principali associati al flusso di lavoro di UMA:

1. Proprietario della risorsa: L’utente o entità che concede l’accesso a una risorsa protetta.
2. Server della risorsa: Ospita le risorse protette e risponde alle richieste di accesso.
3. Server di autorizzazione: Protegge le risorse sul server della risorsa per conto del proprietario della risorsa.
4. Client: Un’applicazione che agisce per conto della parte richiedente.
5. Parte richiedente: L’entità che cerca di accedere a una risorsa protetta tramite un client (​2)​.

La sequenza di azioni nel flusso di UMA è la seguente:

1. Il proprietario della risorsa registra la risorsa sul server della risorsa e imposta le condizioni della politica sul server di autorizzazione.
2. La parte richiedente chiede l’accesso alla risorsa protetta utilizzando il client.
3. Il client, agendo per conto della parte richiedente, interagisce con il server di autorizzazione e fornisce le attestazioni richieste che soddisfano le politiche di autorizzazione del proprietario della risorsa.
4. Il client riceve un token dal server di autorizzazione.
5. Il token viene presentato al server della risorsa per ottenere l’accesso per la parte richiedente (​2)​.

L’architettura di UMA si compone principalmente di due componenti:

• Protection API: Fornisce endpoint come il Resource Registration Endpoint per la registrazione delle risorse e il Permission Endpoint per la richiesta di permessi.
• UMA Grant: Un token unico OAuth che contiene informazioni sui permessi concessi, chiamato RPT (Requesting Party Token), che è essenziale per l’accesso alle risorse protette da UMA (​2)​.

In sintesi, UMA consente ai proprietari delle risorse di avere un controllo completo sull’accesso alle loro risorse, stabilendo politiche attraverso un server di autorizzazione centralizzato, senza la necessità di essere presenti online al momento dell’accesso, e fornendo un metodo sicuro e affidabile per la gestione della privacy e della condivisione dei dati.

User-Managed Access (UMA) in Keycloak

L’UMA in Keycloak consente agli utenti di gestire le autorizzazioni per le proprie risorse. Questo significa che gli utenti possono decidere chi ha l’accesso e a quali condizioni, dando loro un controllo diretto sulla condivisione dei dati. Il processo è facilitato attraverso la console di Keycloak, dove è possibile configurare le impostazioni di UMA. Questa caratteristica è particolarmente utile in scenari complessi, dove la gestione fine dei permessi è essenziale. Dettagli addizionali sulla configurazione UMA in Keycloak possono essere trovati nella guida ai servizi di autorizzazione di Keycloak.

Controllo Accessi Basato sui Ruoli (RBAC) vs. Basato sui Permessi (PBAC)

Role-Based Access Control (RBAC) e Permission-Based Access Control (PBAC) sono due framework distinti utilizzati per la gestione dell’accesso e della sicurezza.

RBAC: Definizione e Utilizzo RBAC associa permessi a ruoli specifici all’interno di un’organizzazione. Un ruolo, che rappresenta un insieme di permessi legati a funzioni lavorative, è assegnato agli utenti, che ereditano i permessi di quel ruolo. I ruoli sono relativamente statici e richiedono un intervento amministrativo per essere modificati.

PBAC: Definizione e Utilizzo PBAC si basa su politiche di sicurezza che regolano l’accesso alle risorse. Le politiche sono regole dinamiche che possono includere contesti come ubicazione, orario e tipo di dispositivo. Queste politiche offrono un controllo granulare e possono essere adattate rapidamente a nuove condizioni, senza modificare i ruoli.

Differenza tra Politiche e Ruoli Le politiche in PBAC sono dinamiche e possono cambiare in base a condizioni esterne, mentre i ruoli in RBAC sono collezioni statiche di permessi. PBAC fornisce la flessibilità di modificare le regole di accesso in tempo reale, rispondendo agilmente a cambiamenti normativi o di politica aziendale, a differenza dei ruoli in RBAC che richiedono modifiche strutturali più sostanziali per adattarsi a tali cambiamenti.

RBAC: Un’Introduzione

RBAC è un meccanismo di controllo dell’accesso basato su ruoli e privilegi. In un sistema RBAC, vengono creati ruoli per varie funzioni lavorative e ai ruoli vengono assegnati permessi specifici. Gli utenti acquisiscono permessi non direttamente ma attraverso i loro ruoli. Questo facilita la gestione dei diritti degli utenti, rendendo più semplici operazioni come l’aggiunta di un nuovo utente o il cambio di dipartimento di un utente esistente​1​.

Le convenzioni utili nella definizione di un modello RBAC includono:

• Soggetto (Subject): Una persona o un agente automatizzato.
• Ruolo (Role): Funzione lavorativa o titolo che definisce un livello di autorità.
• Permessi (Permissions): Approvazione di una modalità di accesso a una risorsa.
• Sessione (Session): Una mappatura che coinvolge Soggetto, Ruolo e/o Permessi.
• Assegnazione Soggetto (Subject Assignment) e Assegnazione Permessi (Permission Assignment).
• Gerarchia dei Ruoli (Role Hierarchy): I ruoli possono essere organizzati gerarchicamente, dove i ruoli di livello superiore includono i permessi dei sottoruoli​ (1)​.

PBAC: Un’Introduzione

PBAC, d’altra parte, è un sistema che definisce ed esegue politiche di sicurezza. Ogni tipo di utente si vede assegnare un insieme di politiche che definiscono ciò che gli è permesso fare. Quando un utente tenta di accedere a una risorsa, il sistema controlla le politiche per vedere se ha l’autorizzazione. PBAC è spesso usato in congiunzione con altri modelli di sicurezza, come RBAC, per fornire una soluzione di sicurezza più completa​(2)​.

PBAC offre diversi benefici, tra cui:

• La definizione e l’applicazione coerente delle politiche di sicurezza in tutta l’organizzazione.
• La riduzione del carico amministrativo associato alla gestione dei permessi di controllo dell’accesso.
• Miglioramento della sicurezza consentendo agli amministratori di revocare rapidamente l’accesso alle risorse quando necessario.
• Abilitazione dell’auditing e della generazione di report sull’attività degli utenti a fini di conformità (​2)​.

PBAC offre un approccio flessibile e granulare alla gestione dei permessi di accesso. Gli amministratori definiscono insiemi di politiche che dettagliano chi ha accesso a quali risorse e in quali condizioni. Queste politiche possono essere semplici o complesse secondo necessità, rendendo PBAC una soluzione ideale per organizzazioni con elevate esigenze di sicurezza. Inoltre, PBAC consente agli amministratori di apportare modifiche ai permessi di accesso senza dover modificare le regole o le configurazioni esistenti (​2)​.

RBAC e PBAC in Keycloak

Keycloak implementa un sistema flessibile che può supportare sia Role-Based Access Control (RBAC) sia Permission-Based Access Control (PBAC). In Keycloak, ogni applicazione cliente può agire come un server di risorse, e le risorse e i relativi ambiti sono protetti e governati da un insieme di politiche di autorizzazione. Le politiche possono essere aggregate per costruire “politiche di politiche”, consentendo una gestione complessa e granulare dell’accesso. Keycloak offre anche la possibilità di creare tipi di politiche personalizzati tramite la sua interfaccia Service Provider Interface (SPI). Inoltre, Keycloak utilizza i permission ticket, definiti dalla specifica User-Managed Access (UMA), per gestire l’accesso basato su politiche fini (​1​​, 2​​)​.

Conclusione

Nella scelta tra RBAC e PBAC, è fondamentale considerare le dimensioni dell’organizzazione, la natura delle risorse da proteggere e la necessità di granularità nel controllo dei permessi. Keycloak offre la versatilità per adattarsi a entrambi gli approcci, permettendo agli amministratori di sistema di trovare il giusto equilibrio per la loro specifica situazione. Per una panoramica completa di come Keycloak gestisce ruoli e permessi, si può fare riferimento alla sua documentazione ufficiale.