In risposta alla tua prima domanda, il problema più grande nel controllare che un utente abbia un ruolo piuttosto che un'autorizzazione specifica è che le autorizzazioni possono essere detenute da più ruoli. A titolo di esempio, uno sviluppatore potrebbe avere accesso a vedere il portale degli sviluppatori sull'intranet aziendale, che probabilmente è anche un'autorizzazione detenuta dal loro manager. Se un utente sta tentando di accedere al portale per gli 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...
(Un'istruzione switch nella tua lingua di scelta sarebbe migliore, ma non ancora particolarmente ordinata)
Più un'autorizzazione è comune o diffusa, più ruoli utente dovresti controllare per garantire che qualcuno sia in grado di accedere a un determinato sistema. Ciò comporterebbe anche il 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 controlla semplicemente che l'utente disponga dell'autorizzazione che gli consente di accedere al portale per gli sviluppatori, ad esempio, indipendentemente dal ruolo che detengono, gli sarà concesso l'accesso.
Per rispondere alla tua seconda domanda, la ragione per cui hai ruoli è perché agiscono come facili da modificare e distribuire "pacchetti" di permessi. Se si dispone di un sistema con centinaia di ruoli e migliaia di autorizzazioni, l'aggiunta di un nuovo utente (ad esempio un nuovo responsabile delle risorse umane) richiede il passaggio e il conferimento di ogni singolo permesso degli altri responsabili delle risorse umane. Non solo sarebbe noioso, ma è incline agli errori se fatto manualmente. Confronta questo con la semplice aggiunta del ruolo "HR manager" al profilo di un utente, che garantirà loro lo stesso accesso di ogni altro utente con quel ruolo.
Si potrebbe sostenere che si potrebbe semplicemente clonare un utente esistente (se il proprio sistema lo supporta), ma mentre questo concede all'utente le autorizzazioni corrette per quel momento, tentando di aggiungere o rimuovere un'autorizzazione per tutti gli utenti nel il futuro potrebbe essere difficile. Uno scenario di esempio per questo è se, forse, in passato lo staff delle risorse umane fosse anche responsabile del libro paga, ma in seguito la società diventerà abbastanza grande da assumere personale appositamente per gestire i salari. Ciò significa che HR non ha più bisogno di accedere al sistema delle buste paga, in modo che il permesso possa essere rimosso. Se hai 10 membri diversi di risorse umane, dovrai eseguire manualmente la verifica e assicurarti di rimuovere il permesso corretto che introduce la possibilità di errore dell'utente. L'altro problema con questo è che semplicemente non scala; man mano che si acquisiscono sempre più utenti in un determinato ruolo, la modifica di un ruolo diventa molto più difficile. Confrontalo con l'utilizzo dei ruoli, in cui dovrai solo modificare il ruolo di overaring in questione per rimuovere l'autorizzazione, che verrebbe riflessa da ogni utente che detiene tale ruolo.