Prima di introdurre l’implementazione vera e propria, presentiamo lo schema del database per la parte riguardante la gestione degli utenti (Figura 6.2). I campi contrassegnati dalla sigla PK, si riferi-scono alle chiavi primarie (tutte le tabelle utilizzano id numerici auto-incrementanti), quelli con la sigla FK si riferiscono invece alle chiavi esterne, U indica un indice univoco. Tutti i campi in gras-setto sono obbligatori. Segue la descrizione delle singole tabelle:
users: qui vengono raccolti tutti i dati relativi all’utente (credenziali, ruolo, dati anagrafici, ecc.). Il campo username deve essere univoco per evitare duplicazioni di credenziali. Tra i vari campi citiamo psw_created e psw_expires. Il primo contiene la data di creazione dell’attuale password utente e servirà a eseguire i controlli di scadenza della stessa, come stabilito dall’allegato B relativo al testo unico sulla privacy (vedi paragrafo 1.7.1); il secondo invece è un booleano che stabilisce se la password dell’utente è soggetta a scadenza (il valore di default è impostato a vero).
passwords: in questa tabella vengono salvate le vecchie password (cifrate) di ogni singolo utente e la data di creazione di tale password (i.e. quando è stato effettuato il cambio pas-sword). Questa tabella non contiene la password attualmente in uso dall’utente, che invece
85
è salvata nella tabella users. Ciò è stato fatto per semplificare e velocizzare la procedura di autenticazione, evitando un dispendioso JOIN tra le due tabelle. Ogni password è legata al suo utente dal campo id_user, che fa da chiave esterna con la tabella users.
User related tables (v. 1)
users PK id U1 username password psw_created psw_expires FK1 id_group surname name address email phone groups PK id name status grants PK id U1 code description groups_grants PK id FK1 id_grant FK2 id_group enable users_grants PK id FK1 id_grant FK2 id_user enable passwords PK id FK1 id_user password created
Figura 6.2. Prima versione dello schema delle tabelle utente.
groups: qui sono elencati i vari ruoli (o gruppi) utente. A ogni gruppo sono associati de-terminati permessi, secondo il modello Role-Based Access Control, descritto al paragrafo 3.5.2. Ogni utente è associato a uno di questi gruppi tramite la chiave esterna id_group.
grants: questa tabella elenca i singoli permessi. Ogni permesso è identificato univocamente da un codice facilmente intellegibile e memorizzabile (per esempio INSPRENO, che sta per “inserimento prenotazione”). Il sistema di autorizzazione fa riferimento a tali codici per il controllo degli accessi.
groups_grants: in questa tabella ogni gruppo (chiave esterna FK2, id_group) è associato a ogni singolo permesso (chiave esterna FK1, id_grant), il quale può essere attivato o
disatti-86
vato per quel gruppo, tramite il campo enable. Questa tabella presenta sempre record.
users_grants: questa tabella è analoga alla precedente, ma si riferisce ai permessi utente. Ogni singolo utente può avere degli specifici permessi in più rispetto al gruppo a cui appar-tiene (privilegi) o in meno (negazioni). A differenza della tabella groups_grants che ha sempre record, il numero di righe di questa tabella dipende esclusi-vamente dal numero di privilegi/negazioni assegnati agli utenti.
Tutte le relazioni tra le tabelle sono N-a-1, vale a dire che esistono, per esempio, N password per ogni utente, N utenti per ogni gruppo, N permessi di gruppo per ogni gruppo, N permessi utente per ogni permesso, ecc.
Carico dei volumi e delle operazioni
Segue una stima tecnica dei volumi delle tabelle:
users: un record per utente, quindi approssimativamente un centinaio.
passwords: raccoglie record per utente, dove è il numero di password memorizzate dell’utente . Si ha quindi un totale di ∑ record. Ipotizzando che tutti gli utenti cambino la password ogni tre mesi (come previsto dalle norme minime di sicurezza del testo unico sulla privacy, par. 1.7.1), si ottengono nuovi record all’anno. Supponendo di avere all’incirca un centinaio di utenti, questo si traduce in circa 400 righe all’anno, cifra più che sostenibile. L’assunzione di avere un cambio password ogni tre mesi non ci appare eccessivamente ottimistica, in quanto l’utente solitamente, evita il più possi-bile di cambiare password, soprattutto se questo implica doverne inserire una diversa dalle precedenti. Supponendo comunque un cambio di password ogni mese, il valore tripliche-rebbe a 1200 righe l’anno. In 10 anni di attività si avtripliche-rebbero quindi “solamente” 120.000 record, valore facilmente sostenibile dai moderni DBMS. Va specificato comunque, che so-litamente i controlli sulle password coinvolgono al più le ultime 10, di conseguenza un’eliminazione periodica delle password più vecchie e ormai inutili, ridurrebbe ulterior-mente il volume della tabella.
groups: un record per gruppo. Il numero dei gruppi è spesso molto ristretto (inferiore a 10).
grants: un record per permesso. È difficile stimare il numero di permessi da inserire, tutta-via si può stimare con elevata probabilità che difficilmente supererà qualche centinaio di re-cord. Attualmente Crono adotta 31 permessi.
groups_grants: come già specificato, in questa tabella sono sempre presenti record. Ipotizzando un numero di utenti e di permessi sull’ordine delle centi-naia, si ha un totale di 10.000 record.
users_grants: una buona strutturazione dei permessi di gruppo permette di ridurre al mi-nimo la necessità di aggiungere permessi utente, mantenendo questa tabella molto contenu-ta. In ogni caso, il volume di tale tabella è certamente strettamente inferiore a quella di
groups_grants.
87
Operazione Tipo Frequenza
Reperimento informazioni utente/gruppo Select >100 al giorno
Cambio password Select ≤1 al mese
Reperimento informazioni permessi Select >100 al giorno Inserimento/modifica utente Update/Insert Raramente Inserimento/modifica nuovo gruppo Update/Insert Raramente Inserimento/modifica nuovo permesso Update/Insert Raramente A parte durante la prima fase di popolamento, i successivi inserimenti e modifiche sono piuttosto rari. Se si considera un bacino di utenza di circa un centinaio di utenti, appare evidente che il mag-gior carico ha a che fare con l’acquisizione dei dati e dei permessi utenti, necessari al corretto fun-zionamento del sistema. Vedremo nel paragrafo successivo come limitare l’accesso al database utiliz-zando una struttura a oggetti per la gestione dei dati e dei permessi utente.
Il recupero dei permessi, è forse l’operazione più impegnativa dell’intera struttura dati, coinvolgen-do ben quattro tabelle: users, grants, groups_grants e users_grants. Va inoltre eseguita in due tempi: prima va recuperato l’array di permessi legati al gruppo, quindi si controlla la tabella
users_grants per verificare l’esistenza di privilegi o negazioni a livello di utente e, se presenti, si sovrascrivono i vecchi permessi. In particolare le due query sono:
SELECT * FROM groups_grants JOIN grants ON (groups_grants.id_grant = grants.id) WHERE groups_grants.id_group = $id_group
SELECT * FROM users_grants JOIN grants ON (users_grants.id_grant = grants.id) WHERE users_grants.id_user = $id
Dove $id_group e $id sono rispettivamente l’id del gruppo a cui appartiene l’utente e l’id dell’utente (entrambi dei quali sono contenuti nel record utente).