Gestione utenti

In una delle prime lezioni si era visto che per poter accedere al server era necessario avere a disposizione delle credeziali utente, configurabili nel file orientdb-server-config.xml presente nella cartella config. Questa lezione si focalizza invece sui permessi utente legati all'accesso ai singoli database, e alle autorizzazioni concesse in merito alle operazioni da poter
svolgere al loro interno.

Utenti e ruoli

Il sistema di sicurezza di OrientDB è imperniato su due concetti chiave: utente e ruolo. Gli utenti sono tutti quei soggetti che hanno accesso ad un database, qualunque tipo di operazione debbano svolgere. Un ruolo è un profilo di accesso costituito da due elementi: il working mode ed un insieme di regole.

Il working mode rappresenta una generale disciplina di comportamento
dell'utente e può essere di due tipi:

• allow all but: è tutto consentito, tranne ciò che è esplicitamente vietato;
• deny all but: è tutto vietato, tranne ciò che è esplicitamente consentito.

Il primo è evidentemente il working mode per utenti speciali, mentre il secondo è più adeguato agli utenti comuni (che hanno meno privilegi). Le regole associate al ruolo indicano invece cosa un utente può fare in riferimento ad una risorsa (dove per "risorsa", si vedrà, è inteso qualunque elemento del database - classi, cluster, hook, query, etc.).

Ogni database creato viene dotato sin da subito di tre utenti di default:

• admin: il superutente che può svolgere qualunque operazione;
• reader: utente in sola lettura, può leggere tutti i record ma non modificare nulla;
• writer: possiede pari permessi dell'utente reader, con l'aggiunta delle capacità di inserimento, modifica e cancellazione dei record.

Ai tre, corrispondono altrettanti ruoli con il medesimo nome che ne definiscono i permessi. La password per i tre utenti è inizialmente identica allo username. Infine, è bene sapere che un utente OrientDB può avere solo due stati: suspended o active.

Utenti e ruoli sono memorizzati in due cluster collegati alle classi OUser e ORole, quindi la gestione utenti può essere eseguita con normali comandi SQL.

Gestione utenti con SQL

Con la seguente query possiamo avere l'elenco degli utenti presenti nel database:

SELECT FROM OUser

Grazie all'output fornito, vedremo che un utente viene definito da quattro elementi: il nome, la sua password codificata con SHA-256 (o con PBKDF2 a partire dalla versione 2.2 del DBMS), lo stato (suspended o active) ed il collegamento con i ruoli. Con il seguente comando INSERT, si può creare un nuovo utente profilato come writer:

INSERT INTO OUser SET name = 'nuovoutente', password = 'parolachiave', status = 'ACTIVE', roles = (SELECT FROM ORole WHERE name = 'writer')

Si potrà ad esempio rinominare un utente con un semplice UPDATE:

UPDATE OUser SET name='utente' WHERE name='reader'

È interessante notare come per cambiare la password si può fare un UPDATE fornendo la nuova parola chiave in chiaro: prima del salvataggio del valore, un hook si occuperà di codificarla con la corretta funzione di hash:

UPDATE OUser SET password='ilmiosegreto' WHERE name='reader'

Visualizzando subito dopo il contenuto della classe OUser, troveremo la password dell'utente reader correttamente codificata e pertanto non leggibile.

Per quanto riguarda la gestione dei ruoli, si deve prima di tutto creare un nuovo record nella classe ORole, assegnandogli nome e working mode, successivamente si assegnano le singole regole. Il parametro mode della classe ORole viene valorizzato a 0 se si tratta di un ruolo deny all but, mentre sarà valorizzato a 1 nel caso di un ruolo allow all but:

// working mode deny-all-but
INSERT INTO ORole SET name = 'nuovoruolo', mode = 0
// working mode allow-all-but
INSERT INTO ORole SET name = 'nuovoruolo', mode = 1

Fatto ciò sarà necessario configurare le regole che costituiranno le eccezioni alla politica generale del working mode. Per ogni regola indicheremo un codice che rappresenta il tipo di permesso posseduto e la risorsa su cui esso agisce. I permessi, con relativo codice, sono:

Permesso	Codice
NONE	0
CREATE	1
READ	2
UPDATE	4
DELETE	8
ALL	15

Le risorse vengono invece definite da una costante, il cui nome è case-sensitive, che rappresenta tutti i vari aspetti del DBMS; eccone alcune:

• database: rappresenta l'accesso generico al database;
• database.class.nome-della-classe: indica una classe come risorsa. Ad esempio, database.class.Persona indica la classe Persona come oggetto del permesso che si sta configurando. Si può usare database.class.* per riferirsi al sistema delle classi in generale;
• database.cluster.nome-del-cluster: permette di regolare l'accesso ai cluster per la memorizzazione fisica dei dati. L'uso è analogo alla risorsa database.class;
• altre risorse regolano l'esecuzione di funzionalità operative come database.query per quanto riguarda le interrogazioni ai database, database.command per i comandi in generale e database.function per le funzioni.
• altre risorse sono di carattere sistemistico, come server.admin per l'amministrazione del server in generale e database.config per accedere alla configurazione.

Se volessimo, ad esempio, permettere al ruolo che stiamo creando di inserire record nella classe Persona, dovremmo impartire il seguente comando:

UPDATE ORole PUT rules="database.class.Persona", 1 WHERE name="nuovo"

dove nuovo è il nome del ruolo, e 1 indica il permesso di CREATE.

Infine, considerando che un nuovo ruolo ha molti aspetti da configurare, non solo per l'interazione con i dati ma proprio nella gestione del rapporto con il server, è possibile creare un ruolo che ne estenda un altro. Se volessimo, ad esempio, basare il profilo sviluppatore su writer, potremmo usare il seguente comando:

UPDATE ORole SET inheritedRole = (SELECT FROM ORole WHERE name = 'writer') WHERE name = 'sviluppatore'

GRANT e REVOKE

I comandi SQL permettono di configurare utenti e ruoli come si vuole, è sufficiente conoscere la struttura delle classi OUser e ORole. Esistono però due comandi che possono agevolare molto il lavoro, rendendolo più intuitivo: si tratta di GRANT e REVOKE; il primo assegna permessi, il secondo li revoca.

I due comandi si usano nel medesimo modo:

GRANT permesso ON risorsa TO ruolo
REVOKE permesso ON risorsa TO ruolo

dove permessi e risorse vengono descritti con le costanti che abbiamo visto poco fa. Ad esempio, per assegnare permesso di scrittura sulla classe Persona al ruolo sviluppatore:

GRANT CREATE ON database.class.Persona TO sviluppatore

mentre per revocarlo:

REVOKE CREATE ON database.class.Persona TO sviluppatore