Controllo degli accessi in base al ruolo e alle autorizzazioni

Sto cercando di capire il compromesso intrinseco tra ruoli e autorizzazioni quando si tratta di controllo degli accessi (autorizzazione).

Partiamo da un dato: nel nostro sistema, un'Autorizzazione sarà un'unità di accesso a grana fine (" Modifica risorsa X ", " Accesso alla pagina del pannello ", ecc.). Un ruolo sarà una raccolta di autorizzazioni 1+. Un utente può avere 1+ ruoli. Tutte queste relazioni (Utenti, Ruoli, Autorizzazioni) sono tutte archiviate in un database e possono essere modificate al volo e secondo necessità.

Le mie preoccupazioni:

(1) Cosa c'è di così "male" nel controllare i ruoli per il controllo degli accessi? Quali vantaggi si ottengono invece controllando le autorizzazioni? In altre parole, qual è la differenza tra questi due frammenti di seguito:

if(SecurityUtils.hasRole(user)) {
    // Grant them access to a feature
}

// vs.
if(SecurityUtils.hasPermission(user)) {
    // Grant them access to a feature
}

E:

(2) In questo scenario quale valore utile forniscono anche i ruoli? Non potremmo semplicemente assegnare 1+ autorizzazioni agli utenti direttamente? Quale valore concreto di astrazione offrono i ruoli (qualcuno può fornire esempi specifici)?

(1) Cosa c'è di così "male" nel controllare i ruoli per il controllo degli accessi? Quali vantaggi si ottengono invece controllando le autorizzazioni?

Al momento della verifica, il codice chiamante deve solo sapere "l'utente X dispone dell'autorizzazione per eseguire l'azione Y?" .
Il codice chiamante non si preoccupa e non dovrebbe essere a conoscenza delle relazioni tra ruoli e autorizzazioni.

Il livello di autorizzazione verificherà quindi se l'utente dispone di questa autorizzazione, in genere controllando se il ruolo dell'utente dispone di tale autorizzazione. Ciò consente di modificare la logica di autorizzazione senza aggiornare il codice chiamante.

Se si controlla direttamente il ruolo nel sito di chiamata, si stanno implicitamente formando relazioni di autorizzazione and ruolo e si inserisce la logica di autorizzazione nel codice chiamante, violando la separazione delle preoccupazioni.

Se in seguito dovessi decidere che il ruolo foonon dovrebbe avere l'autorizzazione baz, dovresti cambiare ogni codice che controlla se l'utente è un foo.

(2) In questo scenario quale valore utile forniscono anche i ruoli? Non potremmo semplicemente assegnare 1+ autorizzazioni agli utenti direttamente? Quale valore concreto di astrazione offrono i ruoli (qualcuno può fornire esempi specifici)?

I ruoli rappresentano concettualmente una raccolta denominata di autorizzazioni.

Supponiamo che tu stia aggiungendo una nuova funzionalità che consente a un utente di modificare determinate impostazioni. Questa funzione dovrebbe essere disponibile solo per gli amministratori.

Se stai memorizzando le autorizzazioni per utente, dovresti trovare tutti gli utenti nel tuo database che in qualche modo conosci sono amministratori (se non stai memorizzando le informazioni sul ruolo per gli utenti, come faresti a sapere quali utenti sono amministratori?) E aggiungere questa autorizzazione al loro elenco di autorizzazioni.

Se usi i ruoli, devi solo aggiungere l'autorizzazione al Administratorruolo, che è sia più semplice da eseguire, più efficiente nello spazio, sia meno incline agli errori.

In risposta alla tua prima domanda, il problema più grande nel verificare che un utente abbia un ruolo anziché un'autorizzazione specifica è che le autorizzazioni possono essere detenute da più ruoli. A titolo di esempio, uno sviluppatore potrebbe avere accesso per vedere il portale degli sviluppatori sull'intranet aziendale, che è probabilmente anche un'autorizzazione detenuta dal proprio manager. Se un utente sta quindi tentando di accedere al portale per sviluppatori, avresti un controllo simile a:

if(SecurityUtils.hasRole(developer)) {
    // Grant them access to a feature
} else if(SecurityUtils.hasRole(manager)) {
    // Grant them access to a feature
} else if...

( switchUn'affermazione nella tua lingua preferita sarebbe migliore, ma ancora non particolarmente ordinata)

Più un'autorizzazione è diffusa o diffusa, più ruoli utente dovresti verificare per garantire che qualcuno sia in grado di accedere a un determinato sistema. Ciò porterebbe anche al problema che ogni volta che si modificano le autorizzazioni per un ruolo, è necessario modificare il controllo per riflettere questo. In un sistema di grandi dimensioni questo diventerebbe molto ingombrante molto rapidamente.

Se si verifica semplicemente che l'utente disponga dell'autorizzazione che consente ad esempio l'accesso al portale per sviluppatori, non importa quale ruolo ricoprono, gli verrà concesso l'accesso.

Per rispondere alla tua seconda domanda, il motivo per cui hai ruoli è perché agiscono come facili da modificare e distribuire "pacchetti" di autorizzazioni. Se si dispone di un sistema con centinaia di ruoli e migliaia di autorizzazioni, l'aggiunta di un nuovo utente (ad esempio un nuovo gestore delle risorse umane) richiederebbe di passare attraverso e dare loro ogni singola autorizzazione detenuta da altri gestori delle risorse umane. Questo non solo sarebbe noioso, ma è soggetto a errori se fatto manualmente. Confrontalo semplicemente aggiungendo il ruolo di "Responsabile risorse umane" al profilo di un utente, che garantirà loro lo stesso accesso di tutti gli altri utenti con quel ruolo.

Potresti sostenere che potresti semplicemente clonare un utente esistente (se il tuo sistema lo supporta), ma mentre ciò concede all'utente le autorizzazioni corrette per quel momento nel tempo, tentare di aggiungere o rimuovere un'autorizzazione per tutti gli utenti in futuro potrebbe essere difficile. Uno scenario di esempio per questo è se forse in passato anche il personale delle risorse umane era responsabile della gestione stipendi, ma in seguito l'azienda diventa abbastanza grande da assumere personale specificamente per gestire le buste paga. Ciò significa che le risorse umane non devono più accedere al sistema di gestione stipendi, pertanto è possibile rimuovere l'autorizzazione. Se hai 10 membri diversi di risorse umane, dovrai passare manualmente e assicurarti di rimuovere l'autorizzazione corretta che introduce la possibilità di errore dell'utente. L'altro problema con questo è che semplicemente non si ridimensiona; man mano che guadagni sempre più utenti in un determinato ruolo, diventa molto più difficile modificare un ruolo. Confrontalo con l'utilizzo dei ruoli, in cui dovrai solo modificare il ruolo generale in questione per rimuovere l'autorizzazione, che sarebbe riflessa da ogni utente che detiene quel ruolo.