Menu Permissions

Iniziamo introducendo un esempio di Spring Boot che presenta un sistema di menu. Questo esempio sfrutta jCasbin per gestire i permessi del menu. In definitiva, mira a astrarre un middleware, specificamente per i permessi del menu, che potrebbe essere esteso ad altre lingue supportate da Casbin, come Go e Python.

1. File di Configurazione

È necessario configurare la gestione dei ruoli e delle autorizzazioni nel file policy.csv, insieme alle relazioni padre-figlio tra gli elementi dei menu. Per maggiori dettagli, si prega di consultare questo repository GitHub.

1.1 Panoramica

Utilizzando policy.csv, è possibile configurare flessibilmente le autorizzazioni dei ruoli e le strutture dei menu per un controllo di accesso dettagliato. Questo file di configurazione definisce le autorizzazioni di accesso per diversi ruoli su vari elementi dei menu, le associazioni tra utenti e ruoli, e le relazioni gerarchiche tra gli elementi dei menu.

1.2 Definizioni delle Autorizzazioni (Politiche)

Regole delle Politiche: Le politiche sono definite con un prefisso p, specificando i ruoli (sub) e le loro autorizzazioni (act) sugli elementi dei menu (obj), insieme all'effetto della regola (eft), dove allow indica che l'autorizzazione è concessa e deny indica che è negata.

Esempi:

p, ROLE_ROOT, SystemMenu, read, allow significa che il ruolo ROLE_ROOT ha accesso in lettura all'elemento del menu SystemMenu.
p, ROLE_ROOT, UserMenu, read, deny significa che il ruolo ROLE_ROOT è negato l'accesso in lettura all'elemento del menu UserMenu.

1.3 Associazioni Ruoli e Utenti

Ereditarietà del Ruolo: Le relazioni utente-ruolo e le gerarchie dei ruoli sono definite con un prefisso g. Ciò consente agli utenti di ereditare permessi da uno o più ruoli.

Esempi:

g, user, ROLE_USER significa che l'utente user è assegnato al ruolo ROLE_USER.
g, ROLE_ADMIN, ROLE_USER significa che ROLE_ADMIN eredita i permessi da ROLE_USER.

Relazioni tra Menu: Le relazioni genitore-figlio tra gli elementi del menu sono definite con un prefisso g2, facilitando la costruzione della struttura di un menu.

Esempi:

g2, UserSubMenu_allow, UserMenu indica che UserSubMenu_allow è un sottomenu di UserMenu.
g2, (NULL), SystemMenu indica che SystemMenu non ha un elemento sottomenu, il che significa che è un elemento di menu di primo livello.

Quando si gestiscono i permessi dei menu con jCasbin, la relazione di permesso tra menu padre e menu figlio segue regole specifiche di ereditarietà, con due importanti regole predefinite:

Ereditarietà dei Permessi del Menu Padre:

Se un menu padre è esplicitamente concesso il permesso allow, tutti i suoi sottomenu assumono di default il permesso allow a meno che non siano specificamente contrassegnati come deny. Ciò significa che una volta che un menu padre è accessibile, i suoi sottomenu sono accessibili di default.

Gestione dei Menu Padri Senza Impostazioni di Permesso Dirette:

Se un menu padre non ha impostazioni di permesso dirette (né esplicitamente consentite né negate) ma ha almeno un sottomenu esplicitamente concesso il permesso allow, allora il menu padre è implicitamente considerato avere il permesso allow. Questo garantisce che gli utenti possano navigare verso questi sottomenu.

1.6 Regole di Ereditarietà delle Permessi Speciali

Riguardo l'ereditarietà delle autorizzazioni tra i ruoli, specialmente in scenari che coinvolgono autorizzazioni di negazione, è necessario seguire le seguenti regole per garantire la sicurezza del sistema e un controllo preciso delle autorizzazioni:

Distinzione tra Negazioni Esplicite e Negazioni Predefinite:

Se un ruolo, come ROLE_ADMIN, è esplicitamente negato l'accesso a un elemento di menu, come AdminSubMenu_deny (contrassegnato come deny), allora anche se questo ruolo è ereditato da un altro ruolo (ad esempio, ROLE_ROOT), il ruolo ereditato non è autorizzato ad accedere all'elemento di menu negato. Questo garantisce che le politiche di sicurezza esplicite non vengano aggirate a causa dell'ereditarietà del ruolo.

Ereditarietà delle Autorizzazioni di Negazione Predefinite:

Al contrario, se la negazione dell'accesso di un ruolo a un elemento di menu (ad esempio, UserSubMenu_deny) è predefinita (non esplicitamente contrassegnata come deny, ma perché non è stata esplicitamente concessa allow), allora quando questo ruolo è ereditato da un altro ruolo (ad esempio, ROLE_ADMIN), il ruolo ereditato può sovrascrivere lo stato di deny predefinito, permettendo l'accesso a questi elementi di menu.

1.7 Descrizione dell'Esempio

politica:

p, ROLE_ROOT, SystemMenu, read, allow
p, ROLE_ROOT, AdminMenu, read, allow
p, ROLE_ROOT, UserMenu, read, deny
p, ROLE_ADMIN, UserMenu, read, allow
p, ROLE_ADMIN, AdminMenu, read, allow
p, ROLE_ADMIN, AdminSubMenu_deny, read, deny
p, ROLE_USER, UserSubMenu_allow, read, allow

g, user, ROLE_USER
g, admin, ROLE_ADMIN
g, root, ROLE_ROOT
g, ROLE_ADMIN, ROLE_USER

g2, UserSubMenu_allow, UserMenu
g2, UserSubMenu_deny, UserMenu
g2, UserSubSubMenu, UserSubMenu_allow
g2, AdminSubMenu_allow, AdminMenu
g2, AdminSubMenu_deny, AdminMenu
g2, (NULL), SystemMenu

NomeMenu	RUOLO_ROOT	RUOLO_AMMINISTRATORE	RUOLO_UTENTE
SystemMenu	✅	❌	❌
UserMenu	❌	✅	❌
UserSubMenu_allow	❌	✅	✅
UserSubSubMenu	❌	✅	✅
UserSubMenu_deny	❌	✅	❌
AdminMenu	✅	✅	❌
AdminSubMenu_allow	✅	✅	❌
AdminSubMenu_deny	✅	❌	❌

L'elenco di tutti gli elementi del menu accessibili da un dato nome utente può essere identificato attraverso la funzione findAccessibleMenus() disponibile nel MenuService. Per verificare se un utente specifico ha i diritti per accedere a un elemento del menu designato, è possibile utilizzare il metodo checkMenuAccess(). Questo approccio garantisce che le autorizzazioni dei menu siano controllate in modo efficace, sfruttando le capacità di jCasbin per gestire i diritti di accesso in modo efficiente.