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 9.43