Considerazioni su RBS, Ruoli e UserType

Credo che uno degli errori più diffusi e sia quello di confondere e/o unire il concetto di UserType con il concetto di ruolo. La Role Based Security (RBS) si basa sul concetto che un utente è associato a più ruoli e un ruolo identifica uno scope di azioni all’interno del applicazione/sistema.  Un utente quindi non ricopre un solo ruolo ma può ricoprire più ruoli. 

(E’ mia opinione che i ruoli costituiscano insiemi non sovrapponibilili di azioni anche se non ci sono vere e proprie contraddizioni a fare il contrario. A tal proposito è interessante notare che sebbene quando si crea un utente si possono associare più ruoli esiste il solo metodo IsInRole che controlla se un utente appartiene ad un determinato ruolo e non esiste il metodo IsInRoles per controllare se un utente appartiene a più ruoli. Anche se è ovvio che non è difficile implementare il metodo in una classe di utilità, la cosa dovrebbe farci pensare che forse non è/era nella filosofia della RBS dover fare un check sull’appartenenza a più ruoli. Ma su questa questione preferisco approfondire in un altro momento e continuare invece sull’argomento principale.)

Nella RBS un utente è associato a molti ruoli e i ruoli sono definiti ByDesign nell’applicazione e registrati poi nel sistema di gestione degli utenti per poter configurare le assocazione utente-ruoli. 

Cosa significa lavorare con lo UserType? Lavorare con il concetto di  UserType  significa che applicativamente sono definiti gli scope di azione di ogni singola tipologia di utente ed un utente è associato ad un solo tipo. Aggiungere una nuova tipologia di utente nell’applicazione potrebbe voler dire rivederla interamente per definire lo scope delle azioni di questo nuovo tipo di utente.

Come possono convivere UserType e RBS? Ha senso fare convirere le due metodologie? E' mia opinione che ha senso farle convivere e si modo di presentare la secuirty in modo più usabile/intuibile. Quando l’applicazione inizia a richiedere la gestione di sempre più ruoli, di conseguenza si ha una complicazione della parte amministrativa che si vede impegnata in una gestione troppo complessa per quanto riguarda le associazioni di un utente con i molti/troppi ruoli. L’impiegato/systemista che deve gestire le authorizzazioni ad un sistema è più facilitato se può dire che un utente è di un certo tipo senza perdersi in configurazioni troppo complesse con il rischio di impiegare troppo tempo e  sbagliare. 

(Qui si potrebbe aprire una parentesi per dire che è tendenza di un tecnico portare verso l’alto l’intero potenziale delle tecnologie/systema in uso invece di presentare il potenziale del sistema nel modo più semplice per l’utilizzatore finale.)

Nel far convivere UserType e RBS si ha che i ruoi non sono associati direttamente all’utente ma alla tipologia di utente. Un utente è associato ad un solo tipo e il tipo è associato a più ruoli e di conseguenza anche l’utente è indirittamente legato a più ruoli. Il sistema potrà continuare a godere delle potenzialità della RBS e la parte amministrativa sarà facilitata nel poter creare semplicemente utenti che saranno di una tipologia ben definita. 

L’associazione UserType-Role ovviamente rimane e qundi si potrebbe dire che si è solo spostato il problema. Ma ora il problema si è spostato in quelle che si potrebbero chiamare configurazione avanzate  (manuale o gestita da interfaccia) o addirittura in fase di setup del sistema  (manuale o automatico). La definizione di nuovo UserType è quindi qualcosa che ha impatto solo a livello di configurazione e non ha impatto sull'applicazione perchè NON è incluso ByDesign perchè NON è parte applicativa.

posted @ giovedì 20 luglio 2006 12:43

Print

Comments on this entry:

# re: Considerazioni su RBS, Ruoli e UserType

Left by M.rkino at 20/07/2006 14:21
Gravatar
Ciao andrea, penso che nel momento in cui dici che un utente può essere associato a più usertype allora stai chiamando usertype quello che poi è il ruolo.... cose che fa - IMHO - cadere in una serie infinita di problemi perchè vengono mischiati concetti diversi e portata compessità verso l'alto.

Nel momento in cui poi si vogliono creare delle associazioni/permessi a livello di dato si esce dalla RBS e non si deve più parlare ne di ruoli e ne di tipologia di utente. Quando si deve definire la paternità dei dati e i permessi sui dati viene comodo l'uso dell'accountability di MArtin Fowler, http://www.martinfowler.com/apsupp/accountability.pdf. Non solo utile per la gestione delle organizzazioni a sruttura complessa ma anche per definire le relazioni tra party che non sono necessariamente persone fisiche e/o guiridiche ma anche documenti e oggetti...

# re: [Daily Issue] Comprendere la sezione

Left by NeatCoding at 25/06/2007 18:35
Gravatar
Comments have been closed on this topic.
«novembre»
domlunmarmergiovensab
31123456
78910111213
14151617181920
21222324252627
2829301234
567891011