I sistemi software per la gestione di più progetti sono complessi - almeno dietro le quinte del lato tecnico. Una moltitudine di funzioni deve essere fornita per la pianificazione di progetti individuali, la gestione dei compiti, la creazione di rapporti, per citarne solo alcuni. Allo stesso tempo, non solo un utente ci lavora. No, tipicamente ci sono decine di utenti che condividono tutte queste funzioni e i dati nel sistema, spesso lavorando con esso simultaneamente e da luoghi diversi. E, naturalmente, l'applicazione dovrebbe essere "super facile" da usare per tutte le persone coinvolte e avere un'esperienza utente eccellente, secondo i requisiti aziendali, naturalmente.

I sistemi multiutente richiedono un concetto di autorizzazione

Con questa posizione di partenza, non sorprende che il sistema software ricercato debba avere un concetto di autorizzazione flessibile ma anche facilmente comprensibile. Cosa intendiamo con questo? Nel contesto di un sistema software, un concetto di autorizzazione è semplicemente definito,

1. quale utente
2. a cui i dati
3. che tipo di accesso.

Questo solleva diverse questioni di comprensione che devono essere spiegate. Prima di tutto, l'utente del sistema deve essere identificato dal sistema. Si parla anche di autenticazione. L'utente accede al sistema dicendo chi è e il sistema gli chiede di provarlo. Questo sembra complicato, ma lo facciamo diverse volte al giorno inserendo il nostro nome utente e la relativa password in una finestra di login. Con il nome utente dico al sistema chi sono, e con la password fornisco la prova. Questo semplice processo si chiama autenticazione. Se vogliamo mettere in gioco un po' più di sicurezza, allora richiediamo un po' più di prova all'utente, per esempio chiedendogli di digitare un codice aggiuntivo una tantum che il sistema invia al suo cellulare. Qui è dove poi si parla di autenticazione a 2 fattori. Ma questo non è l'argomento qui.

Cosa sono i permessi?

Con l'autenticazione, ora sappiamo chi abbiamo di fronte. Ma cosa può fare questo utente nel sistema? È qui che entra in gioco l'autorizzazione , cioè l'assegnazione di autorizzazioni rispetto ai dati e alle funzioni contenute nel sistema. Ora diventa un po' più complicato (almeno da un punto di vista tecnico). Fondamentalmente, si definisce un insieme di autorizzazioni di base (chiamate anche permessi ). Da questo piatto si assegnano poi una serie di permessi all'utente. Finora tutto bene. Ma cos'è esattamente un permesso?

Questa è la prima grande sfida di questo argomento. Un'autorizzazione può essere definita in molti modi diversi. Alcuni esempi:

• Visualizza un progetto
• modificare un compito
• generare un rapporto
• creare un nuovo utente
• assegnare un'autorizzazione

Solo l'ultimo esempio mostra che i permessi funzionano anche in modo ricorsivo: Possiamo definire dei permessi che permettono di concedere ulteriori permessi.... Ma i primi esempi sono anche interessanti, perché ci mostrano che un permesso di solito agisce su un tipo di oggetto (un progetto, un compito, un rapporto, ecc.) e comporta un'azione (visualizzare, modificare, generare, ecc.). Quindi fondamentalmente possiamo semplicemente elencare tutti i tipi di oggetti dati nel nostro sistema e prendere tutte le azioni possibili per questo. Le combinazioni di queste risultano poi nell'insieme di base delle autorizzazioni. Per quanto questo sia semplice da scrivere, è complesso nella realtà. Anche i semplici sistemi di archiviazione dei dati contengono decine di tipi di oggetti e molte azioni diverse sono possibili su di essi. La semplice moltiplicazione di questi insiemi porta a un'esplosione di possibilità. Aggiungete a questo il fatto che vorreste naturalmente concedere permessi su oggetti individuali (cioè istanze di tipi di oggetti). Per esempio "cambiare il progetto X", non generalmente "cambiare i progetti". Questo aggiunge un'altra dimensione di complessità.

Questa pletora di permessi deve essere ben strutturata per poterla gestire e tenerne traccia. Quello che possiamo fare, per esempio, è quanto segue. I permessi possono essere collegati tra loro in una struttura ad albero. Un permesso B può essere definito come un ramo di un permesso A. In questo modo esprimiamo che se un utente è autorizzato a fare B, allora implicitamente è anche autorizzato a fare A. Ancora un semplice esempio: "B = modificare un progetto" e "A = modificare un compito". Quindi se un utente è autorizzato a modificare un progetto, allora implicitamente dovrebbe anche modificare tutti i compiti contenuti. Questo può essere fatto in modo simile con le azioni: "B = modificare un progetto" e "A = visualizzare un progetto". Anche qui, il permesso B implica il permesso A, cioè se qualcuno è autorizzato a modificare un progetto, allora è anche autorizzato a vederlo (chiaramente).

Come fa un utente ad avere i suoi permessi?

Quindi supponiamo di aver definito e strutturato l'insieme di base delle autorizzazioni e quindi di conoscerle. Come faccio ora ad assegnarli ad un utente? A prima vista, si potrebbe fare un'assegnazione diretta. Per esempio: "L'utente Meier ha i permessi B, D, E e H". Questo è facile da capire - ma solo perché l'esempio è così banale. Di nuovo, la complessità sta nel numero di combinazioni possibili. Se abbiamo decine o addirittura centinaia di utenti e molte volte più permessi, abbiamo a che fare con tabelle di permessi esorbitantemente grandi. La visione d'insieme è quindi garantita per essere sparita. Il problema può essere eliminato se ci si accontenta solo di un piccolo set di permessi di base. Ma per esperienza possiamo dire che ogni acquirente di tali sistemi software richiede così tanta flessibilità in termini di "controllo e monitoraggio degli accessi" che è necessaria una soluzione migliore.

La soluzione migliore è quella che funziona con i rulli . Questo approccio risale ai primi anni '90 e si è dimostrato nella pratica. È usato in molti, se non nella maggior parte dei sistemi di gestione dei dati. Questo approccio è conosciuto come controllo d'accesso basato sui ruoli (RBAC). Il principio può essere spiegato così: Definiamo diversi ruoli (per esempio project manager, portfolio manager, amministratore di sistema) e poi assegniamo i permessi a questi ruoli. Solo allora prendiamo gli utenti e diamo loro uno o più ruoli. In questo modo, gli utenti ottengono i loro permessi indirettamente attraverso i loro ruoli. Questo principio ha il grande vantaggio di poter gestire più facilmente l'interazione tra utenti e permessi, soprattutto in caso di modifiche. E come tutti sappiamo, ci sono spesso dei cambiamenti. Così, se voglio revocare il permesso dei project manager di cambiare progetto, lo faccio sul ruolo "project manager". Tutti gli utenti con questo ruolo hanno immediatamente le autorizzazioni modificate.

È quindi necessaria la giusta struttura

È il gran numero di possibilità per definire le autorizzazioni e assegnarle agli utenti che rende la questione così complessa. Tuttavia, con una struttura sofisticata, cioè un buon concetto di autorizzazione, possiamo affrontare questa grande sfida. Le spiegazioni di cui sopra graffiano solo la superficie dell'argomento e il semplice esempio dell'introduzione dei ruoli non vuole assolutamente dare l'impressione che questa sia l'ultima parola in fatto di saggezza. È un approccio possibile e buono. Quello che non abbiamo affrontato qui è la visualizzazione di tutti gli stati e le funzionalità del sistema dal punto di vista dell'utente. Come può un amministratore di sistema mantenere facilmente gli utenti, i ruoli e i permessi ed essere sempre sicuro di aver fatto le impostazioni giuste? Andremo in fondo a questa domanda in un prossimo articolo e mostreremo come risolvere questo problema usando PQFORCE. Quindi rimanete sintonizzati.