Sto implementando il sistema di sicurezza del modello RBAC (Role-Based Access Control) e ho un dilemma: un utente1 è in Role1 e si trova in Role2. Role1 consente l'accesso a Resource1 e Role2 nega l'accesso allo stesso. È un problema ben noto. Qualcuno potrebbe aiutarmi, come risolverlo, forse qualche spiegazione. Come spiegare Utente1 perché non ha accesso ad alcune risorse. Qualche soluzione è come superarla intelligente.
Grazie.
Sembra che tu stia confondendo tra RBAC e DAC (controllo di accesso discrezionale): Nega accesso non è in genere impiegato in RBAC, ma piuttosto proviene dal mondo DAC. F.e. è comune vedere un ACL NTFS (Access Control List) con DENY al suo interno.
Potresti provare a implementare un modello unito (vedi l'esempio nella mia risposta qui ) - es creazione di un ACL con voci ACE (Access Control Entry) che indicano i ruoli. Per esempio. utilizzando i gruppi per concedere l'accesso alle cartelle ...
Ci sono due possibili soluzioni che puoi usare, forse anche mix'n'match, dipende da cosa ha senso per il tuo sistema (l'ho costruito e usato entrambi, in diversi contesti):
Si noti che non si potrebbe implementare questo con un modello ACL standard, ma in realtà solo controllando i ruoli utente - che va ancora bene, il precedente si applica ancora (solo più difficile da visualizzare e spiegare).
La vera domanda che devi capire è, cosa ha senso per il tuo sistema? Stai cercando di implementare SoD (Segregation / Separation of Duties)? Se è così, è chiaro che DENY deve ignorare qualsiasi PERMESSO. Se si desidera che l'utente configuri questo (nel qual caso il suo DAC, non RBAC), la prima opzione offre la massima flessibilità, poiché esiste un modo per aggirare il problema.
Non sono sicuro che questo sia un problema ben noto. Se la tua posizione di default è deny-to-all, e dovrebbe essere, allora le regole dovrebbero solo indicare ciò che ciascun può fare. Se un utente / ruolo ha accesso a una risorsa in base a qualsiasi regola, penso che dovrebbero essere consentiti.
Potrebbe essere necessario ripensare il modo in cui i ruoli sono disposti. Penso che nei conflitti, vincerebbe il più alto. Gli strumenti potrebbero gestirlo in modi diversi. È importante capire esattamente come funziona , non come dovrebbe funzionare.
Potrei mancare qualcosa, ma non è una soluzione abbastanza semplice usare un concetto come un "ruolo attivo"?
In altre parole, l'utente seleziona il proprio ruolo attivo dall'elenco di ruoli a cui sono assegnati e quindi controlla solo ACL rispetto a quel singolo ruolo.
Potresti prendere in considerazione l'utilizzo di ciò che ho sentito nominare come una sicurezza di accesso basata su Claims ibridi. In questo modello, fondamentalmente ogni attività viene suddivisa e utilizzata come profilo per mantenere la sicurezza più facile da gestire (sebbene sia più difficile da implementare inizialmente).
Fondamentalmente tabelle di installazione simili a:
Users --> Groups --> Profiles --> Rights
| |_______________________^
|____________________^
|_________________________________^
Tabella utenti, ogni utente può avere uno o più gruppi Gli utenti possono anche avere uno o più profili (ovvero sub gruppi di diritti per un'attività) Gli utenti possono anche avere uno o più diritti I gruppi hanno uno o più profili I gruppi possono avere uno o più diritti I profili possono avere uno o più diritti
Lo svantaggio deriva dal livello extra di gruppi che sono orientati ai compiti, tuttavia è più facile per la maggior parte dei non sviluppatori essere in grado di concettualizzare questo progetto.
Inoltre puoi usare un sistema basato su Claims puro ma è difficile mantenere qualcosa come IMO a lungo termine. Probabilmente starai meglio con RBAC standard (non RB-RBAC) e userai un insieme coerente di regole come conflict = denial of access.
Leggi altre domande sui tag authorization access-control rbac