Tesi - Amicofragile

UNIVERSITÀ DEGLI STUDI DI BRESCIA
FACOLTÀ DI INGEGNERIA
CORSO DI LAUREA SPECIALISTICA IN INGEGNERIA
INFORMATICA
DIPARTIMENTO DI ELETTRONICA PER L’AUTOMAZIONE
CONTROLLO D’ACCESSO BASATO SU RUOLI
(RBAC) IN UN APPLICATION SERVER J2EE
(JAVA 2 ENTERPRISE EDITION): STUDIO ED
IMPLEMENTAZIONE
Studente:
Giacomo Carlotti
Matricola: 52916
Relatore:
prof. Pietro Baroni
Correlatori:
ing. Andrea Mauro
ing. Pietro Martinelli
ANNO ACCADEMICO 2004/2005
A mia madre e
a mio padre
Pagina 2
Ringraziamenti
Ringrazio sentitamente il prof. Pietro Baroni e l’ing. Andrea Mauro per la stima e
la fiducia che hanno dimostrato avere nei miei confronti.
Un ringraziamento particolare va all’ing. Pietro Martinelli per la sua
disponibilità ed i suoi preziosi consigli.
Pagina 3
INDICE
INDICE....................................................................................................... 4
CAPITOLO 1 INTRODUZIONE............................................................. 11
1.1
Il contesto della tesi: la sicurezza dell’informazione............................ 12
1.2
Le proprietà della sicurezza dell’informazione.................................... 14
1.2.1
Autenticazione .................................................................................. 14
1.2.2
Controllo degli accessi / Autorizzazione........................................... 14
1.2.3
Confidenzialità (privacy e segretezza) .............................................. 15
1.2.4
Integrità ............................................................................................. 15
1.2.5
Responsabilità & Non ripudio........................................................... 16
1.2.6
Disponibilità...................................................................................... 17
1.3
Politiche, modelli e meccanismi ............................................................. 18
1.4
Gli obiettivi della tesi .............................................................................. 20
1.5
Il piano di lavoro ..................................................................................... 21
CAPITOLO 2 IL CONTROLLO D’ACCESSO TRADIZIONALE ........... 23
2.1
Il controllo d’accesso............................................................................... 24
2.1.1
2.2
L’ontologia di base............................................................................ 24
I principi fondamentali ........................................................................... 25
2.2.1
Il minimo privilegio (Least privilege)............................................... 26
2.2.2
La separazione dei compiti (Separation of duty) .............................. 26
2.3
Breve storia del controllo d’accesso tradizionale ................................. 27
2.3.1
Matrice di controllo........................................................................... 28
2.3.2
Reference monitor e security kernel ................................................. 29
2.3.3
Il modello di Bell-LaPadula .............................................................. 31
Pagina 4
2.3.4
Modello d’integrità di Biba............................................................... 32
2.3.5
TCSEC: il MAC e il DAC ................................................................ 33
2.3.5.1
DAC (Discretionary Access Control) ........................................... 33
2.3.5.2
MAC (Mandatory Access Control)............................................... 34
2.3.6
Modello di Clark e Wilson................................................................ 35
2.3.7
Politica del muro cinese e modello di Brewer e Nash ...................... 36
CAPITOLO 3 IL MODELLO RBAC ORIGINALE.................................. 39
3.1
Il primo modello RBAC.......................................................................... 40
3.1.1
Utenti, ruoli ed operazioni ................................................................ 40
3.1.2
Gerarchie di ruoli .............................................................................. 41
3.1.3
Descrizione formale .......................................................................... 43
3.1.4
Il principio del minimo privilegio..................................................... 45
3.1.5
Separazione dei compiti .................................................................... 45
3.2
Differenza tra ruoli e gruppi .................................................................. 46
3.3
Confronto tra RBAC, MAC e DAC....................................................... 47
3.3.1
RBAC vs DAC.................................................................................. 47
3.3.2
RBAC vs MAC ................................................................................. 48
CAPITOLO 4 RBAC96 FRAMEWORK ................................................ 49
4.1
Il framework RBAC................................................................................ 50
4.2
Panoramica dei modelli .......................................................................... 50
4.2.1
RBAC0 .............................................................................................. 51
4.2.2
RBAC1 .............................................................................................. 52
4.2.3
RBAC2 .............................................................................................. 55
4.2.4
RBAC3 .............................................................................................. 55
4.3
Descrizione formale................................................................................. 56
4.3.1
RBAC0 .............................................................................................. 56
4.3.2
RBAC1 .............................................................................................. 57
Pagina 5
4.3.3
RBAC2 .............................................................................................. 57
4.3.4
RBAC3 .............................................................................................. 57
CAPITOLO 5 LO STANDARD RBAC PROPOSTO DAL NIST............ 59
5.1
Presentazione dello standard ................................................................. 60
5.2
Panoramica dei modelli .......................................................................... 60
5.2.1
Core RBAC ....................................................................................... 61
5.2.2
Hierarchical RBAC ........................................................................... 62
5.2.3
Constrained RBAC ........................................................................... 64
5.2.3.1
Static Separation of Duty (SSD) ................................................... 64
5.2.3.2
Dynamic Separation of Duty (DSD) ............................................. 65
5.3
Modello concettuale ................................................................................ 66
5.3.1
Core RBAC ....................................................................................... 67
5.3.2
Hierarchical RBAC ........................................................................... 69
5.3.3
Constrained RBAC ........................................................................... 71
5.4
Specifiche funzionali ............................................................................... 72
5.4.1
Core RBAC ....................................................................................... 73
5.4.2
Hierarchical RBAC ........................................................................... 75
5.4.3
Static Separation of Duty (SSD) ....................................................... 77
5.4.4
Dynamic Separation of Duty (DSD) ................................................ 78
5.5
I packages................................................................................................. 79
CAPITOLO 6 ANALISI CRITICA DEL MODELLO ............................... 83
6.1
Attivazione e disattivazione dei ruoli .................................................... 84
6.2
Le gerarchie ............................................................................................. 85
6.2.1
Gerarchia ed attivazione dei ruoli ..................................................... 86
6.2.2
Gerarchia e disattivazione dei ruoli................................................... 86
6.2.3
Gerarchia e separazione dei compiti ................................................. 88
6.2.4
Gerarchia e permessi ......................................................................... 90
Pagina 6
6.3
Separazione dei compiti e permessi ....................................................... 92
6.4
I permessi in un sistema ad oggetti........................................................ 93
6.5
Aggiunta e rimozione di elementi del modello...................................... 95
6.6
I vincoli..................................................................................................... 96
6.6.1
GTRBAC (Generalized Temporal RBAC) ....................................... 96
6.6.2
La separazione dei compiti storica.................................................... 97
6.6.3
Tassonomia dei vincoli ..................................................................... 98
6.6.4
I vincoli in un sistema ad oggetti .................................................... 101
6.7
Il formato dei vincoli............................................................................. 102
6.7.1
XACML 2.0 (eXtensible Access Control Markup Language)........ 103
6.7.2
La mutua esclusione........................................................................ 104
6.7.3
La Blacklist di Crampton ................................................................ 105
CAPITOLO 7 ESTENSIONE DEL MODELLO: UNA PROPOSTA..... 108
7.1
Premessa ................................................................................................ 109
7.2
L’architettura ........................................................................................ 109
7.2.1
Parte statica ..................................................................................... 111
7.2.2
Parte dinamica................................................................................. 112
7.3
L’attivazione dei permessi.................................................................... 114
7.4
Le scelte di definizione del modello ..................................................... 117
7.5
Il framework .......................................................................................... 119
7.5.1
Le funzioni ...................................................................................... 119
7.5.2
I packages........................................................................................ 121
CAPITOLO 8 LA TECNOLOGIA J2EE .............................................. 122
8.1
La piattaforma J2EE ............................................................................ 123
Pagina 7
8.2
L’architettura J2EE.............................................................................. 124
8.3
L’Application Programming Model.................................................... 127
8.3.1
Livello Client .................................................................................. 129
8.3.2
Livello Web..................................................................................... 129
8.3.3
Livello Business .............................................................................. 130
8.3.4
Livello EIS ...................................................................................... 131
8.4
Le API J2EE .......................................................................................... 132
8.4.1
JDBC (Java DataBase Connectivity) .............................................. 132
8.4.2
RMI (Remote Method Invocation).................................................. 135
8.4.3
Java IDL (Interface Definition Language)...................................... 136
8.4.4
JNDI (Java Naming and Directory Interface) ................................. 137
8.4.5
JMS (Java Message Service)........................................................... 137
8.5
Servlet API: il package javax.servlet................................................... 137
8.5.1
HttpServletResponse ....................................................................... 140
8.5.2
HttpServletRequest ......................................................................... 140
8.5.3
Sessioni utente................................................................................. 140
8.5.3.1
HttpSession ................................................................................. 141
8.5.3.2
Durata di una sessione utente...................................................... 142
8.5.4
Filter ................................................................................................ 142
8.5.5
Eventi di tipo HTTP session ........................................................... 143
8.6
JSP (Java Server Pages) ....................................................................... 144
8.6.1
8.7
Compilazione di una pagina JSP..................................................... 144
Autorizzazione in J2EE ........................................................................ 145
8.7.1
Modello di autorizzazione di base................................................... 145
8.7.2
JAAS (Java Authentication and Authorization Service)................. 146
CAPITOLO 9 L’IMPLEMENTAZIONE DEL MODELLO ESTESO...... 148
9.1
Motivazioni ............................................................................................ 149
Pagina 8
9.2
Architettura del sistema ....................................................................... 150
9.3
I package ................................................................................................ 153
9.4
Descrizione dell’implementazione ....................................................... 156
9.4.1
Il web plug-in .................................................................................. 157
9.4.2
Il motore statico .............................................................................. 159
9.4.3
Il motore dinamico .......................................................................... 161
9.4.4
Il gestore e il monitor delle sessioni................................................ 164
9.4.5
Note implementative ....................................................................... 165
9.5
Il database .............................................................................................. 165
9.5.1
9.6
I vincoli supportati ed il loro formato ............................................. 166
I tool amministrativi ............................................................................. 167
9.6.1
AdminTool ...................................................................................... 167
9.6.2
SessionMonitor ............................................................................... 169
9.7
I file di configurazione .......................................................................... 170
CAPITOLO 10
10.1
TEST E CONCLUSIONI ............................................. 172
Testing .................................................................................................... 173
10.1.1
Motore statico: Casi d’uso .............................................................. 174
10.1.2
Motore Statico: Casi d’uso.............................................................. 177
10.1.3
Risultati ........................................................................................... 177
10.2
Considerazioni finali ............................................................................. 178
10.3
L’attualità del tema............................................................................... 179
10.4
Sviluppi futuri ....................................................................................... 181
INDICE DELLE FIGURE ....................................................................... 182
INDICE DELLE TABELLE .................................................................... 184
Pagina 9
BIBLIOGRAFIA E RIFERIMENTI.......................................................... 185
APPENDICE A JAVADOC ................................................................... 195
APPENDICE B.1 DIAGRAMMI UML DEI PACKAGES ....................... 196
APPENDICE B.2 DIAGRAMMI UML DELLE CLASSI......................... 197
Pagina 10
CAPITOLO 1
INTRODUZIONE
Prima di entrare nel dettaglio delle attività
svolte per il raggiungimento degli obiettivi della
tesi viene fornita una breve descrizione del
contesto in cui essa si pone, in modo da
inquadrare correttamente dal punto di vista
concettuale il lavoro effettuato. A questo scopo
verranno elencati in modo ordinato ed organico
gli obiettivi della presente trattazione ed infine
verrà illustrato il piano di lavoro seguito
durante lo svolgimento delle diverse attività
necessarie
alla
realizzazione
dell’intero
progetto.
Pagina 11
1.1 Il contesto della tesi: la sicurezza
dell’informazione
Non è certo necessario dimostrare che al giorno d’oggi una parte sempre maggiore
delle attività umane viene realizzata, controllata, o coadiuvata dall'utilizzo di
sistemi informatici. Per questa ragione risulta particolarmente importante
comprendere quanto siano sicuri questi sistemi. Il problema ovviamente diviene
sempre più critico, mano a mano che il valore delle informazioni scambiate in
forma digitale cresce.
La sicurezza dell'informazione ha attraversato un lungo periodo di gestazione in
cui veniva considerata un'arte più che una scienza, da apprendere tramite
l'esperienza e non tramite lo studio. Solo pochi studi pionieristici stendevano le
basi dei metodi formali che negli ultimi anni sono stati sviluppati. Questo, unito
all'intrinseca difficoltà della materia, spiega il motivo per cui gran parte degli
approcci al tema della sicurezza dell'informazione sono basati su esperienza e
conoscenza euristica più che su tecniche raffinate. Il principale settore della
sicurezza che vanta una lunga tradizione nell'uso dei metodi formali è il campo
della crittografia, che non sorprendentemente è molto più avanzato e stabile degli
altri.
Se questo metodo pragmatico di procedere ha funzionato per anni, lo sviluppo
esplosivo dei sistemi collegati in rete e di dispositivi con potenza e versatilità
francamente inimmaginabili solo pochi anni fa ha reso necessario e urgente lo
sviluppo di un'ingegneria della sicurezza informatica, dove il termine “ingegneria”
va inteso nel suo senso tradizionale di scienza applicata, con definizione formale
di concetti, metodi e tecniche conosciute, esplorate da una ampia letteratura
scientifica, e globalmente diffuse.
Per capire che cos'è la sicurezza informatica è necessario prima di tutto conoscere
in modo chiaro la differenza ed il rapporto che esiste tra dati ed informazioni,
ovvero i due elementi centrali attorno a cui la sicurezza informatica nasce ed
acquista significato: i dati rappresentano le informazioni, mentre le informazioni
sono la conoscenza contenuta nei dati. Le informazioni sono la base su cui viene
Pagina 12
condotta l'attività economica, cioè sono politicamente, commercialmente e
personalmente sensibili per lo sviluppo aziendale. Per questi motivi le
informazioni sono un bene di grande valore per l'azienda e devono essere protette
adeguatamente.
La “Sicurezza” è tutto ciò che riguarda la protezione dei beni aziendali e quindi la
sicurezza informatica (o dell'informazione) è il ramo della Sicurezza focalizzato
sulla protezione di questo particolare tipo di bene. Questa definizione implica che
l'azienda conosca con precisione tutti i propri beni ed il loro valore, ma
l'esperienza insegna che nella complessità di una realtà aziendale in molti casi non
è così. Questa osservazione generale è assolutamente vera anche per la sicurezza
informatica, ecco perché l'analisi dei rischi è parte integrante e necessaria della
strategia di sviluppo della sicurezza informatica e non.
Per quanto le tecniche fino ad oggi elaborate possano offrire alti standard di
sicurezza, queste non sono infallibili e soprattutto non possono uscire dai confini
del sistema stesso. Per questo motivo il concetto di “sicurezza dell’informazione”
deve essere esteso ben oltre l’informatica in senso ristretto, ovvero l’hardware, il
software e le reti di computer, andando a interessarsi dell’intero processo di
gestione dei dati e delle informazioni messo in atto da un’organizzazione.
Rientrano quindi a pieno titolo nell’ingegneria della sicurezza anche
considerazioni di sicurezza ambientale, gestione dell’informazione non digitale,
procedure nella gestione delle risorse umane, eccetera. In effetti, i filtri della
sicurezza dell’informazione operano come un’interfaccia tra le persone ed i
processi del sistema e devono gestire entrambe le variabili. Come si può
immaginare, si tratta di un processo complesso, costoso ed esposto a sviste anche
gravi.
Alla luce dei concetti esaminati possiamo dunque definire la sicurezza informatica
come il connubio di prevenzione e individuazione di azioni non autorizzate verso
il sistema informatico. Gli obiettivi di prevenzione ed autorizzazione si
concretizzano nelle “Politiche di sicurezza” e nei “Meccanismi di sicurezza”,
ovvero un insieme di regole e procedure che sanciscono a tutti i livelli quali azioni
sono permesse e quali proibite.
Pagina 13
1.2 Le
proprietà
della
sicurezza
dell’informazione
Sia nella letteratura accademica che nella pratica gli obiettivi della sicurezza
dell'informazione sono normalmente descritti in termini di autenticazione,
controllo degli accessi (o autorizzazione), confidenzialità (privacy e segretezza),
integrità, responsabilità, non ripudio e disponibilità. I paragrafi seguenti
forniscono una panoramica di ognuna delle proprietà appena elencate.
1.2.1
Autenticazione
L’autenticazione è il processo che permette di determinare con certezza l’identità
di un utente del sistema.
Ovviamente questo processo può essere più o meno sicuro e di conseguenza la
probabilità di autenticare correttamente un utente può essere più o meno alta a
seconda delle differenti implementazioni del sistema. Generalmente un soggetto
che desidera autenticarsi deve provare di conoscere un certo dato oppure deve
possedere un determinato “oggetto”. Il sistema deve essere in grado di riconoscere
queste informazioni come valide ed utilizzarle per identificare in modo univoco
l’utente.
Va infine sottolineato il fatto che, anche se fino ad ora si è sempre parlato di
“utente”, non è detto che questo sia necessariamente una persona, come la parola
lascia intendere. Infatti a seconda del contesto in cui ci si trova ad operare è
possibile autenticare ad esempio un applicativo, un calcolatore, un nodo di rete,
un pacchetto IP ed altre numerose e disparate tipologie di entità.
1.2.2
Controllo degli accessi / Autorizzazione
Il controllo degli accessi è il processo che permette di definire e controllare i
diritti e i privilegi di accesso alle risorse e ai servizi del sistema.
Questo processo necessita ovviamente di una qualche forma di autenticazione per
poter funzionare, in quanto assume che l’identità dell’utente sia già stata verificata
a monte. Quello che è necessario fare nell’ambito del controllo d’accesso è
Pagina 14
verificare se un soggetto ha o meno i permessi per accedere a certi dati del sistema
e/o compiere determinate operazioni su di essi.
Questo è proprio il tema centrale della presente trattazione, se ne parlerà quindi
ampiamente nei capitoli successivi.
1.2.3
Confidenzialità (privacy e segretezza)
La confidenzialità è la proprietà che permette di garantire che l’accesso alle
risorse e ai servizi del sistema sia permesso solo alle entità autorizzate.
Questa definizione in realtà può essere mal interpretata e può far pensare che la
confidenzialità ed il controllo d’accesso siano in pratica la stessa cosa. In realtà,
mentre lo scopo del processo di autorizzazione è quello di bloccare l'accesso a
risorse e servizi del sistema da parte di utenti non autorizzati, in questo caso il fine
principale è quello di non permettere agli utenti non autorizzati di venire a
conoscenza dell'esistenza di queste informazioni sensibili.
I termini "privacy" e "segretezza" sono a volte utilizzati per distinguere tra la
protezione dei dati personali degli utenti (privacy) e la protezione dei dati
appartenenti all'organizzazione (segretezza).
La confidenzialità è un concetto molto ben definito e la ricerca nel campo della
sicurezza informatica si è spesso concentrata su questo punto, tanto che alle volte i
termini confidenzialità e sicurezza sono stati perfino utilizzati come sinonimi.
1.2.4
Integrità
L’integrità consiste nel di garantire che non vengano eseguite modifiche non
autorizzate ai dati protetti contenuti nel sistema.
In altri termini l’integrità si può definire come la capacità di un sistema di rendere
possibile la modifica di risorse e dati solo a persone autorizzate, e anche a queste
solo in modo autorizzato onde garantire la consistenza di questi dati con le
funzioni gestite dal sistema.
Secondo Clark e Wilson [7] l'integrità c'e' quando: "nessun utente del sistema,
anche se autorizzato, è in grado di modificare dati, altrimenti i beni (le
informazioni) dell'azienda andrebbero persi o corrotti."
Pagina 15
Un'altra prestigiosa definizione di integrità dei dati si può trovare nell'Orange
Book [1]: "Integrità è quando i dati informatici sono identici ai dati dei documenti
originali da cui sono stati estratti, e non sono esposti ad accidentali o maliziose
alterazioni o distruzioni". In questo caso l'integrità è sinonimo di robustezza verso
l'esterno. I dati raccolti in un sistema informatico dovrebbero riflettere
esattamente delle realtà esistenti al di fuori del sistema informatico. Tuttavia è
impossibile garantire questa proprietà unicamente attraverso meccanismi interni al
sistema informatico.
Per aggiungere maggiore confusione, alcune aree della sicurezza informatica
hanno adottato la loro propria nozione di integrità; per esempio la sicurezza della
comunicazione la definisce come: la rilevazione e correzione delle modifiche,
imputazioni, cancellazioni o riproduzioni dei dati trasmessi, comprendendo
manipolazioni e casuali errori di trasmissione. Si può osservare come, partendo da
questa posizione, la presenza (o assenza) di una struttura di autorizzazione non
incida sulla natura del problema da risolvere, né sui rispettivi meccanismi di
sicurezza.
Come si può notare dalle definizioni appena riportate, è' abbastanza difficoltoso
dare una caratterizzazione precisa di integrità. In generale il termine integrità vuol
dire assicurarsi che tutto sia come deve essere. Restringendo il campo nei confini
della sicurezza informatica, quello che si deve fare in pratica è prevenire
"scritture" non autorizzate. L’integrità risiede dunque nell’"essere autorizzati a
fare ciò che stiamo facendo" e nel "seguire le corrette procedure".
Di fatto l'Integrità è spesso un prerequisito per altre proprietà della Sicurezza. Per
esempio un attaccante potrebbe cercare di aggirare i controlli per la
confidenzialità modificando il sistema operativo o la tavola di controllo degli
accessi referenziata dal sistema operativo. Quindi aver protetto l'integrità del
sistema operativo o della tavola di controllo accessi permette ad esempio la
confidenzialità.
1.2.5
Responsabilità & Non ripudio
La responsabilità è la proprietà che permette di ricollegare ogni singola azione
sull’informazione contenuta nel sistema al soggetto che l’ha compiuta.
Pagina 16
È possibile trovare questo requisito, particolarmente importante nel mondo del
commercio elettronico, in un documento storico come l'Orange Book:
"Responsabilità significa controllare le informazioni in modo selettivo e protetto,
così che azioni che influenzano la sicurezza possano essere ricollegate al diretto
responsabile".
Per essere in grado di soddisfare questo requisito il sistema deve prima di tutto
identificare ed autenticare l'utente, ma oltre a questo deve mantenere una "traccia
di verifica" degli eventi rilevanti per la sicurezza. Infatti se si verificasse una
violazione della sicurezza, le informazioni raccolte nella traccia di verifica devono
permettere di identificare il colpevole ed i passi che quest’ultimo ha compiuto per
compromettere il sistema.
A questo punto entra in gioco la proprietà del non ripudio, che assicura
l’impossibilità da parte di chi ha prodotto dei dati di negare della creazione di
questi ultimi.
Si può dunque affermare che la responsabilità implica il non ripudio, in quanto
non è possibile identificare un utente come origine di un’azione dannosa per la
sicurezza del sistema, se non si può provare con certezza la sua colpevolezza.
1.2.6
Disponibilità
Secondo la definizione del CTCPEC (Canadian Trusted Computer Product
Evaluation Criteria) [91] la disponibilità è "la proprietà secondo cui le
informazioni sono sempre accessibili senza eccessivi ritardi quando necessario".
Le definizione ISO (International Organization for Standardization) [92] è quasi
identica: è la proprietà delle informazioni di essere accessibili ed utilizzabili a
richiesta di un ente autorizzato.
Nel contesto della sicurezza si vuole dunque assicurare che la prevenzione nei
confronti degli attaccanti non impedisca agli utenti legittimi di avere un accesso
ragionevole ai loro sistemi. Questo per prevenire disturbi del servizio. Allargando
in questo campo la definizione ISO, la prevenzione diventa finalizzata a rendere
sempre disponibile l'accesso autorizzato alle risorse senza comportare dei ritardi
nelle operazioni time-critical. Infatti sono abbastanza frequenti attacchi che
paralizzano un server per sovraccarico di richieste di connessione "bloccando" la
Pagina 17
disponibilità delle informazioni, con gravi conseguenza per le realtà in cui la
disponibilità è l'aspetto principale della sicurezza informatica.
Va infine sottolineato il fatto che la disponibilità è in qualche modo un obiettivo
in conflitto con i precedenti, in quanto impone che il sistema non solo debba
garantire l’accesso soltanto agli utenti autorizzati, ma che allo stesso tempo non
possa mai negare l'autorizzazione per un accesso corretto. Inoltre, l'accesso deve
essere
consentito
tempestivamente,
dove
la
definizione
esatta
di
“tempestivamente” dipende dal dominio del problema. Esiste in letteratura il
concetto di Maximum Waiting Time proprio introdotto a questo proposito. È
necessario prestare dunque attenzione ai casi in cui una sicurezza troppo "stretta"
rischia di generare di per sé stessa disturbi/ritardi del servizio.
Spesso vengono utilizzati i termini “exposure” per indicare il fallimento nella
condizione di confidenzialità, “compromise” per il fallimento nella relazione di
integrità, e “denial of service” per la mancanza di disponibilità.
1.3 Politiche, modelli e meccanismi
Come già anticipato il progetto relativo alla tesi si inserisce nell’ambito del
controllo d’accesso. Quando si prende in considerazione un qualsiasi sistema di
controllo d’accesso, bisogna tenere presente tre aspetti differenti:
1. la politica di controllo d’accesso
2. il modello di controllo d’accesso
3. il meccanismo di controllo d’accesso
La politica (o “policy”) non è altro che un insieme di requisiti, che specificano
come dev’essere gestito l’accesso alle informazioni, ovvero chi e in quali
circostanze può fare che cosa su di esse. Le politiche di controllo d’accesso sono
molto varie e cambiano anche in modo netto da un’applicazione all’altra. Inoltre
sono dinamiche per natura, poiché cambiano nel tempo per riflettere l’evoluzione
dei diversi fattori economici, legali e sociali, che influenzano le organizzazioni
alle quali si devono applicare. Ad ogni modo, poiché le politiche non possono
essere determinate con esattezza in anticipo, i sistemi di controllo d’accesso
devono essere progettati per poter essere configurati e personalizzati, in modo da
Pagina 18
essere abbastanza flessibili per potersi adattare ad una grande varietà di politiche
di accesso.
Per rendere operative le direttive di una politica è necessario definire dei
meccanismi di controllo d’accesso, che traducano in atto i requisiti specificati da
queste ultime. Vi sono numerosi meccanismi di controllo d’accesso, ognuno dei
quali comporta dei vantaggi e degli svantaggi in termini di flessibilità e capacità
di adattarsi certe tipologie di politiche. In generale un meccanismo richiede che vi
siano degli attributi di controllo d’accesso per utenti e risorse, come ad esempio
degli identificatori, delle etichette o più in generale dei metadati. Questi elementi
vengono utilizzati dalla logica di controllo per verificare se un utente ha o meno il
diritto di compiere una certa operazione su un oggetto protetto del sistema.
Ovviamente, affinché ciò avvenga, devono essere state specificate a priori delle
regole che il meccanismo va a verificare ogni volta che è necessario. Le modalità
con cui questo insieme di regole si può definire, modificare e controllare sono un
fattore discriminante per valutare la flessibilità e l’efficacia di un meccanismo di
controllo d’accesso.
Per analizzare un sistema di controllo d’accesso e per valutarne la caratteristiche è
tuttavia preferibile ragionare su qualcosa di più astratto e concettuale di un
meccanismo. A questo scopo viene definito un modello di controllo d’accesso.
Generalmente i modelli vengono descritti in modo da prevedere numerose scelte
implementative, fornendo un framework concettuale sul quale ragionare per
capire quali requisiti delle politiche di controllo d’accesso essi possono
supportare. I modelli sono di interesse sia per gli utenti finali, che per i produttori
di software, in quanto facilitano la comunicazione fra questi ultimi essendo una
sorta di linguaggio intermedio comprensibile da entrambi. Sono quindi un ponte
tra il livello di astrazione delle politiche e quello dei meccanismi di controllo
d’accesso. Gli utenti vedono i modelli come un modo non ambiguo di definire i
requisiti di controllo d’accesso, mentre i produttori di software li utilizzano come
specifiche di design ed implementazione.
Pagina 19
1.4 Gli obiettivi della tesi
Nei paragrafi precedenti si è cercato di fornire una panoramica delle diverse
problematiche che comporta la gestione di un qualunque sistema informatico dal
punto di vista della sicurezza. Quello che si voleva mettere in luce è la grande
complessità della materia, che oltre ad abbracciare una vasta gamma di argomenti,
non è ancora formalmente consolidata in molte sue aree. La continua evoluzione
tecnologica e la proposta incalzante di modelli teorici sempre più articolati
rendono il lavoro certamente più interessante, ma allo stesso tempo lo complicano
notevolmente.
I contributi maggiori per la sicurezza informatica si sono avuti finora dalla
crittografia, una scienza che ha una storia alle spalle e che quindi ha avuto il
tempo di consolidarsi negli anni, anche se non bisogna dimenticare che gli studi in
materia sono ancora molto produttivi ed hanno ricevuto un grande impulso
proprio negli ultimi tempi. Purtroppo la crittografia non viene in aiuto quando si
parla di controllo d’accesso, in quanto si applica solamente ad alcune delle
proprietà descritte nei paragrafi precedenti, quali l’autenticazione, l’integrità, la
confidenzialità e il non ripudio.
Il problema dell’autorizzazione è stato forse quello più trascurato, anche se
ovviamente non sono mancati studi in questo campo. Tuttavia negli ultimi anni
c’è stata un’inversione di tendenza e un’attenzione sempre maggiore si è
concentrata sul controllo d’accesso. Il motivo principale è da ricercarsi nelle
dimensioni sempre crescenti dei sistemi informatici soprattutto in ambito civile,
commerciale ed industriale, che ha evidenziato come le tecniche finora
implementate non fossero del tutto adeguate per la gestione di questi tipi di
applicazioni. A questo si aggiunge l’introduzione di normative volte alla tutela
della riservatezza dei dati e della privacy degli utenti, che le aziende si trovano a
dover rispettare in tempi molto brevi. Per tutti questi motivi la perdita di risorse,
espressa in ore uomo, per la gestione e l’amministrazione dei sistemi informatici
si è fatta sempre maggiore e la necessità di studiare nuove tecniche per migliorare
la situazione si è fatta più pressante rispetto al passato, essendo ora spinta anche
da esigenze economiche.
Pagina 20
Si arriva dunque all’argomento centrale della tesi, ovvero al controllo d’accesso
basato su ruoli, l’RBAC (Role Based Access Control). Questo modello è stato
proposto per la prima volta agli inizi degli anni Novanta per venire incontro alle
esigenze delle organizzazioni commerciali e governative. Nel decennio scorso
però non ebbe un grande successo e gli studi sull’argomento non vennero seguiti
con l’attenzione che meritavano. Soltanto negli ultimi anni l’interesse su questa
tecnologia è cresciuto notevolmente e numerosi ricercatori stanno dando il loro
contributo per migliorarla sempre più e portarla ad uno stadio maturo e
consolidato.
Come si sarà certamente capito si è ancora lontani dalla definizione di uno
standard RBAC general-purpose e la presente trattazione si pone come primo
obiettivo quello di fornire un modello RBAC il più aggiornato possibile,
elaborando una sintesi degli studi attualmente in corso sulla materia. In secondo
luogo si vuole fornire un’implementazione del modello affinché si possa utilizzare
in un application server J2EE (Java 2 Enterprise Edition) il controllo d’accesso
basato su ruoli.
Gli obiettivi del presente lavoro possono essere definiti in modo più dettagiato
come segue:
•
Studiare un modello di controllo d’accesso basato su ruoli generalpurpose, che inglobi tutte le caratteristiche dei modelli più recentemente
sviluppati;
•
Proiettare il modello elaborato su un insieme di interfacce organizzate
ordinatamente in diversi packages (in linguaggio Java);
•
Fornire un’implementazione in linguaggio Java del modello per un
application server J2EE (Java 2 Enterprise Edition);
•
Sviluppare una piccola applicazione di prova per testare il funzionamento
del sistema.
1.5 Il piano di lavoro
Il piano di lavoro da seguire per portare a termine il progetto illustrato nel
paragrafo precedente prevede innanzitutto uno studio approfondito sia dei modelli
di controllo d’accesso tradizionali, sia di quelli relativi al tema centrale della tesi,
Pagina 21
ovvero all’RBAC. Si cercherà di porre l’attenzione sull’evoluzione temporale dei
diversi modelli, mettendone in luce le novità, i pregi ed i difetti. Terminata questa
fase si procederà ad un’analisi critica del modello RBAC così com’è stato
elaborato nella sua ultima versione, illustrandone gli aspetti ancora critici e
passando in rassegna gli ultimi sviluppi nei diversi settori di ricerca. Alla luce
degli studi effettuati, sarà infine possibile proporre un proprio modello generalpurpose di controllo d’accesso basato su ruoli. A questo punto si potrà passare
all’implementazione e al testing dello standard RBAC definito, in modo da
poterne valutare l’efficacia. La tabella seguente mostra nel dettaglio le diverse
attività del piano di lavoro e fornisce un’indicazione percentuale del carico di
lavoro assegnato a ciascuna di esse.
Attività
Carico di lavoro (%)
Studio ed analisi dei sistemi di controllo d’accesso
tradizionale
Studio ed analisi dei modelli di controllo d’accesso
basato su ruoli proposti in passato.
Analisi critica dello standard RBAC
5
20
20
Definizione a seguito degli studi effettuati di un
proprio standard RBAC general-purpose
20
Studio delle tecnologie J2EE
10
Implementazione del modello adottato
20
Sviluppo di un’applicazione di testing
5
TOTALE
100
Tabella 1-1. Piano di lavoro
Pagina 22
CAPITOLO 2
IL CONTROLLO
D’ACCESSO
TRADIZIONALE
Questo capitolo ha lo scopo di introdurre al
controllo d’accesso. Innanzitutto viene definito
un background terminologico di base, al fine di
poter descrivere con proprietà di linguaggio un
modello di controllo d’accesso. In secondo
luogo vengono illustrati i principi fondamentali,
che stanno alla base di questa disciplina. Infine
viene presentata un breve storia del controllo
d’accesso, in modo da poter apprezzare
l’evoluzione tecnologica che ha portato alla
definizione del controllo d’accesso basato su
ruoli,
ovvero
l’argomento
centrale
della
presente trattazione.
Pagina 23
2.1 Il controllo d’accesso
Prima di entrare nel dettaglio delle tecniche del controllo d’accesso è bene
ricordare le seguenti definizioni:
•
L’accesso è la capacità di agire su una risorsa, come ad esempio leggerla,
modificarla, eliminarla o rinominarla.
•
Il controllo d’accesso è il modo attraverso il quale questa capacità viene
regolata. In particolare definisce i meccanismi che permettono di dare e
revocare diverse tipologie di permessi e di vietare o consentire l’accesso
ad una risorsa in base ai permessi precedentemente assegnati.
•
Un modello di controllo d’accesso è una rappresentazione astratta sia
degli elementi del sistema, sia di quelli relativi alla sicurezza, ovvero di
tutti quei dati che sono rilevanti per il trattamento delle informazioni
classificate e memorizzate nel sistema stesso. Un modello deve dunque
cercare di catturare le caratteristiche ed i comportamenti del sistema di
controllo e fornirne un rappresentazione logica
I paragrafi seguenti forniscono una definizione dell’ontologia di base e dei
principi fondamentali del controllo d’accesso.
2.1.1
L’ontologia di base
Nel corso degli anni si è sviluppata una terminologia abbastanza consolidata per
descrivere i diversi elementi, che vanno a comporre un modello di controllo
d’accesso. La quasi totalità dei modelli di controllo d’accesso finora sviluppati si
basa sulle nozioni di utenti (users) soggetti (subjects), oggetti, (objects),
operazioni (operations) e permessi (permissions) e sulle relazioni che intercorrono
tra esse.
Vengono dunque riportate le definizioni relative a ciascuno degli elementi appena
citati:
•
Un utente è una persona che accede al sistema. In molte architetture un
utente può effettuare login multipli, anche con identificativi differenti.
•
Una sessione è una singola istanza di interazione tra un utente ed il
sistema
Pagina 24
•
Un soggetto è un processo che interagisce con il sistema per conto di un
utente, come se fosse quest’ultimo. Un utente può quindi avere più
soggetti in esecuzione, anche se ha effettuato un solo login. Ad esempio un
client per la posta elettronica può interagire in background con il sistema,
mentre l’utente naviga utilizzando un browser. Ogni programma aperto
dall’utente per il sistema è un soggetto differente.
•
Un oggetto è una qualsiasi risorsa del sistema accessibile da parte degli
utenti. Ad esempio sono oggetti i files, le periferiche, i database, ma lo
possono essere anche i singoli record contenuti in questi ultimi, dipende
dalla grana che si vuole utilizzare e della specifica applicazione. Gli
oggetti sono tradizionalmente considerati come delle entità passive, che
contengono e ricevono informazione, ma alcuni modelli di controllo
d’accesso permettono di trattare come oggetti anche programmi, stampanti
ed altre entità attive.
•
Un’operazione è un processo invocato da un soggetto.
•
Un permesso (o privilegio) è un’autorizzazione ad attivare una certa
azione sul sistema. Volendo fare un’analisi più dettagliata è necessario
sottolineare il fatto che in realtà un permesso non è altro che una
combinazione tra un oggetto ed una operazione. Infatti una stessa
operazione applicata a due oggetti differenti rappresenta due permessi
distinti. Allo stesso modo due differenti operazioni applicate allo stesso
oggetto necessitano di due permessi differenti.
2.2 I principi fondamentali
Un modello di controllo d’accesso ben strutturato deve ovviamente facilitare il
compito dell’amministratore di sistema, rispecchiando il più possibile la realtà
organizzativa che questi deve gestire e permettendogli di specificare in tempi
ragionevolmente rapidi vincoli e permessi. Inoltre, un buon modello deve anche
fornire supporto e nel caso migliore anche guidare al rispetto dei principi
fondamentali del controllo d’accesso:
-
il minimo privilegio (least privilege)
-
la separazione dei compiti (separation of duty)
Pagina 25
I prossimi paragrafi ne forniscono una descrizione dettagliata.
2.2.1
Il minimo privilegio (Least privilege)
Il principio del minimo privilegio afferma che si devono assegnare ad ogni utente
solamente i permessi strettamente necessari per lo svolgimento dei suoi compiti
all’interno dell’organizzazione. Si tratta dunque di una pratica amministrativa
consolidatasi negli anni, che consiste nell’assegnare in modo selettivo i permessi
agli utenti, in modo da evitare che un singolo individuo possa avere la possibilità
di compiere azioni non necessarie per il proprio lavoro e al contempo
potenzialmente dannose per il sistema.
Per rispettare le indicazioni fornite da questo principio fondamentale per la
sicurezza dell’informazione è necessario innanzitutto individuare correttamente
quali sono i compiti che ogni individuo deve svolgere; in secondo luogo si deve
procedere all’assegnazione dei soli permessi ritenuti necessari in base allo studio
appena effettuato. Ovviamente questo è un compito tutt’altro che facile ed è
necessaria una notevole esperienza per configurare correttamente un sistema.
La stretta aderenza al principio del minimo privilegio vorrebbe anche che uno
stesso individuo avesse differenti livelli di privilegi in istanti diversi, a seconda
della compito che sta svolgendo. È inoltre altrettanto importante che i permessi
assegnati ad un utente non persistano al di là del tempo durante il quale sono
necessari per lo svolgimento del suo lavoro.
Ovviamente una gestione dinamica dei privilegi aggiunge ulteriore complessità al
sistema e lavoro aggiuntivo per l’amministratore, tuttavia garantire permessi
maggiori rispetto a quelli strettamente necessari può causare problemi di sicurezza
sia all’integrità dei dati, che alla loro confidenzialità. Per questi motivi non è
possibile prescindere da questo principio fondamentale.
2.2.2
La separazione dei compiti (Separation of
duty)
Il principio della separazione dei compiti viene applicato da tempo in sistemi
commerciali, industriali e governativi e la sua utilità per la sicurezza
dell’informazione è stata ampiamente riconosciuta e dimostrata. Lo scopo è quello
Pagina 26
di evitare che all’interno di un’organizzazione un’unica persona possa recare
danno a quest’ultima perseguendo i sui interessi personali. Si vuole fare in modo
che l’unica evenienza in cui ciò possa accadere sia in corrispondenza di una
collusione tra diversi individui. Il principio dunque afferma che non si devono
assegnare ad una stessa persona i permessi per svolgere compiti che potrebbero
recare danno all’intera organizzazione.
Si può affermare che questo principio non è altro che un deterrente alla frode, in
quanto essa può avvenire solamente nei casi in cui esiste un’opportunità di
collusione tra le capacità operative di figure con diverse competenze. Per rendere
meglio l’idea si può affermare che un particolare set di transazioni non deve poter
essere eseguito da un solo individuo, ma deve essere suddiviso su almeno due
persone distinte.
La separazione dei compiti permette quindi di definire politiche di controllo
d’accesso nelle quali sono presenti conflitti d’interesse. Un conflitto d’interesse
può sorgere ogni volta che un utente cerca di ottenere diversi permessi associati a
ruoli che non possono però essere ricoperti da uno stesso soggetto per motivi di
sicurezza.
Vi sono due tipi di separazione dei compiti, quella statica e quella dinamica. Nel
primo caso è semplicemente necessario assegnare a priori ad ogni individuo un
insieme di permessi, in modo da rispettare i vincoli imposti dal principio di
separation of duty. Il secondo tipo è invece più complesso, in quanto la verifica di
queste regole non è fatta a priori, bensì durante tutto l’arco di funzionamento del
sistema. Il vantaggio è ovviamente quello di introdurre una maggiore flessibilità,
che in certi casi applicativi può essere auspicabile se non indispensabile.
2.3 Breve storia del controllo d’accesso
tradizionale
La storia del controllo d’accesso è piuttosto recente e può essere fatta risalire
attorno agli inizi degli anni Settanta. A quei tempi infatti iniziavano a diffondersi i
primi grandi sistemi di condivisione dati per applicazioni governative,
Pagina 27
commerciali e militari, che avevano la necessità di garantire la sicurezza delle
informazioni da esse gestite.
I prossimi paragrafi presentano in ordine cronologico i modelli di controllo
d’accesso più significativi, che sono stati proposti nel corso degli anni.
2.3.1
Matrice di controllo
Il primo lavoro che ha prodotto una definizione matematica formale di controllo
d’accesso è stato quello di Lampson [2] nel 1969, che ha introdotto i concetti di
soggetto ed oggetto e ha proposto l’utilizzo di una matrice di controllo d’accesso
per filtrare le richieste dei diversi soggetti, in modo da proteggere gli oggetti del
sistema dagli accessi indesiderati.
La matrice non è altro che una rappresentazione concettuale dei permessi legati a
tutte le possibili coppie < x,y > dove x è un soggetto ed y e un oggetto del sistema.
La tabella seguente mostra un esempio tratto dal testo originale di Lampson.
General ledger
Alice
Payroll
R,W
Bob
R,W
Charles
R
Accounts receivable
Accounts payable
R
R
R
R
R
R
Tabella 2-1. Esempio di matrice di controllo d'accesso di Lampson
I diritti di accesso previsti erano semplicemente la scrittura e la lettura,
rispettivamente W ed R., mentre le caselle vuote stavano ad indicare l’assenza di
entrambi i permessi. Il sistema doveva semplicemente controllare se un certo
utente aveva o meno il permesso di leggere o scrivere su un determinato oggetto,
andando a consultare il campo opportuno della tabella, e consentire o meno
l’operazione richiesta.
Pagina 28
2.3.2
Reference monitor e security kernel
Nel 1972 con l’Anderson Report [4] sono stati stato introdotti due importanti
concetti per la sicurezza informatica, che ancora oggi non hanno perso il loro
valore e sono utilizzati come linea guida per il design e l’implementazione dei
sistemi di controllo d’accesso: il reference monitor ed il security kernel.
Il reference monitor può essere visto sotto due ottiche differenti, ma
complementari:
•
In primo luogo fornisce un modello astratto delle proprietà che deve avere
un meccanismo di controllo d’accesso altamente affidabile.
•
In secondo luogo può essere utilizzato come linea guida nel design, nello
sviluppo e nell’analisi delle applicazioni che forniscono servizi di
sicurezza.
La figura seguente riporta uno schema che illustra l’architettura di un reference
monitor.
Figura 2-1. Il reference monitor
Pagina 29
Il reference monitor non è altro che un concetto astratto, secondo il quale tutti gli
accessi che un soggetto fa verso gli oggetti del sistema sono autorizzati
utilizzando l’informazione contenuta in una base di controllo d’accesso (access
control base). È previsto inoltre un altro repository di informazioni (audit file)
relativo alla memorizzazione della storia degli accessi effettuati.
Essendo un’astrazione il reference monitor non detta una politica di controllo
d’accesso particolare e non definisce alcun aspetto implementativo. Si preoccupa
invece di fornire tre requisiti fondamentali che devono essere rispettati:
1. completezza
2. isolamento
3. verificabilità
Il principio della completezza richiede che un soggetto possa accedere ad un
oggetto solamente passando attraverso il reference monitor.
Il principio dell’isolamento afferma invece che la funzione di filtraggio degli
accessi del reference monitor deve essere impenetrabile, ovvero non deve essere
possibile ad un attaccante di inserirsi nel meccanismo di controllo degli accessi e
modificarlo in qualsiasi modo.
L’implementazione di un security kernel può essere un modo per soddisfare
questo requisito. Il security kernel non è altro che un’implementazione minima
delle funzioni di sistema rilevanti dal punto di vista della sicurezza.
La figura seguente mostra l’architettura di un security kernel.
Figura 2-2. Il security kernel
Pagina 30
Si può notare come il security kernel sia posizionato appena al di sopra
dell’hardware e al di sotto delle funzioni non critiche dal punto di vista della
sicurezza, implementate nel sistema operativo.
Infine il principio della verificabilità afferma che deve essere possibile provare
che l’implementazione soddisfa i due precedenti requisiti.
2.3.3
Il modello di Bell-LaPadula
Un report della RAND Corporation [3] del 1970 fornisce un’attenta analisi circa
la sicurezza dei sistemi informatici del Dipartimento della Difesa americano. In
questo documento viene definito per la prima volta un metodo per implementare
un controllo d’accesso multilivello sulle risorse condivise di un sistema. Venivano
distinti gli accessi locali da quelli remoti e si supponeva che l’autenticazione
avvenisse mediante password. I livelli di accesso proposti erano “confidential”,
“secret” e “top-secret”. Ogni utente poteva accedere alle diverse risorse in base al
suo grado.
Nel 1973 Bell e LaPadula [5], ispirandosi probabilmente al documento appena
citato, proposero dunque un nuovo modello di controllo d’accesso multilivello
basato su “etichette di sicurezza”.
Il modello prevede che ad ogni soggetto e ad ogni oggetto del sistema venga
assegnata un’etichetta, che rappresenta il suo livello di sicurezza. Le etichette
sono dunque organizzate in modo gerarchico, ad esempio si può avere la seguente
classificazione (partendo dal livello più alto fino a quello più basso): top-secret
(TS), secret (S), confidential (C), unclassified (U).
Definite ed assegnate le etichette, devono essere rispettate le seguenti due
proprietà:
1. simple security property: un soggetto può accedere in lettura a tutti gli
oggetti che hanno un livello di sicurezza non superiore a quello
assegnatogli.
2. *(star) property: un soggetto può accedere in scrittura solamente agli
oggetti che hanno un livello di sicurezza non inferiore a quello
assegnatogli.
Pagina 31
Un’ultima considerazione va fatta in merito alla differenza che il sistema fa tra
utenti e soggetti. Infatti un utente assegnato ad esempio al livello TS, può
potenzialmente leggere e scrivere tutti gli oggetti del sistema. Quando però
l’utente accede al sistema, diventa un soggetto e come tale deve sottostare alle
due proprietà appena illustrate.
La figura seguente mostra i privilegi di accesso in scrittura (w) e in lettura (r) di
un utente ed un soggetto di livello TS.
Figura 2-3. Utente VS Soggetto
Se un soggetto di livello TS volesse ad esempio scrivere un oggetto di livello S o
C, dovrebbe dunque cambiare il livello della propria sessione degradandolo
quanto è necessario.
2.3.4
Modello d’integrità di Biba
Anche se il modello di Bell-LaPadula controlla le scritture dell’informazione
contenuta negli oggetti del sistema, in realtà quello che offre è un servizio di
confidenzialità in termini di protezione dalle letture non autorizzate. Infatti,
utilizzando questo modello, non vi è alcun modo di prevenire modifiche non
autorizzate delle informazioni.
Per questa ragione nel 1977 Biba [36] propose un nuovo modello di controllo
d’accesso complementare a quello di Bell-LaPadula, in cui lo scopo primario era
quello di preservare l’integrità dei dati, sacrificando la loro confidenzialità.
Pagina 32
Ad ogni soggetto e oggetto del sistema, analogamente a quanto accadeva per il
modello di Bell-LaPadula, dovevano essere assegnate delle etichette, che
rappresentavano un certo livello di integrità.
Soddisfatto questo prerequisito, dovevano essere rispettate le seguenti proprietà,
simmetriche rispetto alle precedenti:
1. simple integrity property: un soggetto può accedere in lettura a tutti gli
oggetti che hanno un livello di sicurezza non inferiore a quello
assegnatogli.
2. integrity *(star) property: un soggetto può accedere in scrittura
solamente agli oggetti che hanno un livello di sicurezza non superiore a
quello assegnatogli.
In questo modo le scritture provenienti dai livelli inferiori non sono più
autorizzate, così come le letture dai livelli superiori a quelli inferiori.
2.3.5
TCSEC: il MAC e il DAC
Nel 1985 il DoD (Department of Defense) americano rese pubblico un
documento, il TCSEC [1] (Trusted Computer Systems Evaluation Criteria), che
definiva due differenti modelli di controllo d’accesso, il MAC (Mandatory Access
Control) e il DAC (Discretionary Access Control). Il primo era stato progettato
allo scopo di adattarsi meglio alle esigenze militari, mentre il secondo era stato
pensato per applicazioni commerciali e governative.
I paragrafi seguenti forniscono una breve descrizione di entrambi i modelli.
2.3.5.1
DAC (Discretionary Access Control)
Il DAC è un meccanismo che consente ad un utente di permettere o vietare ad altri
utenti l’accesso agli oggetti di sua proprietà. Il controllo è “discrezionale” nel
senso che un utente che possiede un determinato permesso di accesso su un
oggetto ha la possibilità di trasmettere questo permesso ad un altro utente.
In alcuni casi il proprietario di un oggetto può decidere di trasmettere tutti o alcuni
dei suoi privilegi d’accesso ad altri utenti, senza però dare loro il permesso di
estendere questi ultimi ad altri utenti.
Pagina 33
Non è dunque necessario l’intervento dell’amministratore di sistema nel processo
di assegnazione e revoca dei permessi. Ad ogni modo l’amministratore è colui che
possiede tutti gli oggetti del sistema e può violare a piacimento le diverse
restrizioni d’accesso.
I sistemi DAC sono quelli a cui siamo più abituati: i meccanismi dei permessi
UNIX e le ACL di Windows sono sistemi DAC.
2.3.5.2
MAC (Mandatory Access Control)
Il MAC deriva direttamente dal modello di Bell-LaPadula ed è un meccanismo
per restringere l’accesso agli oggetti di un sistema basato sulla sensibilità
dell’informazione in essi contenuta e sull’autorizzazione esplicita degli utenti ad
accedere alle informazioni appartenenti ad un preciso livello di sensibilità.
In un sistema MAC gli oggetti hanno dunque un loro livello di segretezza e gli
utenti hanno un loro livello di accesso. Esiste inoltre una figura che nei sistemi
DAC non è prevista, il “security officer”, che è l’unico a poter gestire e
modificare i livelli d’accesso.
Le regole d’accesso che vengono generalmente usate sono le seguenti:
1. No read up: l’utente non può leggere informazioni con un livello
d’accesso superiore al suo.
2. No write down: l’utente non può scrivere informazioni con un livello
d’accesso inferiore al suo.
Un’altra versione ugualmente espressiva delle regole imposte da un modello
MAC è invece la seguente:
1. Security Rule: un utente non può leggere informazioni il cui livello
d’accesso più elevato del suo
2. Minus Property: un utente non può spostare informazioni da un livello di
sicurezza ad un livello di sicurezza più basso, ma può spostarle solamente
ad un livello più alto.
Quest’ultima proprietà implica ovviamente la proprietà di “no write down”,
mentre la prima è identica alla “no read up”.
Pagina 34
2.3.6
Modello di Clark e Wilson
Nel 1987 Clark e Wilson [7] pubblicarono un documento in cui si criticava il
modello DAC proposto dal DoD per le applicazioni commerciali, portando come
motivazione principale il fatto che l’attenzione maggiore in questo ambito deve
essere rivolta all’integrità dell’informazione. Proposero dunque un nuovo modello
di controllo d’accesso, che aveva come obiettivo principale quello di garantire che
gli oggetti del sistema fossero modificati solamente da personale autorizzato.
Il modello di Clark e Wilson si basa su due principi fondamentali:
1. le transazioni ben formate
2. la separazione dei compiti
Le transazioni ben formate assicurano che i dati modificati da un utente passino
da uno stato valido ad un altro stato, anch’esso valido, al termine dell’esecuzione
della transazione.
L’unità base del controllo d’accesso secondo Clark e Wilson è la tripla <user,
operation, object>, ovvero <utente, procedura di trasformazione, oggetto protetto
del sistema>, così come si può osservare bella figura seguente.
Figura 2-4. Tripla di controllo d’accesso secondo Clark e Wilson
Clark e Wilson proposero nove regole per garantire l’integrità dei dati, ma prima
di elencarle è necessario dare le seguenti definizioni:
•
TP (Transformation Procedure): procedura di trasformazione.
•
CDI (Constrianed Data Item): dato di sistema protetto, la cui integrità deve
quindi essere preservata.
•
UDI (unconstrained Data Item): dato di sistema non protetto, la cui
integrità non è assicurata.
Pagina 35
•
IVP (Integrity Verification Procedure): procedure di verifica dell’integrità
dei dati.
Le regole definite dal modello sono dunque le seguenti:
1. per ogni CDI deve esistere una IVP che assicuri che il dato è in uno stato
consistente;
2. ogni TP che modifica un CDI deve essere certificata, ovvero deve
assicurare di modificare il dato lasciandolo in uno stato consistente;
3. un CDI può essere modificato solo da una TP certificata;
4. ogni TP certificata deve fare il log delle modifiche effettuate su un CDI;
5. ogni TP che prende in input un UDI deve essere certificata per assicurare
che trasformerà l’UDI in CDI portando l’oggetto in uno stato consistente;
6. solo TP certificate possono modificare gli UDI;
7. un utente può accedere ai CDI solo attraverso TP per le quali è stato
autorizzato;
8. ogni utente deve essere autenticato dal sistema prima di eseguire una TP;
9. solo l’amministratore può autorizzare gli utenti ad utilizzare una TP.
Le transazioni ben formate mettono in luce il fatto che è non è sufficiente
effettuare controlli a livello di letture e scritture gestite da sistema operativo, ma
che è necessario spostare l’attenzione sul livello applicativo, assicurandosi che le
informazioni siano modificate solo dalle transazioni autorizzate.
Per quanto riguarda infine la separazione dei compiti, che è già stata definita in
precedenza, si sottolinea il fatto che è la prima volta nella storia del controllo
d’accesso che questo importantissimo principio vene enunciato chiaramente e
posto alla base di un modello.
2.3.7
Politica del muro cinese e modello di
Brewer e Nash
Nel 1989 Brewer e Nash [11] identificarono una politica di controllo d’accesso
per impedire i conflitti di interesse nell’ambito delle attività di consultazione delle
informazioni fra diversi istituti bancari e compagnie assicurative. Si voleva
Pagina 36
impedire che una stessa persona potesse accedere alla informazioni riservate di
diverse compagnie ed utilizzarla a proprio vantaggio.
La politica del muro cinese mira dunque ad evitare il flusso di informazioni che
può dare luogo a conflitti di interesse.
Le informazioni riservate vengono classificate in categorie di conflitto di
interesse, dette COI (Conflict of Interest Category). Ogni compagnia appartiene
ad una COI ed ogni COI contiene due o più compagnie. Quello che si deve
impedire è dunque che una stessa persona legga informazioni riservate da più
compagnie della stessa COI.
Valgono le seguenti considerazioni:
•
Un utente, fino a quando non ha letto alcuna informazione di una COI, può
accedere ai dati di qualsiasi compagnia in essa contenuta.
•
Una volta che un utente ha letto le informazioni di una certa compagnia
facente capo ad un determinata COI, non portà più accedere ai dati delle
altre compagnie della stessa COI.
•
Tutti gli utenti possono leggere le informazioni pubbliche di tutte le
compagnie.
La politica del muro cinese regola dunque le letture dell’informazione. Il modello
di Brewer e Nash include questa politica e la estende, andando a vincolare anche
le scritture, in modo da preservare anche l’integrità dei dati. Vengono infatti
definite due regole, una per le letture ed una per le scritture:
1) Regola di lettura: un soggetto S può accedere in lettura ad un oggetto O
solo se vale una delle seguenti due affermazioni:
a. O appartiene alla stessa compagnia di altri oggetti precedentemente
letti da S.
b. O appartiene ad una COI, della quale S non ha ancora letto alcun
oggetto.
2) Regola di scrittura: un soggetto S può accedere in scrittura da un oggetto
O solo se valgono entrabe le seguenti affermazioni:
a. S può leggere O secondo la regola di lettura.
b. Nessun altro oggetto può essere letto, se non quelli facenti capo
alla stessa compagnia di O.
Pagina 37
Quest’ultima regola è stata introdotta per prevenire attacchi di tipo “cavallo di
troia”.
Si può infine notare il fatto che il modello di Brewer e Nash non fa distinzione tra
utente e soggetto e che le politiche di sicurezza sulle letture si applicano non solo
alle singole sessioni, ma rimangono valide per tutta la vita dell’utente all’interno
del sistema.
Pagina 38
CAPITOLO 3
IL MODELLO RBAC
ORIGINALE
Dopo aver illustrato i principi fondamentali del
controllo d’accesso tradizionale ed averne
fornito una breve storia, ci si concentra sul tema
centrale della tesi, l’RBAC appunto. Nella
prima parte di questo capitolo verrà presentato
il documento originale che ha dato vita al
controllo d’accesso basato su ruoli. Nella
seconda parte invece verrà fatto un confronto
tra le principali tecniche di controllo d’accesso
tradizionali, il MAC e il DAC, e quelle
innovative introdotte con l’RBAC.
Pagina 39
3.1 Il primo modello RBAC
Nel 1992 Ferraiolo e Kuhn [15], due studiosi del NIST (National Institute of
Standards and Technology), presentarono uno studio in cui si prospettava un
utilizzo differente dei concetti di utenti, operazioni e gruppi. Questi ultimi presero
il nome di “ruoli” e venivano usati come intermediari tra i primi e le seconde. Si
trattò di fatto del primo modello RBAC proposto nella storia del controllo
d’accesso.
3.1.1
Utenti, ruoli ed operazioni
Prima di entrare nel dettaglio del funzionamento del primo modello di controllo
d’accesso basato su ruoli è opportuno dare una definizione dei termini chiave, che
verranno utilizzati da qui in avanti per riferirsi alle entità principali che lo vanno a
comporre. Si tratta di una rivisitazione di parte dell’ontologia di base data per il
controllo d’accesso generico. In un modello RBAC si possono individuare i
seguenti elementi fondamentali:
1. Un utente è un soggetto (entità fisica) facente parte di un’organizzazione.
2. Un ruolo è un insieme di operazioni che un utente (o un insieme di utenti)
può eseguire nel contesto dell’organizzazione di cui fa parte.
3. Una operazione (o transazione) è una procedura, alla quale viene
associato un certo set di dati, che viene definito con il termine oggetto. Va
notato il fatto che una transazione non è accomunabile a semplici
operazioni di lettura o di scrittura, in quanto queste ultime non fanno
riferimento a nessun oggetto in particolare. Una transazione ha senso solo
se è riferita ad un particolare oggetto. Operazioni uguali fatte su oggetti
diversi sono dunque transazioni differenti.
Le operazioni sono allocate ai diversi ruoli dall’amministratore di sistema, che si
preoccupa anche di assegnare i vari utenti ai diversi ruoli presenti all’interno
dell’organizzazione. Allo stesso modo l’amministratore può revocare in qualsiasi
momento l’appartenenza (o “membership”) di un utente ad un determinato ruolo e
può aggiornare il set di transazioni associate a quest’ultimo.
Pagina 40
Infine va sottolineato il fatto che esistono relazioni molti-a-molti tra utenti, ruoli,
transazioni ed oggetti del sistema; in particolare:
•
Ad un utente possono essere assegnati più ruoli
•
Un ruolo può essere ricoperto da diversi utenti
•
Ad ogni ruolo possono essere associate diverse operazioni
•
Una operazione può essere eseguita da diversi ruoli
•
Una operazione può operare su più oggetti
•
Un oggetto può essere manipolato per mezzo di diverse operazioni
La figura seguente mostra le relazioni molti-a-molti, che sussistono tra utenti,
ruoli, operazioni ed oggetti del sistema.
Oggetto 1
Appartenenza
Operazione 1
Ruolo 1
Oggetto 2
Operazione 2
Operazione 3
Utente 1
Utente 2
Utente 3
Ruolo 2
Figura 3-1. Relazioni tra utenti, ruoli, transazioni ed oggetti di sistema
3.1.2
Gerarchie di ruoli
Spesso all’interno di un’organizzazione ci sono delle operazioni, che possono
essere svolte da tutti gli utenti. In questo caso sarebbe necessario replicare le
stesse transazioni in tutti i ruoli definiti nel sistema. Ovviamente ciò non è
auspicabile, in quanto complicherebbe di molto la gestione da parte
dell’amministratore, mentre lo scopo di RBAC è quello di semplificarla al
massimo, fornendo un modello il più vicino possibile alla realtà organizzativa
sulla quale si vuole esercitare il controllo d’accesso alle informazioni.
Per venire incontro a questa esigenza si è deciso di rendere possibile
un’organizzazione gerarchica dei ruoli, che permette a ruoli più specializzati di
ereditare da altri ruoli tutte le loro operazioni. Così facendo si
semplifica
Pagina 41
notevolmente
la
gestione
delle
attività
comuni
a
tutti
gli
utenti
dell’organizzazione.
Quello che accade quando un ruolo discende da un altro è mostrato nella figura
seguente.
RUOLO A
(Padre)
Set di
transazioni
d el padre
RUOLO B
(Figlio)
Set di
transazioni
specifiche del
figlio
Set di
transazioni
del figlio
Figura 3-2. Gerarchia di ruoli
Un esempio di gerarchia tratto dal documento originale di Ferraiolo e Kuhn è
mostrato nella figura seguente, in cui vengono mostrate le dipendenze tra le
diverse figure professionali presenti all’interno di un ospedale.
Pagina 42
Figura 3-3. Esempio di gerarchia tra ruoli
3.1.3
Descrizione formale
Per chiarire i concetti espressi nei paragrafi precedenti, si vuole ora dare una
semplice descrizione formale del Role-Based Access Control.
Per prima cosa si danno le seguenti definizioni:
•
Subject = insiene dei soggetti
•
Role = insieme dei ruoli
•
Tran = insieme delle transazioni (o operazioni)
•
AR(s: subject) = ruolo attivo del il soggetto s
Pagina 43
•
RA(s: subject) = insieme dei ruoli autorizzati del soggetto s
•
TA(r: role) = insisme delle transazioni autorizzate per il ruolo r
•
Exec(s:subject, t:tran) = esecuzione della transazione t da parte del
soggetto s
In secondo luogo, per ognuno degli insiemi appena elencati, devono valere le
seguenti regole:
•
Un soggetto può ricoprire un solo ruolo attivo per volta
•
Un soggetto può essere autorizzato a ricoprire più ruoli
•
Un ruolo può essere autorizzato ad eseguire più transazioni
Le liste dei ruoli autorizzati e della transazioni autorizzate per ogni ruolo vengono
gestite dall’amministratore di sistema, che può aggiungere e togliere elementi
dagli insiemi RA e TA in qualsiasi momento. Il ruolo attivo del soggetto, invece
cambia durante l’esecuzione ed è alla base del meccanismo di controllo d’accesso
RBAC. Infatti, ogni volta che un utente tenta di eseguire un’operazione su un
oggetto, devono essere verificate le seguenti condizioni:
1. “Role Assignment”: un soggetto può eseguire una transazione solo se ha
assegnato un qualche ruolo attivo.
∀s: subject, t: tran exec(s, t) ⇒ AR(s) ≠ ∅
2. “Role Authorization”:
il ruolo attivo del soggetto dev’essere stato
autorizzato, ovvero deve comparire nella lista dei ruoli autorizzati
∀s: subjec AR(s) ⊆ RA(s)
3. “Transaction Authorization”: un soggetto può eseguire una transazione
solo se quest’ultima fa parte delle transazioni autorizzate per il ruolo attivo
che esso ricopre.
∀s: subject, t: tran exec(s, t) ⇒ t ∈ TA (AR(s))
Con le regole appena elencate si è dunque certi che vengono eseguite solamente le
transazioni autorizzate. Inoltre va notato il fatto che l’implicazione delle regole 1 e
3 esprime una condizione di tipo “solo se” e non “se e solo se”, quindi non è detto
che la transazione venga effettivamente eseguita, anche se valgono le condizioni
espresse. Infatti queste ultime non escludono la possibilità di aggiungere ulteriori
restrizioni all’esecuzione delle transazioni, dipendenti dal contesto operativo del
Pagina 44
sistema. Questa è un’ulteriore prova della grande flessibilità del Role-Based
Access Control.
3.1.4
Il principio del minimo privilegio
Il principio del minimo privilegio è essenziale per garantire l’integrità
dell’informazione ed afferma che ad ogni utente non bisogna dare maggiori
privilegi di quelli strettamente necessari ad eseguire i compiti che deve svolgere.
Per applicare correttamente questo principio è necessario innanzitutto indagare su
quali sono effettivamente i compiti che devono essere svolti da un utente, in
seconda istanza determinare qual è il minimo privilegio da assegnare all’utente,
affinché possa svolgere questi compiti ed infine assegnare l’utente ad un dominio,
che abbia i privilegi richiesti e niente di più.
Un sistema RBAC supporta dunque il principio del minimo privilegio, in quanto è
possibile assegnare un utente ad un ruolo, al quale sono associate le sole
transazioni
indispensabili
allo
svolgimento
del
suo
lavoro
all’interno
dell’organizzazione.
3.1.5
Separazione dei compiti
Un meccanismo RBAC può essere usato da un amministratore di sistema per
rinforzare la politica di separazione dei compiti (“separation of duty”). Il set di
transazioni da gestire opportunamente per rispettare i vincoli introdotti da questa
politica di controllo d’accesso variano a seconda del caso specifico. È dunque
necessario prendere in considerazione di volta in volta ogni singola realtà
organizzativa ed ovviamente solamente alcune ben precise operazioni dovranno
essere ristrette nell’ambito della politica di separazione dei compiti.
La separazione dei compiti, come si è detto in precedenza, può essere statica o
dinamica. Il primo caso è quello più semplice, per cui è necessario solamente
assegnare a priori ad ogni individuo un insieme di ruoli e ad ogni ruolo un set di
transazioni possibili, in modo da rispettare le regole di “separation of duty”. Il
secondo è invece più complesso, in quanto la verifica di queste regole può essere
fatta solamente durante il funzionamento del sistema, ma d’altro canto introduce
una maggiore flessibilità, che in certi casi applicativi può essere auspicabile se
Pagina 45
non indispensabile. In realtà il documento originale di Sandhu non spiega nel
dettaglio come un sistema RBAC possa essere configurato per supportare la
separazione dinamica dei compiti, ma lascia comunque intendere che ciò può
avvenire assegnando ad uno stesso utente anche ruoli che generano conflitti di
interesse e verificando poi run-time che questo utente non ricopra entrambi i ruoli
contemporaneamente.
Appare dunque evidente come il controllo d’accesso basato su ruoli possa
perfettamente adattarsi ad una politica di separation of duty sia statica, che
dinamica.
3.2 Differenza tra ruoli e gruppi
Leggendo le definizioni fornite nel paragrafo precedente, può non essere del tutto
chiaro quale sia la differenza tra ruoli e gruppi di utenti, dove questi ultimi non
sono altro che l’unità di controllo d’accesso più frequentemente adottata in molti
dei sistemi comunemente utilizzati.
La differenza principale esistente fra la maggior parte delle implementazioni di
gruppi ed il concetto di ruoli va ricercata nel fatto che i primi sono tipicamente
trattati come una collezione di utenti e non come un insieme di permessi. Un ruolo
in realtà è entrambe le cose, ovvero racchiude in sé sia i permessi che gli utenti, ai
quali questi ultimi vengono assegnati in modo indiretto. I ruoli sono dunque degli
intermediari tra gli insiemi dei permessi e degli utenti.
Una seconda differenza tra ruoli e gruppi risiede nel grado di facilità con la quale
è possibile determinare l’elenco degli utenti e dei permessi appartenenti
all’insieme (ruolo o gruppo) in questione. Questa differenza è ovviamente una
conseguenza della prima, ma è utile come “prova del nove” per capire se un
sistema di controllo d’accesso appartiene all’una o all’altra tipologia. Infatti, per
poter parlare di ruolo, deve essere altrettanto facile (o difficile) determinare il
relativo insieme di utenti ed il relativo insieme di permessi. Inoltre il controllo
dell’appartenenza di un utente e l’assegnazione di un permesso ad un ruolo
devono essere operazioni abbastanza centralizzate, ovvero concentrate in un
numero limitato di utenti rispetto alle dimensioni globali del sistema che si deve
gestire.
Pagina 46
Si pensi ad esempio ad un sistema Unix. Per determinare l’appartenenza dei
diversi utenti ai vari gruppi è sufficiente guardare i file “/etc/passwd” ed
“/etc/group”. L’informazione circa i permessi assegnati ai diversi gruppi è invece
dispersa su tutto il file system. Inoltre l’assegnamento dei permessi ai gruppi è
altamente decentralizzato. Appare dunque chiaro come in questo caso non si possa
in alcun modo parlare di “ruoli”, secondo la definizione che si è fornita.
3.3 Confronto tra RBAC, MAC e DAC
Mentre il MAC è appropriato per applicazioni militari, in quanto riflette i diversi
livelli di sicurezza della gerarchia militare, il DAC viene spesso considerato il
meccanismo di controllo d’accesso che si sposa meglio con le applicazioni civili
ed industriali. In realtà il DAC risulta essere inadeguato per molte applicazioni
commerciali e civili, mentre il MAC non offre la flessibilità che talvolta è
richiesta anche in ambito militare. Nasce quindi la necessità di un nuovo
meccanismo di controllo degli accessi, che sia più appropriato per le applicazioni
militari e non. L’RBAC è la risposta a questa esigenza.
3.3.1
RBAC vs DAC
Molto spesso le decisioni riguardanti il controllo d’accesso vengono determinate
in base al ruolo che i singoli utenti hanno all’interno dell’organizzazione, ovvero
in base ai loro doveri, alle loro responsabilità e alla loro qualifica. Una politica di
controllo d’accesso RBAC si basa infatti sulle funzioni che un utente deve
svolgere all’interno di un’organizzazione, ovvero sul suo ruolo. È questa la
principale differenza tra DAC e RBAC. Infatti in molte applicazioni commerciali
e civili gli utenti finali non possiedono l’informazione che possono leggere e
manipolare, ma la loro qualifica li autorizza a farlo: è il sistema RBAC che
possiede gli oggetti, ovvero i contenitori di informazione, ed è sempre
quest’ultimo che autorizza o meno l’accesso degli utenti, assegnati ai diversi ruoli,
agli oggetti. Inoltre, proprio perché gli utenti non posseggono le informazioni, non
possono propagare i loro diritti d’accesso ad altri utenti.
Pagina 47
3.3.2
RBAC vs MAC
L’RBAC è molto più simile al MAC, infatti alcuni sostengono persino che sia una
forma di MAC con un singolo livello d’accesso. Questa tesi sembra avvalorata dal
fatto che assegnare un utente ad uno o più ruoli e specificare le operazioni che
competono ad ogni ruolo è del tutto analogo a distribuire gli utenti su vari livelli
di sensibilità ed assegnare ad ogni oggetto un’etichetta in base alla sensibilità
dell’informazione in essi contenuta. Ciò è vero, ma la differenza tra MAC ed
RBAC in realtà è più sottile: l’RBAC si preoccupa maggiormente di regolare
l’accesso alle funzioni, che operano sulle informazioni contenute negli oggetti, e
non strettamente dell’accesso alle informazioni stesse. Infatti mentre nel MAC ci
si preoccupa di stabilire chi può leggere che cosa e di vietare la scrittura ad un
livello inferiore, in un sistema RBAC l’obiettivo principale è proteggere
l’integrità dell’informazione, stabilendo chi può fare che cosa su quale
informazione.
Pagina 48
CAPITOLO 4
RBAC96 FRAMEWORK
Viene
ora
descritto
il
framework
RBAC
proposto nel 1996 dal NIST (National Institute
of Standards and Technology). Si tratta di un
passo importante verso una definizione univoca
ed universalmente accettata del controllo
d’accesso basato su ruoli. Nel capitolo sono
illustrate
dettagliatamente
le
componenti
fondamentali dei modelli in cui il framework è
suddiviso,
ognuno
accompagnato
da
descrizione formale.
Pagina 49
una
4.1 Il framework RBAC
Nel 1996 Sandhu [19] propose assieme a Coyne, Feinstein e Youman un primo
framework per il controllo d’accesso basato su ruoli. L’idea principale fu quella di
dividere in quattro modelli il modello originale, in modo da trattare separatamente
le diverse funzionalità che quest’ultimo doveva mettere a disposizione. Si tratta di
un’evoluzione importante rispetto al modello originale, in cui non c’era alcuna
classificazione e tutto era concentrato in un’unica architettura, per i seguenti
motivi:
1. un sistema in cui tutto è unificato è più difficile da configurare ed
amministrare
2. se si desiderano apportare funzionalità aggiuntive, il modello cresce
ancora di complessità
3. la modularità facilita sia l’aggiunta di nuove funzionalità, sia la
composizione in tutte le possibili varianti di quelle già esistenti
Nei prossimi paragrafi verranno presi in esami i diversi modelli, che compongono
il framework RBAC96.
4.2 Panoramica dei modelli
Il framework RBAC96 si compone dei seguenti modelli:
1) RBAC0: funzionalità di base
2) RBAC1: gerarchia fra ruoli
3) RBAC2: vincoli
4) RBAC3: modello unificato
L’RBAC0 racchiude in sé tutte le caratteristiche necessarie per avere un sistema di
controllo d’accesso basato su ruoli. L’RBAC1 invece aggiunge al modello base la
possibilità di definire gerarchie tra ruoli, mentre l’RBAC2 introduce una serie di
vincoli sulle entità e le relazioni del modello. Infine l’RBAC3 non è altro che il
contenitore di tutti i precedenti modelli.
La figura seguente mostra le dipendenze esistenti fra i diversi modelli del
framework.
Pagina 50
Figura 4-1. RBAC96 Framework
I paragrafi seguenti analizzano più dettagliatamente i singoli modelli.
4.2.1
RBAC0
L’RBAC0 è detto anche “modello base” e non fa altro che definire le entità
principali del controllo d’accesso basato su ruoli ed elencare le relazioni che le
legano. Rispetto al modello RBAC originale vi sono due novità: le sessioni ed i
permessi.
Le sessioni non sono altro che dei contenitori, che tengono traccia dei ruoli
attivati da un utente durante l’interazione con il sistema. In alcuni documenti non
si parla di sessioni, ma di soggetti. I due concetti potrebbero sembrare molto
differenti fra loro; in realtà sono la medesima cosa, in quanto il termine soggetto è
utilizzato per sottolineare il fatto che un utente può avere diverse istanze, con le
quali accede contemporaneamente al sistema, dotate tutte degli stessi permessi.
Queste istanze, non sono altro che i soggetti, ovvero le sessioni.
Per quanto riguarda invece i permessi, si può affermare che essi non sono altro
che le operazioni/transazioni del modello RBAC originale. Infatti ai ruoli
venivano assegnate direttamente delle transazioni, specificando che un’operazione
eseguita su un oggetto differente non poteva essere considerata la stessa
transazione. Per non dare adito a confusione ed eliminare la possibilità di
fraintendere questa sottile distinzione, si è deciso di introdurre il concetto di
permesso, che esprime appunto la possibilità manipolare le informazioni
contenute negli oggetti del sistema.
Pagina 51
Per completezza segue un elenco esaustivo degli elementi di base dell’ RBAC0:
•
Users (insieme U): utenti del sistema. Un utente è identificato in questo
caso con un essere umano, anche se il concetto può essere esteso a
macchine, reti o agenti intelligenti autonomi.
•
Roles (insieme R): ruoli dell’organizzazione. Un ruolo è identificato con
un determinato compito all’interno di un’organizzazione, al quale è legata
una certa semantica riguardo la responsabilità e l’autorità che esso
rappresenta.
•
Permissions(insieme P): permessi di accesso. Un permesso è la possibilità
di eseguire un’operazione su uno o più oggetti protetti.
•
Sessions (insieme S): sessioni utente. Una sessione non è altro che un
sottoinsieme dei ruoli attivabili dall’utente. Ogni sessione è associata da
un unico utente, mentre un utente può attivare più sessioni
contemporaneamente.
Le relazioni che legano fra loro gli elementi del modello base sono invece le
seguenti:
•
UA (User Assignment): relazione che assegna un utente ad un ruolo.
•
PA (Permission Assgnment): relazione che assegna un permesso ad un
ruolo.
•
user: relazione che lega un utente alle sessioni da lui create.
•
roles: relazione che lega una sessione ai ruoli dell’utente attivati nella
stessa.
4.2.2
RBAC1
Il modello RBAC1 aggiunge rispetto all’RBAC0 la possibilità di definire una
gerarchia fra ruoli. Le relazioni gerarchiche sono relazioni di eredità di permessi.
In particolare se un ruolo r1 discende da un ruolo r2, allora l’insieme dei permessi
di r2 è incluso in quello dei permessi di r1, mentre l’insieme degli utenti di r1 è
incluso in quello degli utenti di r2. Ciò vuol dire che se un utente appartiene ad un
ruolo che discende da un altro, è come se fosse stato assegnato anche a
quest’ultimo e può usufruire dei permessi ad esso collegati.
Pagina 52
La figura seguente mostra un esempio di gerarchia tratto dal documento originale
del 1996.
Figura 4-2. Esempi di gerarchia di ruoli
Pagina 53
La struttura della gerarchia può essere più o meno complicata, in modo da
adattarsi perfettamente alla realtà organizzativa, che si deve gestire. La figura
seguente, sempre tratta dal documento originale dell’RBAC96 framework, mostra
una serie di gerarchie di complessità crescente.
Figura 4-3. Gerarchie di complessità crescente
Pagina 54
4.2.3
RBAC2
L’RBAC2 introduce infine la possibilità di aggiungere dei vincoli al modello base.
In generale viene prospettata la possibilità di agire su ognuna della relazioni
presenti nel modello, ma non viene fornito un elenco preciso ed esaustivo dei
vincoli che devono essere supportati.
Alcuni vincoli che vengono citati nel documento originale sono i seguenti:
•
separazione dei compiti statica e dinamica, in particolare legata a coppie di
ruoli mutuamente esclusivi
•
vincoli di cardinalità, in particolare inerenti al numero massimo o minimo
di utenti, che possono essere assegnati ad un ruolo, o di permessi che
possono essere assegnati ad uno stesso ruolo
•
vincoli di prerequisito, in particolare vincoli che impongono ad un utente
di avere già assegnati uno o più ruoli ben precisi, prima di potersi vedere
assegnato un certo altro ruolo
In questo ambito viene sottolineato il fatto che i legami gerarchici fra ruoli
possono essere anche considerati dei vincoli. Infatti le relazioni di eredità
impongono al ruolo figlio di portare con sé anche tutti i permessi, che erano stati
assegnati al ruolo padre.
4.2.4
RBAC3
L’RBAC3 è l’unione dei precedenti tre modelli e viene anche definito “modello
consolidato”, in quanto ingloba tutte le funzionalità del controllo d’accesso basato
su ruoli, ovvero le gerarchie ed i vincoli
La figura seguente, anch’essa tratta come le precedenti dal documento originale
del 1996, mostra l’architettura dell’RBAC3, all’interno della quale si possono
individuare i singoli modelli RBAC0, RBAC1 e RBAC2.
Pagina 55
Figura 4-4. RBAC 3: unione dei modelli RBAC 0, 1, 2
4.3 Descrizione formale
Di ognuno dei modelli presentati nei paragrafi precedenti viene ora fornita una
descrizione formale.
4.3.1
RBAC0
Il modello si compone dei seguenti elementi:
•
Users (U), Roles (R), Permissions (P) e Sessions (S), ovvero gli insiemi di
utenti, ruoli, permessi e sessioni.
•
PA ⊆ P x R, relazione molti-a-molti di assegnazione permessi-ruoli.
•
UA ⊆ U x R, relazione molti-a-molti di assegnazione utenti-ruoli.
•
user: S Æ U, funzione di mapping tra gli utenti e le relative sessioni.
•
roles: S Æ 2R, funzione di mapping tra una sessione ed i ruoli attivati
dall’utente in quella sessione. Formalmente: roles (si) ⊆ { r ∈ R | (user (si),
r) ∈ UA}.
Pagina 56
4.3.2
RBAC1
Il modello si compone dei seguenti elementi:
•
Users (U), Roles (R), Permissions (P) e Sessions (S), ovvero gli insiemi di
utenti, ruoli, permessi e sessioni. [Invariato rispetto all’RBAC0]
•
PA ⊆ P x R, relazione molti-a-molti di assegnazione permessi-ruoli.
[Invariato rispetto all’RBAC0]
•
UA ⊆ U x R, relazione molti-a-molti di assegnazione utenti-ruoli.
[Invariato rispetto all’RBAC0]
•
user: S Æ U, funzione di mapping tra gli utenti e le relative sessioni.
[Invariato rispetto all’RBAC0]
•
RH ⊆ R x R, ordine parziale sull’insieme dei ruoli, detto anche relazione
di ereditarietà; si indica con il simbolo ”≥”.
•
roles: S Æ 2R, funzione di mapping tra una sessione ed i ruoli attivati
dall’utente in quella sessione. Formalmente: roles (si) ⊆ { r ∈ R | ∃r’ ≥ r :
(user (si), r’) ∈ UA}.
4.3.3
RBAC2
Il modello aggiunge rispetto all’RBAC0 i vincoli precedentemente discussi, che
vanno a determinare se i vari elementi (entità e relazioni) che lo compongono
sono accettabili, oppure no.
Non viene fornita in questo caso una descrizione dei vincoli supportati, in quanto
nel documento originale questi ultimi non sono stati formalizzati ed elencati con
precisione.
4.3.4
RBAC3
Quest’ultimo modello non è altro che l’unione dei precedenti, quindi la sua
descrizione formale è direttamente ricavabile da quelle fornite nei paragrafi
precedenti:
•
Users (U), Roles (R), Permissions (P) e Sessions (S), ovvero gli insiemi di
utenti, ruoli, permessi e sessioni. [RBAC0]
Pagina 57
•
PA ⊆ P x R, relazione molti-a-molti di assegnazione permessi-ruoli.
[RBAC0]
•
UA ⊆ U x R, relazione molti-a-molti di assegnazione utenti-ruoli.
[RBAC0]]
•
user: S Æ U, funzione di mapping tra gli utenti e le relative sessioni.
[RBAC0]
•
RH ⊆ R x R, ordine parziale sull’insieme dei ruoli, detto anche relazione
di ereditarietà; si indica con il simbolo ”≥”. [RBAC1]
•
roles: S Æ 2R, funzione di mapping tra una sessione ed i ruoli attivati
dall’utente in quella sessione. Formalmente: roles (si) ⊆ { r ∈ R | ∃r’ ≥ r :
(user (si), r’) ∈ UA}.[RBAC1]
•
VINCOLI [RBAC2]
Pagina 58
CAPITOLO 5
LO STANDARD RBAC
PROPOSTO DAL NIST
In questo capitolo viene descritto lo standard
RBAC proposto dal NIST (National Institue of
Standards and Technology) allo scopo di
unificare e condensare le caratteristiche del
controllo d’accesso basato su ruoli in un unico
documento. Dopo aver illustrato l’architettura
del sistema ed aver presentato una panoramica
delle sue componenti, si procederà ad una
descrizione del modello concettuale sul quale
quest’ultima è basata. Infine verranno descritte
le specifiche funzionali dello standard e
l’organizzazione
in
packages
dei
suoi
componenti principali.
Pagina 59
5.1 Presentazione dello standard
Nel 2000 un gruppo di studiosi del NIST (National Institue of Standards and
Technology) e di altri enti di standardizzazione composto da Ferraiolo, Sandhu,
Gavrila, Kuhn e Chandramouli, ha proposto uno standard RBAC [23] allo scopo
di unificare le caratteristiche principali del controllo d’accesso basato su ruoli
universalmente riconosciute ed implementate in una parte significativa di prodotti
commerciali.
La descrizione formale dello standard, così come viene proposta nel documento
ufficiale, è suddivisa in due parti principali:
1) La prima definisce il modello concettuale dell’RBAC, offrendone una
trattazione del tutto teorica e formale.
2) La seconda illustra invece la specifica funzionale degli elementi costituivi
dell’RBAC e le loro caratteristiche distintive, in modo da permettere la
creazione, la modifica e la manutenzione di un vero e proprio sistema di
controllo d’accesso basato su ruoli.
Sia il modello concettuale che le specifiche funzionali sono organizzate in quattro
sezioni (tre principali, di cui una divisa in due sotto-sezioni):
1) Core RBAC
2) Hierarchical RBAC
3) Constrained RBAC
a) Static Separation of Duty (SSD)
b) Dynamic Separation of Duty (DSD)
Ognuna di queste sezioni descrive un modello fondamentale di controllo
d’accesso con caratteristiche ben distinte dagli altri e ad essi complementare.
Infatti è possibile comporre i diversi modelli fra loro per ottenere un sistema più o
meno complesso e ricco di funzionalità, in modo da adattarsi alle più disparate
esigenze di utilizzo.
5.2 Panoramica dei modelli
Questo standard sarà alla base di quello proposto ed adottato, nonché
implementato, nella presente trattazione, di conseguenza se ne desidera fornire un
Pagina 60
resoconto attento e puntuale. Per questo motivo, prima di entrare nel dettaglio del
modello concettuale e delle specifiche formali dello standard, risulta certamente
utile offrire una panoramica delle sue componenti principali.
5.2.1
Core RBAC
Il core RBAC comprende gli elementi essenziali del controllo d’accesso. Il
concetto base dell’RBAC è ovviamente la possibilità di assegnare agli utenti i
ruoli e a questi ultimi i permessi; gli utenti ereditano quindi indirettamente i
permessi dai ruoli che possono ricoprire. Le relazioni utenti-ruoli e ruoli-permessi
sono di tipo molti-a-molti, ciò implica che:
•
un utente può essere assegnato a più ruoli
•
un ruolo può essere ricoperto da più utenti
•
un permesso può essere assegnato a diversi ruoli
•
un ruolo può avere più permessi.
Oltre ai concetti di utente, ruolo e permesso fa parte del core RBAC anche quello
di sessione, che permette un’attivazione e un disattivazione selettiva dei ruoli
facenti capo ad uno specifico utente.
Infine va sottolineato il fatto che non c’è alcuna restrizione relativa all’attivazione
dei
ruoli
del
sistema,
di
conseguenza
ogni
utente
può
attivarne
contemporaneamente diversi e quindi usufruire dei relativi permessi.
Il core RBAC contiene dunque tutte quelle funzioni necessarie alla descrizione
delle strutture appena definite e alla loro gestione.
Il core RBAC racchiude in sé tutte quelle caratteristiche, che vanno a costituire il
tradizionale controllo d’accesso basato su ruoli, così come è stato implementato
sin nei primi sistemi, giungendo pressoché inalterato attraverso le diverse
generazioni di software fino ad oggi. L’unica diversità rispetto al primo modello
del 1992 è la possibilità di attivare più di un ruolo all’interno di una sessione
utente. È dunque una tecnologia solida ed ampiamente sperimentata e validata
sul campo.
Pagina 61
5.2.2
Hierarchical RBAC
L’RBAC gerarchico aggiunge ulteriori requisiti al core RBAC per supportare la
gerarchia dei ruoli. Formalmente – dal punto di vista matematico – una gerarchia
è un ordine parziale definito su un insieme di ruoli in cui il figlio eredita dal padre
i relativi permessi ed il padre include il figlio nella lista dei suoi discendenti. Lo
standard prevede due tipi di gerarchia, quella generale e quella limitata.
General Hierarchical RBAC: permette di definire in modo arbitrario un ordine
parziale tra ruoli ed utilizzarlo come gerarchia; ciò include anche la possibilità di
avere ereditarietà multipla sia nelle relazioni utenti-ruoli, che in quelle ruolipermessi. L’ereditarietà multipla ha alcune importanti proprietà da tenere
presente. La prima riguarda a possibilità di comporre un ruolo utilizzando diversi
ruoli con minori permessi; questo può essere utile in un’organizzazione all'interno
della quale vi sono funzioni che ne inglobano al loro interno altre di minore
importanza. Una seconda proprietà è il trattamento uniforme degli assegnamenti
utenti-ruoli e
delle relazioni di ereditarietà fra ruoli. Ciò permette, se lo si
desidera, di includere nella gerarchia dei ruoli anche gli utenti, trattandoli
uniformemente a questi ultimi: è come se un utente, anziché vedersi assegnati i
ruoli, ereditasse da essi i permessi, come se fosse esso stesso un ruolo.
Limited Hierarchical RBAC: pone delle restrizioni all’ordine parziale da
utilizzare come gerarchia tra ruoli. I vincoli utilizzati possono variare a seconda
della specifica implementazione, ma generalmente si impone che la gerarchia
abbia una struttura ad albero o a foresta, evitando così l’ereditarietà multipla.
Le figure seguenti esemplificano tre diversi tipi di gerarchia:
1. ad albero
2. ad albero invertito
3. a reticolo
Pagina 62
Figura 5-1. Gerarchia ad albero
Figura 5-2. Gerarchia ad albero invertito
Figura 5-3. Gerarchia a reticolo
Pagina 63
L’RBAC gerarchico è stato introdotto come modello fondamentale, in quanto
nella pratica capita molto di frequente che diversi ruoli abbiano permessi in
comune. Senza una gerarchia i permessi dovrebbero essere ridefiniti in modo
identico per ogni singolo ruolo ed ovviamente questo causerebbe un notevole
spreco di risorse per la gestione del sistema. Infatti si perderebbe molto tempo
non solo nel definire i permessi ed assegnarli a diversi ruoli, ma soprattutto
nell’amministrazione degli stessi: le modifiche comuni dovrebbero essere ripetute
su ogni singolo ruolo con il rischio non improbabile di commettere eventuali
errori. Per migliorare l’efficienza e l’efficacia della gestione del sistema è dunque
indicato implementare la gerarchia fra ruoli, soprattutto se esso è di grandi
dimensioni.
5.2.3
Constrained RBAC
Il Constrained RBAC agglunge al modello base la separazione dei compiti.
Vi sono due tipi di separazione dei compiti, quella statica e quella dinamica, che
verranno descritte nei paragrafi seguenti.
5.2.3.1
Static Separation of Duty (SSD)
La Static Separation of Duty viene utilizzata per definire politiche di controllo
d’accesso nelle quali sono presenti conflitti d’interesse. Un esempio classico che
richiede la presenza della SSD è la definizione di ruoli mutuamente esclusivi, che
diventa indispensabile quando una determinata operazione può essere iniziata da
un certo utente, ma conclusa (o approvata) da un altro, come avviene per molte
transazioni bancarie. In questi casi la SSD permette di definire delle regole per cui
non è possibile assegnare a priori due ruoli conflittuali ad uno stesso utente.
Un’ultima precisazione va fatta nel caso in cui sia presente una gerarchia di ruoli:
i vincoli devono essere verificati non solo sui permessi assegnati direttamente al
singolo ruolo, ma anche su quelli ereditati secondo la gerarchia a cui esso
appartiene.
Un modo per prevenire i conflitti di interesse tra ruoli è quello di imporre dei
vincoli sull’assegnazione di un utente ad un ruolo. Questi vincoli possono essere
Pagina 64
espressi in modi molto differenti fra loro. Ad ogni modo nello standard proposto
dal NIST i vincoli specificati da un SSD sono espressi mediante una coppia
<role-set, n> dove role-set è un insieme di ruoli, mentre n è un numero intero che
esprime quanti ruoli, tra quelli presenti nell’insieme, possono al massimo essere
assegnati ad uno stesso utente. Se ad esempio si vuole esprimere il vincolo di due
ruoli mutuamente esclusivi, si dovranno inserire questi ultimi nel role-set e si
dovrà porre n uguale a uno, in modo tale che uno soltanto dei due ruoli possa
essere assegnato ad un determinato utente.
Dal punto di vista delle politiche di sicurezza la SSD si presenta come uno
strumento valido ed affidabile per gestire i conflitti di interesse e semplificare la
separazione dei compiti assegnati ai diversi ruoli del sistema. Generalmente i
vincoli statici vengono imposti sulle operazioni amministrative, che potrebbero
minare le politiche di Separation of Duty ad alto livello organizzativo, in quanto
sono le operazioni più critiche dal punto di vista della sicurezza.
5.2.3.2
Dynamic Separation of Duty (DSD)
La Dynamic Separation of Duty viene utilizzata, come la SSD, per limitare i
permessi a disposizione dei singoli utenti. Quello che cambia è il contesto
all’interno del quale vengono imposte queste limitazioni. La DSD infatti pone
delle restrizioni sui permessi, mettendo dei vincoli sui ruoli che possono essere
attivati all’interno di una stessa sessione dell’utente.
I vincoli della DSD sono espressi anch’essi in modo del tutto simile alla SSD,
ovvero tramite una coppia <role-set, n> dove role-set è un insieme di ruoli, scelti
tra quelli assegnati all’utente, mentre n è un numero intero, che rappresenta il
numero massimo di ruoli attivabili dall’utente all’interno di una stessa sessione.
Le proprietà definite da una DSD forniscono un valido supporto al principio del
minimo privilegio, poiché fanno in modo che un utente possa esercitare di volta in
volta diversi permessi a seconda dei differenti compiti che deve svolgere. Ciò
assicura che i permessi non persistano oltre il tempo in cui sono richiesti per
svolgere un determinato compito. Questo aspetto del minimo privilegio è anche
conosciuto come “temporary revocation of trust” (revoca temporanea di fiducia)
ed in passato è stato solitamente trascurato, in quanto non esistevano validi
Pagina 65
supporti per la sua definizione ed attuazione. Grazie alla DSD è invece possibile
supportare anche questo aspetto del principio del minimo privilegio
Va infine sottolineato il
fatto che la SSD permette di evitare un conflitto
d’interesse a priori, ovvero quando un utente viene assegnato ad un ruolo, al
contrario la DSD permette di assegnare ad un utente ruoli che possono causare
conflitti di interesse se attivati simultaneamente, ma che non lo fanno se vengono
resi operativi in modo indipendente. Il controllo dinamico permette quindi di
avere una maggiore flessibilità ed efficienza nel controllo d’accesso.
5.3 Modello concettuale
Il modello concettuale viene definito per un duplice scopo:
1. definire un vocabolario standardizzato di termini da utilizzare nella fase
successiva di stesura delle specifiche
2. definire una classificazione delle specifiche dell’RBAC in modo da
individuare diversi modelli di controllo d’accesso, ognuno con
caratteristiche peculiari
È importante notare fin da subito il fatto che il modello di riferimento definisce
una tassonomia delle caratteristiche dell’RBAC, che possono andare a costituire
un insieme di packages da sviluppare anche separatamente. Questo tema verrà
approfondito in seguito. Nei paragrafi che seguono sono invece passati in rassegna
i quattro modelli fondamentali, dei quali si è data una panoramica in precedenza,
fornendo per ognuno di essi una descrizione formale. Infatti ogni modello viene
sistematicamente suddiviso nelle seguenti componenti:
1) un insieme di elementi base
2) un insieme di relazioni tra gli elementi base definiti nel punto precedente
3) un insieme di funzioni amministrative, che mappano istanze di un
elemento base con istanze di altri elementi base.
Ognuna della componenti viene quindi analizzata singolarmente.
Pagina 66
5.3.1
Core RBAC
Elementi di base:
•
USERS (utenti del sistema): un utente è identificato in questo caso con un
essere umano, anche se il concetto può essere esteso a macchine, reti o
agenti intelligenti autonomi.
•
ROLES (ruoli dell’organizzazione): un ruolo è identificato con un
determinato compito all’interno di un’organizzazione, al quale è legata una
certa semantica riguardo la responsabilità e l’autorità che esso rappresenta.
•
OBJECTS (oggetti del sistema): un oggetto è un’entità che riceve o
contiene informazione.
•
OPERATIONS (operazioni sugli oggetti del sistema): un’operazione è un
programma eseguibile che svolge un certa funzione per l’utente che lo
invoca.
•
PERMISSIONS (permessi di accesso): un permesso è la possibilità di
eseguire un’operazione su uno o più oggetti protetti.
•
SESSIONS (sessioni utente): una sessione è un sottoinsieme dei ruoli
attivabili dall’utente. Ogni sessione è associata da un unico utente, mentre
un utente può attivare più sessioni contemporaneamente.
Relazioni tra gli elementi di base:
•
UA (User Assignment): assegnazione di un ruolo ad un utente (o
viceversa).
•
PA (Permission Assignment): assegnazione di un permesso ad un ruolo (o
viceversa).
•
user_sessions: funzione che restituisce le sessioni attivate dall’utente.
•
session_roles: funzione che restituisce i ruoli attivati da una sessione.
La figura seguente illustra gli elementi base del core RBAC e le relazioni che li
legano. In particolare la doppia freccia indica le relazioni molti-a-molti, mentre la
freccia singola indice una relazione uno-a-molti.
Pagina 67
Figura 5-4. Core RBAC
Segue ora una descrizione formale del core RBAC, che comprende tutte le
funzioni amministrative necessarie al corretto funzionamento del sistema:
•
USERS, ROLES, OPS e OBS, gli insiemi di utenti, ruoli, operazioni ed
oggetti.
•
UA ⊆ USERS x ROLES, una relazione di mapping molti-a-molti
dell’assegnazione utenti-ruoli.
•
Assigned_users: (r:ROLES) Æ 2USERS, funzione di mapping di un ruolo
sui suoi utenti. Formalmente: assigned_users(r) = {u ∈ USERS | (u, r) ∈
UA}.
•
PRMS = 2(OPS x OBS), l’insieme dei permessi.
•
PA ⊆ PRMS x ROLES, una relazione di mapping molti-a-molti
dell’assegnazione permessi-ruoli.
•
Assigned_permissions (r: ROLES) Æ 2PRMS, funzione di mapping di un
ruolo sui suoi permessi. Formalmente: assigned permissions(r) = {p ∈
PRMS | (p, r) ∈ PA}.
•
Ob(p: PRMS) Æ {op ⊆ OPS}, funzione di mapping permessi-operazioni,
che restituisce l’insieme di operazioni associate al permesso p.
•
Ob(p: PRMS) Æ {ob ⊆ OBS}, funzione di mapping permessi-oggetti, che
restituisce l’insieme di oggetti associati al permesso p.
•
SESSIONS, l’insieme delle sessioni.
Pagina 68
•
User_sessions (u: USERS) Æ 2SESSIONS, la funzione di mapping tra un
utente ed il suo insieme di sessioni.
•
Session_roles (s: SESSIONS) Æ 2ROLES, la funzione di mapping tra una
sessione ed i ruoli attivati. Formalmente: session_roles (si) ⊆ { r ∈ ROLES
| (user_sessions (si), r) ∈ UA}.
•
Avail_session_perms (s:SESSIONS) Æ 2PRMS, funzione che restituisce i
permessi disponibili ad un utente durante una sessione.
5.3.2
Hierarchical RBAC
Elementi di base:
•
Tutti gli elementi di base del core RBAC
•
Relazioni tra gli elementi di base
•
Tutte le relazioni del core RBAC
•
ROLE HIERARCHY (gerarchia tra ruoli): definisce una relazione di
ereditarietà tra ruoli. L’ereditarietà è espressa in termini di permessi,
ovvero il ruolo figlio eredita i permessi del padre e li tramanda ai suoi
discendenti.
La figura seguente mostra la relazione di gerarchia tra ruoli che sia aggiunge al
modello del core RBAC visto in precedenza.
Pagina 69
Figura 5-5. Hierarchical RBAC
Segue ora una descrizione formale del hierarchical RBAC, che comprende tutte le
funzioni amministrative necessarie al corretto funzionamento del sistema:
•
RH ⊆ ROLES x ROLES, ordine parziale sull’insieme dei ruoli, detto
anche relazione di ereditarietà ed indicato con “≥”. Inoltre si ha: r1 ≥ r2 ⇒
authorized_permissions(r2)
⊆
authorized_permissions(r1)
∧
authorized_users(r1) ⊆ authorized_users(r2).
•
authorized_users(r: ROLES) Æ 2USERS, funzione di mapping tra un ruolo
ed il corrispondente insieme di utenti in presenza di una gerarchia tra ruoli.
Formalmente authorized_users(r) ={u ∈ USERS | r’ ≥ r , (u,r’) ∈ UA}
•
authorized_permissions(r: ROLES) Æ 2PRMS, funzione di mapping tra un
ruolo ed il corrispondente insieme di permessi in presenza di una gerarchia
tra ruoli. Formalmente authorized_users(r) ={p ∈ PRMS | r’ ≥ r , (p,r’) ∈
PA}.
•
[Ereditarietà non multipla] in presenza di una gerarchia fra ruoli limitata in
modo tale da evitare l’ereditarietà multipla, va aggiunto il vincolo che
permette ad un ruolo di ereditare i permessi da un solo altro ruolo: r1 ≥ r ∧
r2 ≥ r ⇒ r1 = r2.
Pagina 70
5.3.3
Constrained RBAC
Il constrained RBAC aggiunge la separazione dei compiti al modello base. Come
illustrato nella figura seguente i nuovi vincoli che si vanno ad aggiungere al
modello possono benissimo convivere con la presenza di una gerarchia fra ruoli.
Ovviamente in questo caso sarà maggiormente complesso verificare il rispetto dei
vincoli a causa della presenza dell’ereditarietà tra ruoli.
Elementi base:
•
SSD, insieme dei vincoli per la static separation of duty
•
DSD, insieme dei vincoli per la dynamic separation of duty
Relazione tra gli elementi base:
•
Nessuna relazione aggiuntiva
Figura 5-6. Constrained RBAC: SSD
Pagina 71
Figura 5-7. Constrained RBAC: DSD
Segue ora una descrizione formale del constrained RBAC, che comprende tutte le
funzioni amministrative necessarie al corretto funzionamento del sistema:
•
[SSD semplice] SSD ⊆ (2ROLES x N), un insieme di vincoli SSD, che
impongono che nessun utente possa avere assegnati più di ‘n’ ruoli
all’interno del role set ‘rs’, formalmente ∀(rs, n)∈SSD, ∀ t ⊆ rs : |t| ≥ n ⇒
∩r∈t assigned_users(r) = ∅
•
[SSD con gerarchia fra ruoli] viene ridefinita la precedente formulazione
utilizzando i ruoli autorizzati, anziché semplicemente quelli assegnati agli
utenti: ∀(rs, n)∈SSD, ∀ t ⊆ rs : |t| ≥ n ⇒ ∩r∈t authorized_users(r) = ∅
•
[DSD] DSD ⊆ (2ROLES x N), un insieme di vincoli DSD, che impongono
che nessun utente possa attivare più di ‘n’ ruoli all’interno del role set ‘rs’
Formalmente si ha che:
o ∀rs ∈ 2ROLES , n ∈ N (rs, n) ∈ DSD ⇒ |rs| ≥ n
o ∀ s ∈ SESSIONS, ∀rs ∈ 2ROLES , ∀role_subset ∈ 2ROLES, ∀ n ∈ N,
(rs, n) ∈ DSD, role_subset ⊆ rs, role_subset ⊆ session_roles ⇒
|role_subset| ≤ n
5.4 Specifiche funzionali
Le specifiche funzionali definiscono i requisiti che deve avere una
implementazione del controllo d’accesso basato su ruoli per rispettare lo standard
Pagina 72
descritto dal modello concettuale. Nel paragrafo precedente è stato illustrato
quest’ultimo suddividendolo in quattro modelli fondamentali, ognuno dei quali
era formato da tre componenti astratti: gli elementi base, le relazioni e le funzioni
amministrative. A questo punto è dunque necessario mappare il modello
concettuale e le sue componenti astratte in requisiti funzionali concreti, che
permettano di implementare correttamente lo standard RBAC definito.
In questo paragrafo viene definita la semantica di varie funzioni per creare e
mantenere i diversi componenti del modello RBAC (elementi base e relazioni),
nonché per supportare le funzioni di amministrazione del sistema. Tutte queste
funzioni posso essere organizzate ordinatamente in diversi packages, in modo da
rispettare i diversi livelli di astrazioni così come definiti nel modello concettuale.
Possono essere individuate tre categorie principali funzioni:
1) Administrative functions (funzioni amministrative): creano e mantengo gli
elementi base del modello RBAC e le loro relazioni, permettendo di
costruire i diversi componenti.
2) Supporting System Functions (funzioni di sistema): supportano i costrutti
del modello RBAC durante l’interazione dell’utente con il sistema (es.
gestione degli attributi di sessione e logica decisionale del controllo
d’accesso).
3) Review functions (funzioni di reportistica): visualizzano i risultati prodotti
dalle azioni delle altre funzioni.
5.4.1
Core RBAC
1) Funzioni amministrative
Creazione e manutenzione degli elementi base
Gli elementi d base sono gli utenti, i ruoli, le operazioni e gli oggetti. Devono
essere dunque presenti tutte le operazioni di creazione ed eliminazione di utenti e
ruoli, mentre non si gestiscono le funzioni per creare ed eliminare le operazioni e
gli oggetti di sistema, in quanto si suppone che questi siano già presenti nel
sistema. Di conseguenza le uniche funzioni da implementare in questo caso sono
le seguenti:
•
addUser
Pagina 73
•
deleteUser
•
addRole
•
deleteRole
Creazione e manutenzione delle relazioni
Le relazioni principali del core RBAC sono l’assegnazione utente-ruolo e ruolipermesso; dovranno quindi essere presenti le seguenti funzioni per creare e
distruggere queste relazioni:
•
assingUser
•
deassignUser
•
grantPermission
•
revokePermssion
2) Funzioni di sistema
Queste funzioni sono necessarie per la gestione delle sessioni utente e per
prendere le decisioni di controllo d’accesso. In primo luogo è necessario poter
attivare e disattivare un ruolo di un utente all’interno di una sua sessione. Ancora
prima deve quindi essere possibile creare una sessione, che per default dovrà
attivare un set di ruoli dell’utente per iniziare la stessa. Ovviamente l’insieme di
ruoli di default potrà poi essere alterato tramite l’utilizzo delle funzioni di
attivazione e disattivazione. Infine dovrà essere presente una funzione che
controlli se l’utente in quella sessione ha il permesso di accedere ad un oggetto di
sistema o di svolgere una determinata operazione. Le funzioni di sistema sono
dunque le seguenti:
•
CreateSession
•
AddActiveRole
•
DropActiveRole
•
CheckAccess
3) Funzioni di reportistica
Quando vengono creati degli assegnamenti utente-ruolo o delle istanze di
relazioni permesso-ruolo, deve essere possibile verificare l’esistenza di queste
ultime sia dal punto di vista degli utenti, che da quello dei ruoli. Inoltre deve
Pagina 74
essere possibile vedere il risultato delle funzioni di supporto sistema per
determinare il valore di certi attributi delle sessioni in corso, come ad esempio i
ruoli attivi di un utente. Per questo motivo è necessario implementare le seguenti
funzioni:
•
assignedUsers
•
assignedRoles
•
rolePermissions
•
userPermissions
•
sessionActiveRoles
•
sessionPermissions
•
roleOperationsOnObject
•
userOperationsOnObject
In realtà solo le prime due funzioni devono essere obbligatoriamente
implementate, mentre tutte le successive non sono indispensabili per il corretto
funzionamento del sistema, ma sono comunque di grande utilità per facilitarne la
gestione.
5.4.2
Hierarchical RBAC
1) Funzioni amministrative
Le funzioni amministrative richieste dall’RBAC gerarchico includono tutte le
funzioni amministrative del core RBAC. Va sottolineato il fatto che la semantica
della funzione deassignUser() deve essere ridefinita, poiché la presenza della
gerarchia dei ruoli dà vita al concetto di “ruoli autorizzati” per un utente. In altre
parole un utente può ereditare i permessi di ruoli, che non gli sono stati assegnati
direttamente, ma che fanno parte della gerarchia dalla quale discende un ruolo
assegnatogli direttamente. Un’importante caratteristica è dunque quella di poter
deassegnare da un utente non solo i ruoli assegnatigli direttamente, ma anche
quelli ereditati.
Le funzioni amministrative aggiuntive, rispetto a quelle già presenti nel core
RBAC riguardano la creazione e la manutenzione dell’ordine parziale che viene
usato come gerarchia fra ruoli e sono le seguenti:
•
addInheritance
Pagina 75
•
deleteInheritance
•
addAscendant
•
deleteAscendant
•
addDescendant
•
deleteDescendant
Il modello prevede anche la possibilità di porre vincoli sull’ordinamento parziale
utilizzato per creare la gerarchia tra ruoli. Solitamente si fa in modo che la
struttura di quest’ultima sia ad albero, evitando in questo modo di avere
ereditarietà multipla tra ruoli. Per avere una gerarchia limitata è dunque necessario
modificare le diverse funzioni in modo che ogni ruolo accetti un solo genitore.
2) Funzioni di sistema
Le funzioni di sistema per l’RBAC gerarchico sono le stesse del core RBAC e
forniscono le stesse funzionalità. Solamente le funzioni createSession e
addActiveRole devono essere ridefinite a causa della presenza della gerarchia fra i
ruoli. Infatti l’attivazione di un ruolo può implicare o meno (la scelta non è
definita) quella dei ruoli da cui esso discende secondo la gerarchia esistente.
3) Funzioni di reportistica
Tutte le funzioni di reportistica definite per il core RBAC rimangono valide. Ad
esse vanno aggiunte una le funzioni per rilevare la corretta configurazione della
gerarchia dei ruoli. In primo luogo l’insieme degli utenti che appartengono ad un
stesso ruolo include non solo quelli assegnati direttamente a quest’ultimo, ma
anche tutti quelli assegnatigli indirettamente. Analogamente i ruoli assegnati ad
un utente comprendono anche tutti quelli ereditati indirettamente. Per le stesse
ragioni l’insieme dei permessi relativi ad un singolo ruolo non include solo quelli
assegnatigli direttamente, ma anche quelli ottenuti tramite l’ereditarietà della
gerarchia, e questi si riflettono sugli utenti che sono stati assegnati a quel ruolo.
Le funzioni di reportistica aggiuntive sono dunque le seguenti:
•
authorizedUsers
•
authorizedRoles
Pagina 76
5.4.3
Static Separation of Duty (SSD)
1) Funzioni amministrative
Le funzioni amministrative per il modello RBAC con SSD senza gerarchia fra
ruoli includono tutte quelle del core RBAC. L’unico accorgimento è il fatto che la
funzione assingUser deve incorporare la verifica dei vincoli della SSD. È
possibile definire un vincolo SSD tramite un nome, un insieme di ruoli ed una
cardinalità; il primo è semplicemente un’etichetta identificativa del vincolo stesso,
mentre la cardinalità esprime il numero massimo di ruoli, scelti all’interno
dell’insieme specificato, che un utente può attivare contemporaneamente.
Vi sono dunque funzioni amministrative aggiuntive, necessarie alla creazione e
alla cancellazione dei vincoli SSD, all’aggiunta e alla rimozione dei ruoli facenti
parte di questi ultimi, nonché all’impostazione del valore della loro cardinalità.
Segue un elenco delle funzioni appena illustrate:
•
createSSDSet
•
deleteSSDSet
•
addSSDRoleMember
•
deleteSSDRoleMember
•
setSSDCardinality
Nel caso in cui si volesse gestire l’RBAC gerarchico (sia nel caso generale che in
quello limitato) le funzioni introdotte da quest’ultimo producono lo stesso
risultato con una sola eccezione: i vincoli che intervengono sulla gerarchia e quelli
di SSD devono essere verificati contemporaneamente ogni volta che queste
funzioni vengono invocate.
2) Funzioni di sistema
Le funzioni di sistema sono le stesse di quelle già presentate per il core RBAC.
3) Funzioni di reportistica
Tutte la funzioni di reportistica per il core RBAC sono necessarie per il corretto
funzionamento dell’SSD RBAC. Oltre a queste funzioni base ne vanno aggiunte
Pagina 77
delle altre per ottenere l’elenco dei vincoli SSD, quello dei ruoli assegnati ad
ognuno di questi ultimi e la relativa cardinalità.
Ecco dunque l’elenco delle funzioni di reportistica aggiuntive:
•
SSDRoleSets
•
SSDRoleSetRoles
•
SSDRoleSetCardinality
5.4.4
Dynamic Separation of Duty (DSD)
1) Funzioni amministrative
La semantica della creazione di un vincolo DSD è identica a quella relativa al
modello SSD. La differenza risiede nel contesto in cui viene fatto il controllo sui
vincoli; infatti, mentre per l’SSD RBAC questo veniva attivato durante
l’assegnazione di un utente ad un ruolo, ora è inserito al momento dell’attivazione
di un ruolo all’interno di una sessione.
Di seguito è riportato l’elenco delle funzioni amministrative che devono essere
implementate per il modello DSD RBAC:
•
createDSDSet
•
deleteDSDSet
•
addDSDRoleMember
•
deleteDSDRoleMember
•
setDSDCardinality
2) Funzioni di sistema
Le funzioni di sistema del core RBAC (createSession, addActiveRole e
deleteActiveRole) devono essere presenti anche per il DSD RBAC, ovviamente se
non si prevede di utilizzare anche la gerarchia tra ruoli; in tal caso deve essere
preso come base il modello gerarchico dell’ RBAC. In entrambi i casi queste
funzioni devono essere modificate, in modo da verificare anche i vincoli imposti
dalla DSD. Per esempio la funzione di creazione di una nuova sessione deve
verificare che il set di ruoli attivati per default non violi i vincoli della DSD; lo
stesso vale per la funzione di attivazione di un nuovo ruolo.
Pagina 78
3) Funzioni di reportistica
Tutte le funzioni di reportistica del core RBAC sono necessarie anche per il
modello DSD. In aggiunta a queste ultime vi sono altre tre funzioni, una per avere
l’elenco dei vincoli DSD creati, un’altra per ottenere l’insieme dei ruoli assegnati
a questi ultimi ed un’ultima per conoscerne la cardinalità:
•
SystemRBAC.DSDRoleSets
•
DSDSet.DSDRoleSetRoles
•
DSDSet.DSDRoleSetCardinality
5.5 I packages
Come anticipato nei paragrafi precedenti lo standard RBAC proposto dal NIST
può essere organizzato in modo organico in diversi packages. I quattro
componenti fondamentali (core, hierarchical, SSD e DSD) possono essere
direttamente mappati su rispettivi packages, disposti secondo la gerarchia
illustrata nella figura seguente, in modo da sfruttare il meccanismo
dell’ereditarietà per propagare le caratteristiche di un livello superiore della
gerarchia ai livelli sottostanti più specializzati.
Pagina 79
Figura 5-8. Packages dello standard RBAC
In particolare le caratteristiche del core RBAC devono essere propagate su tutta la
gerarchia dei packages, in quanto comprendono funzioni base dalla quali dipende
il corretto funzionamento dell’intero sistema. È poi possibile scegliere se
implementare in aggiunta al package principale anche l’RBAC gerarchico
(generale o limitato), la SSD (con o senza gerarchia) o la DSD, combinando i
diversi modelli in tutti i modi possibili. Ogni componente può dunque essere
implementato opzionalmente con l’unica eccezione del core RBAC, che deve
essere incluso in ogni package.
Va infine sottolineato il fatto che questo è un approccio funzionale alla
suddivisione in packages dello standard e che di conseguenza per passare ad
un’implementazione reale e funzionante dovranno essere apportate delle
modifiche strutturali per adattare lo schema concettuale all’architettura
dell’applicazione.
La tabella seguente mostra un riassunto delle diverse funzioni che un sistema
RBAC deve implementare per seguire lo standard proposto dal NIST organizzate
secondo la distribuzione in packages appena illustrata.
Pagina 80
Funzioni
Package
Core
Funzioni
Funzioni di
Funzioni di
amministrative
sistema
reportistica
•
Add user
•
Create session
•
Assigned users
•
Delete user
•
Delete session
•
Assigned roles
•
Add role
•
Add active role •
Role permissions
•
Delete role
•
Drop active
•
User permissions
•
Assign user
role
•
Session roles
•
Deassign user
Check access
•
Session permission
•
Grant permission
•
Role operations on
•
Revoke permission
•
object
•
User operations on
object
•
Add inheritance
•
Create session
•
Authorized users
•
Delete inheritance
•
Add active role •
Authorized roles
•
Add ascendant
•
Role permissions
Add descendant
•
User permissions
•
Role operations on
Hierarchical •
(general)
object
•
User operations on
object
Hierarchical •
Add inheritance
(limited)
SSD
SSD (general
hierarchy)
/
/
•
Assign user
•
Ssd role sets
•
Create SSD set
•
Ssd role set roles
•
Delete SSD set
•
Ssd role set cardinality
•
AddSsdRoleMember
•
DeleteSsdRoleMember
•
SetSsdSetCardinality
•
Assign user
•
Add inheritance
•
Create SSD set
•
AddSsdRoleMember
•
SetSsdSetCardinality
/
/
/
Pagina 81
SSD (limited •
Add inheritance
/
hierarchy)
DSD
•
Create DSD set
•
Create session
•
Delete DSD set
•
Add active role •
•
AddDsdRoleMember
•
DeleteDsdRoleMember
•
SetDsdSetCardinality
DSD
(general
/
/
•
•
•
Create session
•
Add active role
Dsd role sets
Dsd role set roles
Dsd role set cardinality
/
hierarchy)
DSD (limited
hierarchy)
/
/
/
Tabella 5-1. Funzioni e packages dello standard RBAC
Pagina 82
CAPITOLO 6
ANALISI CRITICA DEL
MODELLO
In questo capitolo verranno discusse tutte le
problematiche non ancora messe in luce
riguardanti lo standard RBAC presentato in
precedenza. Si tratta di una discussione critica
sulle possibili varianti di cui si deve tener conto,
se si vuole procedere ad una implementazione
funzionante e non banale del modello stesso.
Appare dunque evidente come la distanza tra
teoria e pratica sia a volte non indifferente e
dunque si può apprezzare quanto lavoro sia
ancora necessario prima di tradurre in atto una
teoria in apparenza lineare e facilmente
applicabile.
Pagina 83
6.1 Attivazione
e
disattivazione
dei
ruoli
Uno dei primi problemi che si devono affrontare non appena si decide di
implementare un qualsiasi modello di RBAC è quello relativo alle tempistiche
relative all’attivazione e alla disattivazione dei ruoli.
L’attivazione non è un meccanismo particolarmente complesso, in quanto un
ruolo viene di norma attivato all’occorrenza, ovvero quando l’utente richiede di
agire su una risorsa protetta ed i privilegi necessari sono legati ad un suo ruolo
non ancora attivo. In questo caso, una volta verificato il rispetto di eventuali
vincoli, quest’ultimo deve essere attivato.
Un’attenzione particolare va prestata nel definire i ruoli che vengono attivati di
default all’inizio di ogni sessione utente. Questo insieme di ruoli non deve
assolutamente violare nessun vincolo, altrimenti un utente potrebbe nel peggiore
dei casi non riuscire nemmeno ad accedere al sistema. Per evitare che ciò accada
si può procedere in due modi differenti:
1. Effettuare un controllo d’integrità all’avvio del sistema, che segnali
eventuali inconsistenze dello stesso.
2. Attivare un ruolo di default alla volta, in modo che, qualora un vincolo
non sia rispettato, si possa procedere alla disattivazione del/i ruolo/i
incriminato/i.
Per quanto riguarda invece il meccanismo di disattivazione, si possono
individuare due principali varianti:
1. La prima scelta possibile è quella di attivare un ruolo e non disattivarlo
mai, se non in presenza di un vincolo (ad esempio di separazione dei
compiti) per cui sia necessario farlo, in modo da poterne attivare un altro.
2. La seconda alternativa consiste, contrariamente al caso precedente, nel
disattivare ogni ruolo non appena il privilegio resosi necessario è stato
utilizzato.
La prima soluzione sovraccarica meno il sistema rispetto alla seconda, che impone
una continua attivazione e disattivazione dei ruoli. L’unico difetto potrebbe essere
Pagina 84
quello di non supportare pienamente il principio del minimo privilegio, poiché in
un certo istante un utente ha più permessi di quelli realmente necessari. Tuttavia,
se si percorre la seconda strada, si incorre nello spiacevole inconveniente di
attivare e disattivare continuamente un ruolo, nel caso in cui l’utente utilizzi più
volte, durante una sua sessione, i privilegi dello stesso. Essendo questa evenienza
tutt’altro che improbabile, si corre il rischio di sovraccaricare parecchio il sistema
e rallentarne l’esecuzione con gravi disservizi per gli utenti.
Infine per completezza va fatta un’ultima considerazione, anche se ovvia, ovvero
va ricordato il fatto che si possono studiare numerosi altri metodi per gestire il
meccanismo di attivazione e disattivazione dei ruoli. Ad esempio si può pensare
di disattivare un ruolo dopo un certo lasso di tempo, che può essere calcolato
rispetto all’istante di attivazione, oppure rispetto all’ultimo utilizzo di un suo
permesso, ma anche in base ad altre politiche. Tutte queste soluzioni, oltre a
complicare il modello, non fanno altro che caricare il sistema di lavoro, in quanto
aggiungono vincoli che devono essere controllati, di conseguenza è bene
utilizzarli solo nei casi specifici, in cui si ritiene che siano strettamente necessari.
6.2 Le gerarchie
L’RBAC gerarchico permette di definire gerarchie di ruoli anche molto
complesse. Da un lato questa caratteristica è certamente un aspetto positivo del
modello, in quanto ne fa crescere la flessibilità, che si concretizza in una maggiore
aderenza alla realtà organizzativa che si deve amministrare. Dall’altro lato però ne
aumenta la complessità, poiché l’ereditarietà tra ruoli va ad influenzare le altre
relazioni del modello ed i vincoli su di esse. Infatti da un punto di vista pratico le
relazioni di ereditarietà tra ruoli possono essere considerate dei vincoli sulla
relazione PA (Permission Assigment) del modello RBAC. Ogni volta che un ruolo
viene assegnato ad un altro come figlio, o come padre, è come se fosse stato
aggiunto un vincolo che impone al figlio di avere tutti i permessi del padre, oltre a
quelli assegnatigli direttamente.
I paragrafi seguenti analizzano alcuni problemi che si vengono a creare quando si
introduce la gerarchia tra ruoli all’interno di un modello RBAC.
Pagina 85
6.2.1
Gerarchia ed attivazione dei ruoli
Una delle prime scelte da compiere in relazione all’introduzione della gerarchia
tra ruoli riguarda l’attivazione di questi ultimi. Il problema sembra banale, ma si
vedrà nei paragrafi seguenti come questa scelta abbia delle ripercussioni anche su
altri elementi del modello.
Quando un utente attiva un determinato ruolo all’interno di una sua sessione è
necessario decidere se attivare anche i ruoli dai quali esso discende oppure no.
Entrambe le scelte possono trovare delle giustificazioni plausibili in base al
contesto applicativo di interesse. Nel primo caso si può pensare che, se un utente
cerca di attivare il permesso relativo ad un certo ruolo, avrà in seguito bisogno di
utilizzare anche i permessi dei ruoli padri, in quanto completano il quadro delle
attività che l’utente solitamente svolge. Attivando in un unico momento tutta la
gerarchia dei ruoli da cui discende quello esplicitamente richiesto, il sistema viene
sgravato di un buon carico di lavoro, poiché non deve ripetere più volte il
processo di attivazione. Nel secondo caso invece questa ottimizzazione
prestazionale viene meno, ma l’aderenza al principio del minimo privilegio è
maggiore, in quanto non si verifica mai un’attivazione di permessi non
esplicitamente richiesti e ogni utente ha in un preciso istante soltanto i privilegi di
accesso che gli sono strettamente necessari.
Considerazioni del tutto analoghe possono essere fatte nel caso di una gerarchia
limitata. Anzi, questa osservazione dà modo di sottolineare il fatto che possono
esistere anche delle soluzioni intermedie rispetto alle due appena prospettate. Ad
esempio si può decidere di attivare in automatico solo parte della gerarchia dei
ruoli padre secondo criteri di volta in volta differenti. Tuttavia questi meccanismi
sempre più flessibili hanno come effetto collaterale una maggiore complessità del
modello e conseguentemente un maggior carico di lavoro per il sistema. È bene
dunque introdurre queste tecniche solamente in casi particolari, dove ce ne sia
realmente bisogno.
6.2.2
Gerarchia e disattivazione dei ruoli
Il problema inverso a quello precedente riguarda la disattivazione dei ruoli in
presenza di una gerarchia. In particolare si deve scegliere se disattivare o meno i
Pagina 86
ruoli padre ogni qualvolta viene disattivato un ruolo figlio. Vi possono essere
diversi meccanismi per la disattivazione dei ruoli, tra i quali i seguenti risultano
essere i principali:
1. i ruoli padri non vengono mai disattivati automaticamente in
corrispondenza di una disattivazione di un ruolo figlio
2. un ruolo padre viene sempre disattivato automaticamente, ogni qualvolta
un ruolo figlio viene disattivato
3. un ruolo padre viene disattivato in automatico solamente quando sono stati
disattivati tutti i suoi ruoli figli
4. un ruolo padre viene disattivato automaticamente se e solo se era stato
attivato a causa dell’attivazione di un ruolo figlio e quest’ultimo viene
disattivato
Ovviamente si potrebbe proseguire con l’elenco ed individuare meccanismi di
disattivazione sempre più complessi, ma valgono le stesse considerazioni fatte in
precedenza sul carico di lavoro, che si va a riversare sul sistema. Inoltre una
gestione complessa di questi meccanismi, che sono basilari per il modello,
potrebbe portare ad implementazioni non correttamente funzionanti, con falle di
sicurezza dannose per l’intero sistema.
NOTA: La scelta riguardo l’attivazione e la disattivazione (implicite o esplicite)
dei ruoli padre non è semplicemente una questione tecnica, ma implica una
visione differente circa il concetto di gerarchia ed ereditarietà.
Se ad esempio ci si pone in un’ottica del tutto simile a quella di un linguaggio ad
oggetti, l’attivazione dei permessi dei ruoli padri dovrebbe essere automatica, in
quanto il ruolo figlio è visto come una specializzazione del padre e quindi ne
ingloba tutte le funzionalità.
Se invece si considerano i ruoli come semplici contenitori di permessi e se le
relazioni gerarchiche fra di essi sono viste semplicemente come un modo per
evitare di assegnare più volte gli stessi privilegi a ruoli differenti, allora non ci si
deve scandalizzare se si decide di attivare i permessi di un ruolo alla volta, senza
seguirne la gerarchia. Dunque l’ereditarietà è vista in questo caso come una
Pagina 87
tecnica amministrativa e non funzionale, come al contrario accedeva in
precedenza.
6.2.3
Gerarchia e separazione dei compiti
L’impatto più evidente che una gerarchia tra ruoli ha sul modello RBAC è
certamente quello relativo alla separazione dei compiti. Il fatto che i ruoli figli
ereditino tutti i permessi dei padri complica notevolmente il processo di verifica
dei vincoli statici e dinamici (SSD e DSD).
Quando un ruolo viene inserito nella gerarchia dei discendenti di un altro ruolo, il
sistema si deve assicurare che i vincoli relativi alla separazione dei compiti siano
ancora rispettati.
Per quanto riguarda la SSD il problema è stato affrontato da Kuhn nel 1997 [54]ed
il risultato della ricerca si è concretizzato nelle formulazione delle seguenti
proprietà:
Proprietà 1.
due ruoli possono essere mutuamente esclusivi solo se uno non
eredita l’altro (direttamente o indirettamente).
Proprietà 2.
se ci sono due ruoli mutuamente esclusivi, non ce ne può essere
un terzo che eredita da entrambi i relativi permessi.
Proprietà 3.
se è rispettata la SSD, allora lo è anche la DSD, in quanto se un
utente è autorizzato a ricoprire solo uno dei due ruoli non potrà mai averli
entrambi attivati contemporaneamente.
Proprietà 4.
se ci sono due ruoli mutuamente esclusivi, non può esistere
all’interno del sistema un ruolo “root” che eredita i permessi di tutti gli
altri ruoli.
Con l’introduzione della DSD i problemi aumentano, in quanto le proprietà
appena elencate non è detto che valgano ancora: dipende dalla modalità di
attivazione dei ruoli che è stata scelta.
Infatti se si decide di non attivare implicitamente anche i ruoli padre ogni volta
che viene attivato un ruolo figlio, le prime due proprietà e la quarta perdono di
veridicità.
Nel primo caso, se due ruoli mutuamente esclusivi si ereditano (direttamente o
indirettamente), uno dei due può essere tranquillamente attivato senza coinvolgere
Pagina 88
l’altro. Se successivamente l’utente dovesse cercare di attivare l’altro ruolo, i
vincoli DSD verrebbero controllati e, in base alla politica scelta, il primo verrebbe
disattivato per poter attivare il secondo.
Per quanto riguarda la seconda proprietà, se ci sono due ruoli mutuamente
esclusivi, ce ne può comunque essere un terzo che eredita da entrambi i permessi.
Infatti, quando quest’ultimo viene attivato, nessuno dei due ruoli mutuamente
esclusivi viene coinvolto e non si crea alcun conflitto. Non ci sono problemi
nemmeno se uno di questi due ruoli viene attivato in un secondo momento; se
infine si cerca di attivare anche il secondo, allora si dovrà procedere alla
disattivazione del primo per non violare il vincolo DSD.
Infine valgono considerazioni del tutto analoghe per la quarta proprietà. Infatti
può esistere ed essere attivato un ruolo “root”, se questo non comporta
l’attivazione automatica di tutti gli altri ruoli, fra i quali alcuni mutuamente
esclusivi.
La terza proprietà rimane invece sempre valida. È ovvia ma molto importante,
poiché mette in luce il fatto che la separazione statica dei compiti semplifica di
molto il funzionamento del sistema. Infatti il controllo dei vincoli deve essere
effettuato solo una volta all’avvio, in quanto durante l’esecuzione non accadrà mai
che un utente possa attivare ruoli mutuamente esclusivi, in quanto non gli sono
stati assegnati.
Tutte le proprietà rimangono invece valide qualora sia fatta la scelta opposta,
ovvero quella di attivare tutti i ruoli padri assieme al figlio. In questo caso i
vincoli DSD verrebbero violati e non sarebbe possibile portare a termine il
processo di attivazione. Per risolvere queste situazioni di conflitto è possibile fare
due scelte:
1. non supportare l’RBAC gerarchico e la DSD contemporaneamente.
2. effettuare un’attivazione selettiva dei ruoli padri, che non causano
violazioni dei vincoli DSD.
La seconda opzione può sembrare risolutiva, ma nasconde il fatto che bisogna
comunque definire una politica per selezionare quale ruolo padre si deve attivare
fra quelli che sono in conflitto. Il problema non è di facile soluzione e deve essere
affrontato per ogni caso specifico.
Pagina 89
Come ultima considerazione rimane da sottolineare il fatto che la violazione di
una delle proprietà appena discusse, anche nei casi in cui è possibile bypassarle,
può essere sintomo di una cattiva configurazione del sistema, a meno che non sia
stata prevista e studiata attentamente.
6.2.4
Gerarchia e permessi
Un tentativo per risolvere i problemi che insorgono con l’introduzione dell’RBAC
gerarchico è stato fatto nel 2003 da Crampton [85], il quale propone di alterare il
meccanismo di ereditarietà dei permessi.
Secondo questa architettura, quando un ruolo discende da un altro non è detto, che
possa ereditare tutti i permessi di quest’ultimo. I permessi vengono dotati di un
“verso” che definisce la loro “ereditabilità”. Infatti l’insieme dei permessi viene
suddiviso in tre classi disgiunte:
1. P+: permessi che si possono ereditare dal padre al figlio
2. P-: permessi che si possono ereditare dal figlio al padre
3. P0: permessi che non si possono ereditare
In questo modo è possibile definire gerarchie anche complesse, evitando di creare
conflitti con altri vincoli, in particolare quelli di separazione dei compiti.
Si noti inoltre il fatto che questo schema ingloba l’RBAC classico, che era
composto solamente dai permessi di tipo P+.
Un esempio renderà il tutto più chiaro. Prendiamo due permessi p1 e p2 ed
associamoli a due ruoli, rispettivamente r1 ed r2. Se i permessi sono di tipo P+
avremo la situazione classica dell’RBAC gerarchico, dove un ruolo r3 eredita tutti
i permessi dai padri r1 ed r2, dando luogo ad eventuali conflitti qualora r1 ed r2
fossero mutuamente esclusivi.
La figura seguente mostra la situazione appena illustrata.
Pagina 90
figli
• p1, p2 ∈ P+
• (p1, r1) ∈ PA
•
(p2, r2) ∈ PA
Albero rovesciato
padri
Figura 6-1. Interpretazione standard dei permessi RBAC
Se al contrario si definisce p1 come appartenente alla classe P-, allora sarà
possibile creare un ruolo r3 e farlo discendere sia da r1 che da r2, senza violare
alcun vincolo di separazione dei compiti, in quanto p2 non sarà attivabile da r3.
La figura seguente chiarisce il concetto appena espresso.
figli
• p1 ∈ P+
• (p1, r1) ∈ PA
• p2 ∈ P•
(p2, r2) ∈ PA
Albero rovesciato
padri
Figura 6-2. Modello dei permessi RBAC modificato
La classe cui appartiene un permesso può essere interpretata in due modi
differenti:
1. La classificazione dei permessi non è altro che un vincolo che altera la
gerarchia tra ruoli (e questo era già stato previsto dallo standard RBAC
proposto dal NIST).
Pagina 91
2. La classificazione dei permessi è una vincolo di attivazione posto
direttamente sui permessi assegnati ai differenti ruoli del modello.
Anche se ad una prima analisi la prima interpretazione può sembrare quella più
corretta, in realtà lo è la seconda, in quanto la gerarchia è fra ruoli e non fra
permessi, quindi non viene alterata. L’azione di questi nuovi vincoli è invece
direttamente sui permessi. Si discuterà comunque più avanti di questa tipologia di
vincoli in modo più approfondito.
Un’ultima considerazione riguarda invece le modifiche che dovrebbe subire il
modello per poter gestire le classi di permessi. Il problema riguarda i permessi di
classe P-, ovvero quelli attivabili nel senso inverso a quello delle normali relazioni
di ereditarietà. In questo caso un ruolo padre dovrebbe poter attivare un permesso
di un ruolo figlio, ma ciò non avviene mai secondo il processo di attivazione
dell’RBAC standard. Sarebbe dunque necessario modificare questo meccanismo,
in modo tale da ricercare i permessi a disposizione di un utente non solo tra i ruoli
assegnatigli esplicitamente ed i ruoli padri, ma anche tra i ruoli figli.
Ovviamente valgono anche in questo caso le stesse considerazioni fatte in
precedenza, per cui introdurre maggiore complessità nel modello comporta un
carico di lavoro maggiore per il sistema, che deve essere evitato, se non nei casi in
cui è strettamente necessario.
6.3 Separazione dei compiti e permessi
Anche in assenza di gerarchia uno stesso permesso può essere assegnato a più
ruoli e se questo permesso è determinante per la mutua esclusione di due ruoli,
possono nascere problemi dovuti alla violazione dei vincoli di separazione dei
compiti.
Nel 1997 Kuhn [54] ha fornito un classificazione delle diverse modalità con cui i
privilegi possono essere condivisi tra i ruoli mutuamente esclusivi e tutti gli altri
ruoli:
1. D/D (disjoint / disjoint): un permesso assegnato ad un ruolo coinvolto in
un vincolo di mutua esclusione non può essere assegnato né all’altro ruolo
mutuamente esclusivo, né a nessun altro ruolo.
Pagina 92
2. D/S (disjoint / shared): un permesso assegnato ad un ruolo coinvolto in un
vincolo di mutua esclusione non può essere assegnato all’altro ruolo
mutuamente esclusivo, ma può essere assegnato ad un altro ruolo non
coinvolto nel vincolo di mutua esclusione.
3. S/D (shared / disjoint): un permesso assegnato ad un ruolo coinvolto in un
vincolo di mutua esclusione può essere assegnato all’altro ruolo
mutuamente esclusivo (ci deve essere ovviamente almeno un permesso
differente tra i due ruoli!), ma non può essere assegnato ad alcun altro
ruolo non coinvolto nel vincolo di mutua esclusione.
4. S/S (shared / shared): un permesso assegnato ad un ruolo coinvolto in un
vincolo di mutua esclusione può essere assegnato sia all’altro ruolo
mutuamente esclusivo, sia a qualsiasi altro ruolo.
La condizione di sicurezza che deve essere verificata consiste ovviamente
nell’impedire ad uno stesso utente di vedersi assegnare dei privilegi che creano un
conflitto di interesse e che quindi fanno da discriminante per l’individuazione di
ruoli mutuamente esclusivi.
Lo studio si concentra sulla prima e sulla quarta configurazione, che vengono
definite rispettivamente esclusione completa (complete esclusion) ed esclusione
parziale (partila exclusion). L’analisi effettuata da Kuhn ha prodotto i seguenti
due importantissimi risultati:
1. l’esclusione completa è una condizione necessaria e sufficiente per il rispetto
della condizione di sicurezza.
2. l’esclusione parziale è una condizione necessaria ma non sufficiente per
garantire la condizione di sicurezza.
6.4 I permessi in un sistema ad oggetti
Fino ad ora si sono analizzate alcune problematiche relative alla corretta
configurazione dei permessi in un sistema di controllo d’accesso basato su ruoli.
Non si è però ancora posto il problema relativo alle entità che i privilegi d’accesso
vogliono proteggere. Si è detto che un permesso non è altro che un’operazione che
si può eseguire su un oggetto del sistema, ma è necessario definire con precisione
cosa si intende per quest’ultimo.
Pagina 93
Per rispondere a questa domanda bisogna prima di tutto definire il contesto in cui
deve funzionare il meccanismo di controllo d’accesso che si desidera
implementare. In un sistema in cui gli oggetti sono tutti statici il problema non si
pone, basta associare ad ognuno di essi un identificativo ed il gioco è fatto. In un
sistema ad oggetti, invece bisogna distinguere tra classi ed istanze. Ovviamente vi
possono essere tre alternative:
1. Si gestiscono permessi relativi solamente alle classi: in questo caso tutte le
istanze di oggetti appartenenti alla stessa classe godranno degli stessi
permessi e l’identificativo sarà il nome della classe.
2. Si dettagliano i permessi a livello delle singole istanze: in questo caso sarà
necessario dare un identificativo ad ognuna di queste ultime.
3. Si sceglie una soluzione ibrida, in cui si possono gestire permessi sia
riferiti alle singole istanze, che alle classi di oggetti. Vi possono essere due
sottocasi:
a. Gli identificativi sono misti ed il sistema non si preoccupa se sono
riferiti ad un’istanza o a una classe.
b. Si crea una sorta di gerarchia a due livelli di permessi, per cui
alcuni permessi sono a livello di classe ed altri a livello di istanza.
La prima soluzione è senza dubbio la più semplice, ma anche la meno flessibile.
La seconda alternativa è tuttavia troppo specializzata e richiederebbe uno sforzo di
configurazione notevole, se non addirittura insostenibile. Infatti per definire
semplicemente un permesso di classe, come nel caso precedente, ora sarebbe
necessario specificarlo per ogni singola istanza di oggetti facenti parte della stessa
classe. Ciò ovviamente non è accettabile, quindi si deve necessariamente ricorrere
alla terza soluzione, scegliendo una delle due proposte. La prima è più facilmente
gestibile, in quanto il controllo RBAC viene effettuato basandosi semplicemente
su un nome identificativo, senza preoccuparsi che si tratti di classe o istanza. Il
secondo invece è più articolato, ma anche più flessibile.
Pagina 94
6.5 Aggiunta e rimozione di elementi
del modello
Ulteriori problemi insorgono allorquando si eliminano elementi (entità e relazioni)
dal sistema di controllo RBAC. Se ciò avviene a sistema non in funzione,
ovviamente non vi sono particolare ripercussioni, ma ciò accade molto raramente.
Nella maggior parte dei casi questi cambiamenti avvengono con il sistema attivo
e con utenti che vi stanno lavorando.
I casi principali da analizzare sono i seguenti:
1. Eliminazione di un utente
2. Eliminazione di un ruolo
3. Eliminazione di un permesso
4. Eliminazione dell’appartenenza di un utente ad un ruolo
5. Eliminazione di un relazione gerarchica
6. Eliminazione dell’assegnazione di un permesso ad un ruolo
Quando si elimina un utente si deve decidere se annullare o meno le sessioni
attive di quest’ultimo. La scelta ovviamente deve essere fatta in base al contesto
applicativo e alle implicazioni di sicurezza che essa comporta. Come linea
generale l’alternativa migliore da questo punto di vista è sicuramente la
terminazione immediata di tutte le sessioni attive dell’utente cancellato.
Un discorso analogo vale per le altre eliminazioni elencate. Nel caso
dell’eliminazione di un ruolo o di una relazione di appartenenza di uno o più
utenti ad un ruolo la scelta riguarda sempre la disattivazione di quest’ultimo in
tutte le sessioni in cui esso sia attivo. Se invece ad essere cancellati sono un
permesso o l’assegnazione di quest’ultimo ad uno o più ruoli, è necessario
stabilire se questo va immediatamente eliminato anche dai ruoli attivi oppure no.
Infine per quanto riguarda l’eliminazione di una relazione gerarchica è necessario
decidere se disattivare o meno i ruoli attivati sfruttando l’ereditarietà.
Come sempre la soluzione migliore dal punto di vista della sicurezza è la
disattivazione immediata dei ruoli e dei permessi eliminati o dei quali si è
revocata l’autorizzazione.
Pagina 95
6.6 I vincoli
Uno tra i problemi più articolati, che si devono affrontare nella progettazione di
un sistema RBAC, è la definizione dei vincoli che si desidera supportare.
I vincoli previsti dallo standard RBAC proposto dal NIST sono sostanzialmente di
due tipi: vincoli di separazione dei compiti e vincoli gerarchici. I primi sono sia
statici che dinamici, mentre i secondi solamente statici.
In generale, anche se queste tipologie di vincoli sono indubbiamente essenziali per
effettuare un buon controllo d’accesso, molte applicazioni richiedono di effettuare
anche altre verifiche per garantire o meno l’accesso alle risorse del sistema. Ad
esempio si possono introdurre dei controlli basati sull’istante temporale in cui un
permesso viene richiesto, oppure si possono autorizzare solamente le transazioni
“ben formate” secondo un modello definito a priori, che tipicamente stabilisce chi
può fare che cosa su un oggetto di sistema e l’ordine secondo cui le diverse
operazioni possono essere effettuate.
A dimostrazione di quanto detto, si portano come esempio un modello di RBAC
che espande quello originale aggiungendovi un serie di vincoli temporali, il
GTRABC (Generalized Temporal RBAC), ed un diverso tipo di vincoli di
separazioni dei compiti, non più statici o dinamici, ma storici.
6.6.1
GTRBAC (Generalized Temporal RBAC)
Nel 2001 Bertino, Monatti e Ferrari [73] proposero un nuovo modello di controllo
d’accesso basato su ruoli dotato di alcune interessanti caratteristiche aggiuntive
relative a vincoli temporali: il TRBAC (Temporal RBAC). Questo modello venne
poi ripreso e modificato nel 2002 da Bertino, Latif, e Ghafoor, che diedero vita al
GTRBAC (Generalized Temporal RBAC)[87].
I vincoli temporali sono richiesti in applicazioni che richiedono il monitoraggio di
operazioni “time-sensitive”, come ad esempio i sistemi di “workflow
management” WFMSs (WorkFlow Mnagement Systems). Questo però non è
l’unico ambito in cui essi possono risultare utili. Infatti ad esempio in alcune
applicazioni bancarie può essere necessario vietare ad un certo utente di assumere
i privilegi appartenenti un determinato ruolo al di fuori dell’orario lavorativo.
Pagina 96
Una descrizione dettagliata del modello esula dagli scopi della presente tesi,
tuttavia è utile dare un’idea di quanti e quali vincoli siano stati introdotti rispetto
allo standard RBAC originale. A questo scopo è importante ricordare la
distinzione tra i concetti di abilitazione ed attivazione di un ruolo:
a) Secondo il modello GTRBAC un utente è abilitato ad un ruolo, se ha la
possibilità di attivarlo: non è dunque sufficiente aver assegnato un ruolo
per attivarlo, ma bisogna anche esserne abilitati.
b) Un ruolo è invece attivo se è stato utilizzato da almeno un utente
all’interno di una sua sessione.
I vincoli che è possibile specificare in un sistema di controllo d’accesso GTRBAC
sono i seguenti:
1. vincoli temporali sull’abilitazione e la disabilitazione dei ruoli:
specificano l’inizio e la fine dell’intervallo temporale all’interno del quale
un ruolo è abilitato per un utente, oppure la durata dello stesso.
2. vincoli temporali sugli assegnamenti utente-ruolo e permesso-ruolo:
specificano gli estremi dell’intervallo durante il quale un utente o un
permesso sono assegnati ad un ruolo, oppure la durata dello stesso.
3. vincoli di attivazione: specificano la durata dell’attivazione di un ruolo da
parte di un utente, ma anche gli intervalli temporali in cui essa è
consentita.
Sono infine presenti le seguenti caratteristiche aggiuntive:
4. eventi run-time: è possibile definire degli eventi di sistema GTRBAC,
che rendono operativi i vincoli di durata e di attivazione
5. espressioni di attivazione dei vincoli: si possono utilizzare delle
espressioni, che permettono di attivare i vincoli precedentemente definiti
6. triggers: permettono di esprimere relazioni di dipendenza tra eventi
GTRBAC
6.6.2
La separazione dei compiti storica
Un altro esempio di vincoli che non sono inclusi nello standard RBAC del NIST
sono quelli relativi alla separazione dei compiti storica. Quest’ultima si
Pagina 97
differenzia dalla separazione dei compiti statica e dinamica poiché tiene traccia
degli eventi passati del sistema.
Un esempio renderà più chiaro il concetto:
•
Separazione dei compiti statica: “nessun utente può avere la possibilità
di accedere sia al file1 che al file2”.
•
Separazione dei compiti dinamica: “nessun utente può avere accesso
contemporaneamente al file1 e al file2”.
•
Separazione dei compiti storica: “nessun utente può avere avuto
l’accesso sia al file1 che al file2”.
Secondo la separazione dei compiti storica un utente può dunque accedere al file1
se e solo se non ha mai avuto accesso al file2 e viceversa.
Si comprende dunque come la separazione dei compiti storica sia un vincolo più
restrittivo di quella dinamica, in quanto tiene anche traccia degli accesi passati
dell’utente, ma meno restrittivo di quella statica, poiché un utente può comunque
scegliere al primo accesso quale file utilizzare.
6.6.3
Tassonomia dei vincoli
Essendo impossibile presentare tutte le varianti dei modelli RBAC oggi presenti,
si è cercato di definire una tassonomia di tutti i vincoli, o quantomeno della
maggior parte dei vincoli, che un sistema di controllo d’accesso basato su ruoli
può supportare.
I vincoli vengono classificati nelle seguenti categorie:
1. vincoli di separazione dei compiti
2. vincoli di cardinalità
3. vincoli temporali
4. vincoli transazionali/operazionali
5. vincoli di prerequisito
Le prima categoria, ovvero la separazione dei compiti, non necessita di
particolari spiegazioni, in quanto è già stata ampiamente discussa nei capitoli
precedenti.
I vincoli di cardinalità invece pongono dei limiti sul numero massimo e minimo
di certe entità e relazioni del modello. Ad esempio si può imporre che il numero
Pagina 98
massimo di ruoli assegnati ad un utente sia maggiore di uno e minore di otto,
oppure si può voler impedire ad un utente di creare più di nove sessioni, e cos’
via.
I vincoli temporali intervengono sulle entità e le relazioni del modello ponendo
dei limiti temporali di durata o di intervallo. Sono i vincoli di cui si è diffusamente
parlato nel paragrafo precedente.
I vincoli transazionali (o operazionali) permettono di autorizzare certe operazioni
su un oggetto del sistema solamente se esse rispettano una certa sequenza definita
a priori. Una transazione viene intesa come una sequenza di operazioni compiute
su di un oggetto e, se questa sequenza rispetta certi vincoli, allora viene definita
“transazione ben formata”. Ad esempio si può imporre che su un oggetto di tipo
transazione bancaria la richiesta di pagamento sia eseguita da un utente dotato del
ruolo di impiegato e che essa sia successivamente autorizzata da un diverso utente
con il ruolo di direttore.
I vincoli di prerequisito sono infine dei vincoli che impongono di possedere già
una determinata caratteristica per potersene vedere assegnata un’altra. Ad esempio
si può vietare di assegnare ad un utente il ruolo di manager se non possiede già
quello di semplice impiegato. Allo stesso modo si può imporre che un utente non
possa attivare il ruolo di direttore se non ha già attivato quello di cassiere. Esempi
simili possono essere fatti sull’assegnazione dei permessi ai ruoli.
Ognuna delle categorie di vincoli appena descritte può essere ulteriormente
classificata secondo due dimensioni:
1. dimensione temporale del vincolo
2. target del vincolo
La dimensione temporale del vincolo sta ad indicare quanto la validità di un
vincolo perdura nel tempo e ciò si riflette sul momento in cui quest’ultimo deve
essere verificato. Vi sono tre tipologie possibili:
1. vincoli statici
2. vincoli dinamici
3. vincoli storici
Pagina 99
I vincoli statici devono essere sempre verificati, anche quando il sistema non è in
funzione. I vincoli dinamici devono essere verificati dal sistema durante il suo
funzionamento. I vincoli storici vengono verificati anch’essi durante il
funzionamento del sistema, ma tengono conto anche delle operazioni eseguite nel
passato. Ne sono un perfetto esempio i vincoli di separazioni dei compiti statici,
dinamici e storici, dei quali si è discusso in precedenza.
Va sottolineato il fatto che non tutte le categorie di vincoli precedentemente
illustrate possono essere sia statiche, che dinamiche e storiche. I vincoli temporali
possono essere solo dinamici o storici, mentre i vincoli transazionali sono per loro
natura solamente storici.
La tabella seguente riporta le dimensioni temporali di ogni singola categoria di
vincoli.
Dimensione temporale
Statico
Dinamico
Storico
3
3
3
Cardinalità
3
3
3
Temporali
X
3
3
X
X
3
3
3
3
Separazione dei
Categoria
compiti
Transazionali /
Operazionali
Prerequisito
Tabella 6-1. Categorie di vincoli e dimensione temporale
Il target del vincolo rappresenta invece l’oggetto, il bersaglio, delle limitazioni
che esso impone. In particolare per un sistema RBAC si possono individuare i
seguenti possibili target:
1) relazioni del modello, ovvero:
a. UA
b. PA
c. RH
d. User_session
Pagina 100
e. Session_roles
2) entità del modello, ovvero:
a. utenti
b. ruoli
c. oggetti
d. operazioni
e. permessi
f. sessioni
3) altri vincoli
Va sottolineato il fatto che i vincoli sulle relazioni e sulle entità del modello
possono inserirsi sia nella fase di attivazione o creazione, che in quella di
disattivazione o eliminazione delle stesse. Inoltre Per quanto riguarda le entità del
modello, va ricordato che è possibile specificare vincoli che abbracciano ad
esempio tutti gli utenti oppure solo uno specifico utente. Varia dunque quella che
viene definita la granularità del target.
Infine un’ultima considerazione va fatta in merito ai vincoli che hanno come
target altri vincoli. Ci si trova ad esempio nel caso in cui si vuole attivare un
vincolo di separazione dei compiti dinamica su due ruoli solamente in un certo
intervallo temporale. Si tratta dunque di un vincolo temporale che ha come target
un vincolo di separazione dei compiti. Ovviamente queste tipologie di vincoli
sono piuttosto complesse da supportare e le applicazioni in cui esse sono
realmente indispensabili non sono numerose.
6.6.4
I vincoli in un sistema ad oggetti
Nella classificazione appena fornita sono stati indicati come possibili target di un
vincolo gli oggetti del sistema. Va dunque sottolineato il fatto che, così come per
i permessi, il target di un vincolo può essere sia un’intera classe di oggetti, che
una singola istanza. Le alternative tra cui scegliere sono le medesime di quelle
presentate in relazione ai permessi, ovvero si possono avere:
1. vincoli solo a livello di classe
2. vincoli solo a livello di istanza
3. vincoli ibridi
Pagina 101
Si rimanda al paragrafo 6.4 per la spiegazione dettagliata delle tre varianti. È
invece utile sottolineare a questo punto il fatto che, poiché ogni oggetto del
sistema deve avere un nome univoco, è necessario effettuare lo stesso tipo di
scelta sia per i permessi che per i vincoli. Questi infatti faranno riferimento allo
stesso insieme di etichette, che rappresenteranno le istanze o le classi degli oggetti
a seconda dell’alternativa messa in atto.
6.7 Il formato dei vincoli
Dopo aver determinato l’insieme dei vincoli che si vogliono supportare è
necessario
stabilire
anche
come
essi
possono
essere
specificati
dall’amministratore di sistema.
Lo standard RBAC del NIST non si preoccupa di definire il formato dei vincoli,
probabilmente perché viene considerato un aspetto maggiormente legato
all’implementazione del modello e non al modello stesso. Per quanto questa
logica di pensiero possa essere condivisibile, risulta utile a questo punto fornire un
breve resoconto circa lo stato dell’arte della standardizzazione dei formati dei
vincoli in un sistema di controllo d’accesso basato su ruoli.
Va subito detto che ad oggi non esiste ancora uno standard universalmente
riconosciuto, che definisca il formato di tutti i possibili vincoli di un sistema
RBAC. Tuttavia alcuni tentativi più o meno autorevoli sono stati fatti in questa
direzione negli ultimi anni ed hanno prodotto risultati interessanti. La maggior
parte di essi utilizza il formato XML per la specifica dei vincoli. La motivazione
principale di questa scelta va ricercata nel fatto che gli ambienti di tipo enterprise
altamente distribuiti sono composti da entità eterogenee, che devono collaborare
tra loro e scambiarsi dati in un formato universalmente comprensibile. Il formato
XML, essendo indipendente dal fornitore, fornisce una rappresentazione uniforme
dei dati e semplifica dunque la loro condivisione tra sistemi eterogenei.
Una scelta di questo tipo è stata fatta ad esempio per la definizione dell’XGTRBAC (XML-based GTRBAC) [88], uno standard proposto nel 2003 da
Bhatti, Bertino e Ghafoor per la rappresentazione dei vincoli temporali del
controllo d’accesso di tipo GTRBAC, del quale si è parlato in precedenza.
Pagina 102
Un altro importante standard, che definisce il formato dei vincoli di un sistema di
controllo d’accesso è l’XACML (eXtensible Access Control Markup Language),
al quale è dedicato il prossimo paragrafo.
6.7.1
XACML 2.0 (eXtensible Access Control
Markup Language)
L’XACML [90] è un linguaggio basato sullo standard XML, che è stato a sua
volta standardizzato dall’OASIS (Organization for the Advancement of Structured
Information Standards). La sua breve storia inizia nel 2003, anno in cui viene
definita la sua prima versione dalla 1.0 alla 1.2. Lo standard ha un buon successo
ed è implementato da diverse software-house, tra le quale ricordiamo le seguenti:
•
Parthenon Computing (ex. Jiffy Software): Parthenon XACML Evaluation
Engine
•
Sun Microsystems: Sun's XACML Open Source Implementation
•
Lagash Systems: XACML.NET
•
University of Murcia (UMU), Spain: Java-based XACML editor
Lo standard evolve e nel febbraio 2005 viene definita la versione 2.0, del la quale
non si conosce al momento alcuna implementazione di una certa rilevanza.
L’XACML descrive i formati sia del linguaggio per definire le politiche di
sicurezza (“policy language”), che del linguaggio per scrivere le interrogazioni da
porre al sistema di controllo d’accesso ed ottenerne le risposte (“request/response
language”). In un tipico scenario d’uso un soggetto vuole effettuare una certa
operazione su una risorsa del sistema ed invia a quest’ultimo la una query
opportunamente strutturata (tramite il request language). Il sistema, a seconda di
come è stato configurato (tramite il policy language), prende le decisioni in merito
alla richiesta dell’utente ed elabora la risposta (tramite il response language) che
passa a quest’ultimo.
I formati dei vincoli esprimibili mediante l’XACML sono piuttosto articolati,
perciò si rimanda al documento ufficiale se si desidera averne una descrizione
precisa e completa. Si vuole semplicemente sottolineare il fatto che lo standard è
ancora lontano dall’assumere una connotazione stabile, tanto che si sta già
lavorando alla terza versione, di conseguenza può non essere così vantaggioso
Pagina 103
adottarlo, anche perché la sua complessità comporta tempi di sviluppo ed
implementazione elevati.
6.7.2
La mutua esclusione
Una nota particolare va fatta a proposito del formato dei vincoli di mutua
esclusione, che permettono di supportare il principio della separazione dei
compiti.
Anche se fino ad ora è stato illustrato e portato ad esempio il solo modello RBAC
proposto dal NIST, vi sono diversi modi per esprimere i vincoli di mutua
esclusione. Infatti, a seconda di come viene interpretato il principio del minimo
privilegio, in modo più o meno stringente e rigoroso, possono esistere diverse
varianti nelle modalità di specifica dei relativi vincoli.
Se il sistema vuole fornire la possibilità di esprimere la mutua esclusione tra un
ruolo ed uno o più altri ruoli, possono essere individuati due differenti formati:
1. mutua esclusione specificata tramite insieme di ruoli: permette di elencare
in un’unica istruzione un insieme di ruoli, dei quali uno soltanto può
essere assegnato ad un singolo utente (o attivato dallo stesso se si tratta di
separazione dei compiti dinamica).
2. mutua esclusione specificata tramite coppie di ruoli: permette di
specificare una coppia di ruoli mutuamente esclusivi, ovvero che non
possono essere assegnati o attivati contemporaneamente da uno stesso
utente.
Ad una prima e superficiale analisi si potrebbe pensare che i due diversi formati
abbiano anche una differente espressività, ovvero che la specifica tramite coppie
di ruoli non possa essere utilizzata per rappresentare tutti i vincoli, che possono
essere definiti utilizzando l’altro formato. In realtà è possibile emulare i vincoli
espressi tramite insiemi di ruoli, rendendo mutuamente esclusive tutte le possibili
coppie di ruoli dell’insieme stesso.
Per chiarire meglio il concetto vengono riportate nella seguente figura tutte le
relazioni di mutua esclusione che devono essere definite su un insieme di cinque
ruoli.
Pagina 104
Figura 6-3. Esempio di mutua esclusione tra cinque diversi ruoli
In generale, per definire la mutua esclusione su un insieme di n ruoli è necessario
definire (n*(n – 1))/2 coppie di mutua esclusione.
La scelta di una soluzione sull’altra è sicuramente influenzata dal numero di ruoli
che si prevede possano essere definiti come mutuamente esclusivi. Se questo
numero è limitato, allora avrà senso utilizzare la soluzione meno articolata delle
coppie di ruoli, che semplifica la verifica del vincolo da parte del sistema. Al
crescere di questo valore, sarà al contrario indicato l’utilizzo degli insiemi di ruoli
mutuamente esclusivi, che pur complicando il lavoro di verifica effettuato dal
sistema, semplificano notevolmente il processo di configurazione, che è invece a
carico dell’amministratore.
6.7.3
La Blacklist di Crampton
Un’ultima nota riguardo ai formati va spesa per i vincoli storici di separazione dei
compiti. Come tutti i vincoli storici non è sicuramente agevole verificarne il
rispetto, in quanto bisogna memorizzare in modo permanente gli eventi del
sistema che interessano ed in seguito andarli ad utilizzare in modo efficiente ogni
volta che è necessario.
Pagina 105
Nel 2003 J. Crampton [89] ha proposto di utilizzare delle blacklist come supporto
per i vincoli di separazione dei compiti storici. L’aspetto innovativo di questo
approccio è il fatto che non vengono memorizzati tutti gli stati passati del sistema,
ma in base agli eventi che si susseguono durante il suo funzionamento vengono
computate e salvate direttamente le informazioni circa gli eventi futuri che non
possono accadere. Questo sistema inoltre è applicabile anche ai vincoli di
separazione dei compiti statica e dinamica.
A seconda della relazione su cui si vuole imporre il vincolo si dovranno creare
differenti black list:
•
I vincoli sulle relazioni di assegnazione tra utenti e ruoli generano delle
liste di assegnazioni utente-ruolo proibite.
•
I vincoli sulle relazioni di assegnazione tra permessi e ruoli generano delle
liste di assegnazioni permesso-ruolo proibite.
•
I vincoli che fanno riferimento ad un utente o un ruolo specifico e alle sue
relazione di assegnazione con i permessi generano liste di permessi
proibiti.
Ogni volta che un utente cerca di attivare un ruolo o un permesso, il sistema,
prima di dare l’autorizzazione a procedere, verifica che questi ultimi non siano
presenti nelle opportune blacklist e al contempo aggiorna queste ultime qualora
fosse necessario.
Il procedimento appare più chiaro osservando l’esempio riportato nella figura
seguente, che è stato tratto da alcune slide rese disponibili dallo stesso Crampton:
Pagina 106
Figura 6-4. Esempio di utilizzo di blacklist
I vincoli sono espressi mediante la tripla <scope, set, temporal context>. Lo
“scope” indica se il vincolo si applica ad un utente o ad un ruolo in particolare,
oppure a tutti gli utenti o i ruoli. Il “set” è l’insieme dei ruoli o dei permessi
mutuamente esclusivi. Infine il “temporal context” sta ad indicare se il vincolo è
statico (“static”), dinamico (“dynamic”) o storico (“historical”).
All’inizio non vi è alcuna relazione UA (assegnazione utente-ruolo) e la lista delle
assegnazioni utente-ruolo proibite (LUA) contiene la coppia <jason, r1> poiché lo
impone il secondo vincolo statico. Quando viene assegnato all’utente mick il
ruolo r1, viene aggiornata la lista delle assegnazioni utente-ruolo proibite
inserendovi anche la coppia <mick, r2> a causa della presenza del primo vincolo
statico. Nel momento in cui mick usa il permesso p1, il vincolo storico impone la
creazione di una nuova blacklist relativa al solo mick (Lmick), contenente il
permesso p2. Infine, qualora mick venisse privato del ruolo r1, la lista delle
assegnazioni utente-ruolo proibite verrebbe aggiornata eliminando la coppia
<mick, r2>, mentre la blacklist di mick rimarrebbe inalterata, poiché ad essa è
applicato un vincolo storico.
Pagina 107
CAPITOLO 7
ESTENSIONE DEL
MODELLO: UNA
PROPOSTA
In questo capitolo viene descritto il modello
RBAC proposto, che verrà successivamente
implementato. L’architettura base da cui si è
partiti è ovviamente lo standard di controllo
d’accesso basato su ruoli definito dal NIST, che
è stato rivisto, anche se non stravolto,
apportandovi alcune modifiche laddove si
riteneva necessario. Lo scopo infatti non è
quello di creare un’alternativa allo standard
originale, ma di perfezionarlo sempre più, in
modo
da
creare
un
modello
veramente
universale, che possa adattarsi alle esigenze più
disparate.
Pagina 108
7.1 Premessa
Come si è dimostrato nel capitoli precedenti, sono stati sviluppati in questi ultimi
anni diversi modelli di RBAC per risolvere i più svariati problemi relativi al
controllo d’accesso. Fino ad oggi sono stati ampiamente studiati ed implementati
differenti sistemi, ognuno con caratteristiche specifiche per il contesto applicativo
di interesse e sono stati riconosciuti i loro vantaggi per la gestione e
l’amministrazione di sistemi specialmente su larga scala. Quello che in passato è
mancato è stata la caratterizzazione di un modello general purpose universalmente
riconosciuto per la gestione del controllo d’accesso basato su ruoli. La mancanza
di una definizione unica ed autorevole ha portato come risultato una certa
confusione circa il significato e l’utilità dell’RBAC.
Sicuramente gli sforzi compiuti dal NIST (National Institute of Standards and
Technology) in questi ultimi anni hanno dato una forte spinta in questa direzione,
ma la presenza di numerose varianti del modello originale dimostra che il
processo di standardizzazione non è affatto terminato.
In questo capitolo si vuole dunque fornire un’accurata descrizione di uno standard
RBAC general purpose, che prenda spunto dai modelli base più diffusi, sia per
quanto riguarda quelli già in uso in diversi prodotti commerciali, sia quelli più
stimati nell’ambito della ricerca, anche se ancora in fase prototipale.
Lo standard presentato nei paragrafi successivi prende vita dai documenti sul
controllo d’accesso basato su ruoli prodotti dal NIST, apportandovi, laddove si
ritengono necessarie, alcune modifiche, senza però stravolgerne l’essenza, in
modo da non produrre un’ulteriore meteora nella molteplicità dei modelli RBAC
già studiati ed implementati. Lo scopo infatti non è quello di creare un’alternativa
allo standard originale, ma di perfezionarlo sempre più, in modo da creare un
modello veramente universale, che possa adattarsi alle esigenze più disparate.
7.2 L’architettura
Per prima cosa è necessario definire l’architettura del modello, ovvero occorre
elencare e descrivere le entità che lo compongono e le relazioni che intercorrono
tra di esse.
Pagina 109
Come anticipato la base di partenza è il modello RBAC proposto dal NIST. Per
comodità di consultazione quest’ultimo viene riportato nella figura seguente.
Figura 7-1. Modello RBAC del NIST
Dopo un’attenta analisi appare evidente che il modello del NIST, apparentemente
semplice, chiaro e conciso, contenga in realtà una complessità intrinseca,
derivante dal voler catturare in un’unica architettura sia la sua parte statica, che
quella dinamica.
Le relazioni UA (assegnazione di un utente ad un ruolo), PA (assegnazione di un
permesso ad un ruolo) ed RH (relazioni gerarchiche fra ruoli) sono senza dubbio
statiche, ovvero non cambiano durante la vita del sistema. Viceversa le relazioni
user_sessions (relazioni tra un utente e le relative sessioni) e session_roles
(relazioni tra una sessione ed i ruoli da essa attivati) vanno a costituire la parte
dinamica dell’architettura.
Questa distinzione è applicabile non solo alle relazioni, ma anche alle entità del
modello. Infatti le sessioni (in figura: SESSIONS) non hanno alcun senso di
esistere nella parte statica e trovano la loro corretta collocazione soltanto in quella
dinamica. Tutte le altre entità invece possono essere inserite in entrambi gli
ambiti, ma ovviamente sono legate fra loro da relazioni differenti.
Pagina 110
È dunque necessario dividere l’architettura del modello in due parti, una statica ed
una dinamica, ognuna delle quali dotata di entità e relazioni specifiche. Il
principio da seguire in questo caso è il famoso “divide et impera”, infatti ogni
sotto-modello risulta più semplice di quello globale e quindi più facilmente
comprensibile e gestibile. Inoltre si potrà notare leggendo i prossimi paragrafi
come questa suddivisione metta in luce una lacuna dell’architettura originale, che
verrà dunque ristrutturata.
7.2.1
Parte statica
La figura seguente riporta l’architettura statica del modello, dove U rappresenta
l’insieme degli utenti, R quello dei ruoli e P quello dei permessi, che unifica
oggetti ed operazioni, mentre UA, PA ed RH sono rispettivamente le relazioni di
assegnazione di un utente ad un ruolo, di un permesso ad un ruolo e di gerarchia
fra ruoli.
RH
U
UA
R
PA
P
Figura 7-2. Architettura statica dello standard NIST
Come si sarà certamente notato la parte statica del modello è molto semplice ed è
ottenuta selezionando correttamente le opportune entità e relazioni dallo standard
RBAC del NIST. Per la descrizione dettagliata delle entità e delle relazioni in
gioco si rimanda dunque al relativo capitolo.
Il modello proposto non modifica dunque la parte statica dell’architettura
originale. Tuttavia è possibile apportare a quest’ultimo una piccola miglioria
esplicitando la relazione esistente tra utente e ruoli di default, che viene definita
staticamente, ma che viene poi utilizzata a livello dinamico ogni volta che un
utente crea una nuova sessione.
Pagina 111
La figura seguente introduce rispetto alla precedente la relazione “default_roles”,
che lega un utente ai suoi ruoli di default e dunque illustra l’architettura statica del
modello RBAC proposto.
RH
UA
U
R
PA
P
Default_roles
Figura 7-3. Architettura statica del modello proposto
7.2.2
Parte dinamica
Per quanto riguarda l’architettura dinamica del modello è utile osservare per prima
cosa come essa era strutturata nello standard proposto dal NIST, anche se come
detto in precedenza non viene espressa in modo esplicito.
La figura seguente mostra appunto l’architettura della parte statica del modello
RBAC originale, in cui U rappresenta l’insieme degli utenti, S quello delle
sessioni ed R quello dei ruoli, mentre user_sessions e session_roles sono
rispettivamente le relazioni tra un utente e le sue sessioni e quelle tra una sessione
ed i ruoli in essa attivi.
U
User_sessions
S
Session_roles
R
Figura 7-4. Architettura dinamica dello standard NIST
Osservando la figura e confrontandola con la precedente, ovvero quella relativa
alla parte statica del modello, si possono notare due principali differenze:
1. l’aggiunta dell’entità S (Sessioni)
2. la mancanza dell’entità P (Permessi)
Pagina 112
Per quanto riguarda le sessioni è ovvio il fatto che esse possano esistere soltanto a
livello dinamico, in quanto vengono create e distrutte dall’utente durante il
funzionamento del sistema. In realtà la loro presenza non sarebbe strettamente
necessaria, in quanto una sessione non è altro che una sorta di contenitore di ruoli
attivi, ma i vincoli di attivazione dei ruoli vanno verificati contemporaneamente
su tutte le sessioni create dallo stesso utente, quindi queste ultime si potrebbero
considerare di fatto come un’unica entità che rappresenta l’utente dal punto di
vista dinamico. Il concetto di sessione diventa invece utile quando il sistema di
controllo d’accesso basato su ruoli deve essere integrato in un altro sistema che ne
prevede l’uso. In questo caso risulta vantaggioso avere una corrispondenza uno a
uno tra le sessioni RBAC e quelle dell’ambiente in cui esso è inserito.
La mancanza dei permessi a livello dinamico è invece la lacuna del modello
RBAC originale di cui si parlava in precedenza. Il fatto di non inserire i permessi
nella parte dinamica dell’architettura pone un limite alle tipologie di vincoli che il
modello può supportare, alcune delle quali sono di notevole interesse per diverse
applicazioni.
Il modello dinamico proposto introduce dunque l’entità P (Permessi) e la
relazione “role_permission”, che lega un ruolo ai permessi da esso attivati
durante il funzionamento del sistema. Questo processo viene definito appunto
“attivazione dei permessi” per simmetria rispetto a quello di attivazione dei ruoli
e di esso si parlerà più approfonditamente nel prossimo paragrafo.
La figura seguente mostra il risultato della modifica architetturale appena
illustrata.
U
User_sessions
S
Session_roles
R
Role_permissions
P
Figura 7-5. Architettura dinamica del modello proposto
Infine la figura che segue mostra la variante del modello proposto descritta in
precedenza, secondo la quale le sessioni utente vengono riunite in un’unica entità,
Pagina 113
che raccoglie tutti i ruoli attivati dall’utente stesso durante il funzionamento del
sistema.
U/S
Session_roles
R
Role_permissions
P
Figura 7-6. Variante della parte dinamica del modello
Come si può vedere l’entità U/S, ovvero user/sessions, viene collegata
direttamente a quella dei ruoli (R) tramite la solita relazione session_roles, la cui
semantica rimane invariata.
Questa variante del modello mette in evidenza la corrispondenza diretta che c’è
tra le relazioni e le entità dell’architettura statica e di quella dinamica, come è
mostrato nella seguente tabella.
Architettura Statica
Architettura Dinamica
UA
Session_roles
PA
Role_permissions
U
U/S
R
R
P
P
Tabella 7-1. Corrispondenze tra architettura statica e dinamica
Le relazioni statiche di assegnazione di un utente e di un permesso ad un ruolo
trovano dunque i corrispettivi in ambito dinamico nei processi di attivazione dei
ruoli e dei permessi.
7.3 L’attivazione dei permessi
Come sottolineato nel paragrafo precedente, quello che manca allo standard
proposto dal NIST è l’attivazione dei permessi. Di tutte le entità che compongono
il modello (utenti, ruoli, permessi e sessioni) l’unica che può essere attivata è il
Pagina 114
ruolo, ma questa è una semplificazione eccessiva, che non permette di supportare
alcuni tipi di vincoli. È dunque necessario introdurre un meccanismo che dia la
possibilità di attivare singolarmente ogni permesso.
Lo standard del NIST permette di definire solamente vincoli statici sulla relazione
PA (assegnazione dei permessi), che possono impedire di assegnare un permesso
ad un ruolo. Quando però questo accade, ogni volta che un ruolo viene attivato, lo
sono di conseguenza anche i relativi permessi, in quanto non è possibile introdurre
vincoli aggiuntivi su questi ultimi. Si può inoltre affermare che a livello dinamico
i permessi vengono utilizzati come dei semplici indici per ricercare il relativo
permesso da attivare. Infatti quando un utente chiede al sistema RBAC di
compiere una certa operazione su un oggetto, quello che accade può essere
riassunto nei seguenti passi:
1. L’utente passa al sistema il suo nome, l’identificativo della sessione, il
nome dell’oggetto e quello dell’operazione.
2. Per prima cosa il sistema verifica che la sessione appartenga all’utente.
3. Dal nome dell’oggetto e dell’operazione viene ricavato il relativo
permesso.
4. Si ricercano tra i ruoli assegnati all’utente, quelli dotati del permesso
richiesto.
5. Se almeno uno dei ruoli individuati è già attivo l’operazione viene
autorizzata.
6. In caso contrario si procede all’attivazione dei ruoli individuati,
controllando i relativi vincoli e fermandosi non appena se ne riesce ad
attivare uno.
7. La procedura di autorizzazione può terminare con esito positivo solo dopo
aver superato con successo tutte le fasi appena elencate, in caso contrario
fallisce e l’utente non può compiere l’operazione desiderata sull’oggetto
indicato.
Appare ora evidente come i permessi vengano utilizzati solamente al passo
quattro per ricercare il ruolo da attivare e non vengano più coinvolti nel processo
di autorizzazione.
Pagina 115
I vincoli che possono essere definiti hanno dunque una limitata espressività,
poiché nel processo di attivazione vengono persi, assieme al riferimento al
permesso, anche quelli relativi all’oggetto e all’operazione richiesta. Facendo
riferimento alla tassonomia dei vincoli presentata nel capitolo precedente, si può
quindi affermare che non è possibile definire alcun vincolo dinamico o storico,
che non riguardi i ruoli, gli utenti o le sessioni del sistema di controllo d’accesso.
Si prenda ad esempio un vincolo temporale: con l’architettura dello standard
RBAC proposto dal NIST sarebbe possibile, anche se non è espressamente
previsto, definire un vincolo che impedisce ad un ruolo di essere attivato fuori
dall’orario d’ufficio e verificarlo al momento della sua attivazione. Non accade
però lo stesso se si vuole applicare il vincolo ad un singolo permesso legato ad un
ruolo. Il problema diventa ancor più evidente se ad ogni permesso associato allo
stesso ruolo devono essere associati vincoli temporali differenti.
A questo punto si potrebbe obiettare che è sufficiente assegnare ad un ruolo un
singolo permesso ed utilizzare i vincoli sul primo come se fossero sul secondo.
Questo è sicuramente vero, ma avere una corrispondenza uno a uno tra ruoli e
permessi sarebbe altamente controproducente per l’amministrazione del sistema e
annullerebbe tutti i vantaggi, che hanno reso l’RBAC uno dei modelli di controllo
d’accesso più apprezzati di questi ultimi anni.
Per porre rimedio a questa situazione è dunque necessario affiancare
all’attivazione dei ruoli, anche quella dei permessi. Il processo di attivazione dei
permessi dovrà sempre seguire quello di attivazione dei ruoli e, con riferimento
all’elenco di passi esecutivi precedentemente illustrato, si inserisce sia dopo il
punto cinque, che dopo il punto sei. Ovviamente l’attivazione di un permesso
andrà a buon fine se tutti i relativi vincoli saranno rispettati, altrimenti il sistema,
pur avendo attivato il ruolo, non consentirà all’utente di usufruire del permesso
richiesto.
Rimane infine da fare un’ultima considerazione riguardo all’attivazione dei
permessi, ovvero è necessario scegliere tra le seguenti due opzioni:
1. un permesso, una volta attivato, rimane tale
2. il processo di attivazione di un permesso viene ripetuto ogni volta che
quest’ultimo è richiesto dall’utente
Pagina 116
Senza dubbio la seconda alternativa è la migliore, principalmente perché si adatta
in modo più stringente al principio del minimo privilegio, in quanto un utente si
vede assegnati i privilegi necessari per compiere il suo lavoro solo nel preciso
istante in cui ne deve usufruire. Inoltre non bisogna dimenticare che, se i permessi
dovessero rimanere attivi per un tempo indefinito, non sarebbe possibile
supportare correttamente alcune tipologie di vincoli temporali.
7.4 Le scelte di definizione del modello
Nel capitolo sei è stata effettuata un’analisi critica dello standard RBAC proposto
dal NIST e si sono messi in luce numerosi punti dello stesso, cha lasciavano
spazio a diverse interpretazioni. Nel modello proposto son state fatte dunque delle
scelte in relazione ad ognuno di questi aspetti, che vengono ora elencate nella
seguente lista, mantenendo l’ordine di presentazione del capitolo precedente.
1) Attivazione e disattivazione dei ruoli
SCELTA: attivazione di un ruolo di default alla volta e disattivazione di
un ruolo solamente all’occorrenza.
2) Le gerarchie
a. Gerarchia ed attivazione dei ruoli
SCELTA: attivazione esplicita dei ruoli padri.
b. Gerarchia e disattivazione dei ruoli
SCELTA: disattivazione esplicita dei ruoli padri.
c. Gerarchia e separazione dei compiti
SCELTA: nessun problema perché si usa l’attivazione esplicita dei
ruoli padri.
d. Gerarchia e permessi
SCELTA: permessi standard (è sempre possibile, se lo si desidera,
introdurre come vincoli di attivazione dei permessi quantomeno le
classi P+ e P0).
3) Separazione dei compiti e permessi
SCELTA: shared/shared, il rispetto della condizione di sicurezza viene
lasciato come competenza dell’amministratore di sistema (è comunque
possibile introdurre se lo si desidera vincoli statici sull’assegnazione dei
Pagina 117
permessi che verifichino che un permesso assegnato ad un ruolo coinvolto
in un vincolo di mutua esclusione non sia assegnato a nessun altro ruolo,
riportandosi così alla situazione disjoint/disjoint).
4) I permessi in un sistema ad oggetti
SCELTA: 3.a (soluzione ibrida), il sistema agisce in base al nome
dell’oggetto che gli viene passato dall’utente, senza preoccuparsi che sia
riferito ad una classe o ad un’istanza
5) Eliminazione degli elementi del modello
a. Eliminazione di un utente
b. Eliminazione di un ruolo
c. Eliminazione di un permesso
d. Eliminazione dell’appartenenza di un utente ad un ruolo
e. Eliminazione di un relazione gerarchica
f. Eliminazione dell’assegnazione di un permesso ad un ruolo
SCELTA: le sessioni in corrispondenza di tutte le eliminazioni sopra
elencate non vengono distrutte, in quanto ogni volta che un utente
richiede un permesso al sistema viene controllata l’esistenza di tutte le
entità e le relazioni che possono essere state cancellate, di
conseguenza l’accesso verrà correttamente negato qualora fosse
necessario.
6) I vincoli
a. Vincoli supportati
SCELTA: è obbligatorio supportare i vincoli di cardinalità sulle
relazioni gerarchiche (o vincoli gerarchici) e quelli di separazione dei
compiti sia statici che dinamici; i vincoli di cardinalità, temporali,
transazionale e di prerequisito sono invece opzionali.
b. Il formato dei vincoli
SCELTA: non essendoci ancora uno standard universalmente
riconosciuto, il formato dei vincoli non viene imposto dal modello, ma
può variare da implementazione ad implementazione.
Pagina 118
7.5 Il framework
Come è stato fatto per lo standard RBAC proposto dal NIST, subito dopo aver
definito il modello concettuale, si vuole fornire un’indicazione su come
organizzare le diverse funzionalità dello stesso, in modo da garantirne una corretta
implementazione.
I paragrafi seguenti descrivono le funzioni e i packages che si consiglia di
implementare.
7.5.1
Le funzioni
Le funzioni che devono essere supportate sono suddivise nelle seguenti tre
categorie:
1. funzioni di sistema
2. funzioni amministrative
3. funzioni di reportistica
La semantica di questa classificazione è la medesima rispetto a quella definita nel
capitolo dello standard RBAC proposto dal NIST, al quale si rimanda.
Le funzioni di sistema permettono di verificare i vincoli dinamici e statici del
modello. Esse sono:
•
Create session: crea una nuova sessione utente ed prova ad attivare i ruoli
di default
•
Delete session: disattiva i ruoli della sessione e la elimina
•
Add active role: attiva un ruolo per una sessione utente se sono verificati i
relativi vincoli
•
Drop active role: disattiva un ruolo di una sessione utente
•
Check access: controlla la disponibilità di un permesso per un certo utente
e cerca di attivare un ruolo a cui il permesso è associato
•
Activate permission: attiva un permesso per un ruolo se sono verificati i
relativi vincoli
•
Check integrity: controlla gli eventuali vincoli statici del modello
Pagina 119
Da notare è il fatto che mentre per il processo di attivazione dei ruoli sono previsti
due metodi, uno per l’attivazione (add active role) ed uno per la disattivazione
(drop active role), per i permessi è invece definito un solo metodo (activate
permission). Ciò è giustificato dal fatto che i ruoli rimangono attivi per un tempo
indefinito, quindi è necessario disattivarlo esplicitamente, mentre per i permessi è
stata fatta una scelta progettuale differente, secondo la quale questi ultimi non
rimangono attivi dopo che l’utente ne ha potuto usufruire.
Le funzioni amministrative consentono invece di creare, eliminare e modificare
le entità e le relazioni del modello di controllo d’accesso. Esse sono:
•
Add user: aggiunta di un nuovo utente
•
Delete user: eliminazione di un utente
•
Add role: aggiunta di un nuovo ruolo
•
Delete role: eliminazione di un ruolo
•
Assign user: assegnazione di un utente ad un ruolo
•
Deassign user: revoca di un ruolo ad un utente
•
Grant permission: assegnazione di un permesso ad un ruolo
•
Revoke permission: revoca di un permesso ad un ruolo
•
Add inheritance: aggiunta di un ruolo figlio ad un ruolo padre
•
Delete inheritance: eliminazione di un ruolo figlio da un ruolo padre
•
Create SSD set: creazione di un vincolo SSD
•
Delete SSD set: eliminazione di un vincolo SSD
•
Create DSD set: creazione di un vincolo DSD
•
Delete DSD set: eliminazione di un vincolo DSD
Infine le funzioni di reportistica forniscono tutti i servizi necessari per leggere i
dati relativi alle entità ed alle relazioni del modello e vengono utilizzate sia dalle
funzioni di sistema, che da quelle amministrative.
Non si fornisce in questo caso un elenco delle funzioni di reportistica, in quanto la
scelta non è critica, ma si delega questa scelta alla fase di implementazione del
modello.
Pagina 120
7.5.2
I packages
La suddivisione in packages proposta dal NIST è sicuramente applicabile anche in
questo contesto. I packages proposti sono dunque i seguenti:
1. Core RBAC
2. Hierarchical RBAC
3. SSD (Static Separation of Duty) RBAC
4. DSD (Dynamic Separation of Duty) RBAC
Al primo fanno capo le funzionalità di base del modello, alle quali il secondo
aggiunge quelle relative alle gerarchie fra ruoli, mentre il terzo ed il quarto quelle
della separazione dei compiti rispettivamente statica e dinamica.
A questi quattro packages principali è possibile affiancare una serie di altri
packages per supportare le tipologie di vincoli illustrate e classificate nel capitolo
precedente. In particolare possono essere previsti i seguenti:
5. temporal RBAC
6. cardinality RBAC
7. transactional RBAC
8. prerequisite RBAC
Il primo offre supporto ai vincoli temporali, il secondo a quelli di cardinalità, il
terzo a quelli transazionali (o operazionali) ed il quarto ai vincoli di prerequisito.
Pagina 121
CAPITOLO 8
LA TECNOLOGIA J2EE
Prima di descrivere l’implementazione del
modello si vuole fornire una presentazione della
tecnologia J2EE, che si andrà poi ad utilizzare
per lo sviluppo del sistema RBAC. Verranno
illusrtate sia l’architettura della piattaforma
J2EE, che quella delle applicazioni enterpise
che essa è in grado di eseguire. Infine verranno
presentate le classi utilizzate nel corso del
lavoro di sviluppo del sistema RBAC.
Pagina 122
8.1 La piattaforma J2EE
J2EE è la piattaforma più diffusa del settore delle applicazioni enterprise assieme
alla piattaforma “.NET” del colosso Microsoft. La piattaforma J2EE usa un
modello distribuito a più livelli (multi-tier) per lo sviluppo di applicazioni
enterprise. Il termine “Enterprise Computing” (EC) è sinonimo di “Distributed
Computing” ovvero calcolo eseguito da un gruppo di programmi interagenti
attraverso una rete. La disomogeneità tra le componenti e di conseguenza la
complessità strutturale sono le caratteristiche principali di questi sistemi.
La piattaforma J2EE tende a semplificare tali aspetti fornendo un ambiente di
sviluppo completo di API e metodologie di approccio alla risoluzione dei
problemi di programmazione relativi alle applicazioni enterprise. La soluzione
proposta da Sun si compone di quattro elementi principali:
•
Specifiche
•
Reference Implementation
•
Test di compatibilità
•
Application Programming Model (APM)
Le specifiche elencano gli elementi necessari alla piattaforma e le procedure da
seguire per una corretta implementazione di applicazioni basate su J2EE. La
Reference Implementation contiene prototipi che rappresentano istanze
semanticamente corrette di J2EE al fine di fornire all’industria del software
modelli completi per i test di compatibilità. Include tool per il deployment e
l’amministrazione di sistema, diversi EJB e JSP, Java Messaging Service e altri
prodotti di terzi. Queste tecnologie verranno tutte illustrate nei paragrafi seguenti.
L’Application Programming Model è un modello per la progettazione e la
programmazione di applicazioni basato sulla metodologia “best-practice” per
favorire un approccio ottimale alla piattaforma. Fornisce dunque una guida per il
programmatore, analizzando le operaioni da svolgere con J2EE, e stabilendo le
basi della metodologia legata allo sviluppo di sistemi multi-tier.
Pagina 123
8.2 L’architettura J2EE
Viene presentata sin da ora la figura di riferimento per l’architettura J2EE nella
sua ultima versione, la 1.4. La Sun sta preparando una nuova versione, la 5.0, che
però ad oggi è ancora in fase di sviluppo.
Figura 8-1. L’architettura J2EE
Procedendo con ordine, si comincia dalla descrizione ad alto livello
dell’architettura proposta dalla piattaforma J2EE, che divide le applicazioni
enterprise in tre strati applicativi fondamentali componenti (Component),
contenitori (Container) e connettori (Adapter).
Pagina 124
Figura 8-2. Componenti, contenitori e connettori
Le applicazioni J2EE sono costituite da componenti. Un Component è un’unità
software funzionale assemblata in un’applicazione J2EE con le sue classi, files e
interconnessioni con altri componenti. Questi ultimi sono scritti nel linguaggio di
programmazione Java e sono compilati nello stesso modo con cui si compila
qualsiasi applicazione Java. La differenza tra i componenti J2EE e le classi
standard Java risiede nel fatto che i componenti sono assemblati in
un’applicazione J2EE, che deve essere verificata per essere conforme alle
specifiche J2EE, ne viene fatto il deployment, ovvero vengono memorizzati in
opportune directory accompagnati dai relativi file di configurazione, e vengono
eseguiti e gestiti dagli application server J2EE, dei quali si parlerà in seguito.
Il modello di programmazione prevede dunque lo sviluppo di soluzioni
utilizzando componenti, a supporto dei quali fornisce le seguenti tecnologie
fondamentali:
•
Applicazioni client e Applet: sono componenti che vengono eseguiti sulla
macchina client.
•
Java Servlet, JavaServer Pages (JSP), Filters e web-event-Listener: sono
componenti web che vengono eseguiti sul server.
•
Enterprise JavaBeans (EJB): sono componenti business che vengono
eseguiti sul server.
Pagina 125
Le Applicazioni client e le Applet sono componenti che vengono eseguiti sulla
macchina client. Tipicamente sono delle GUI (Graphic User Interface), che
permettono all’utente di interagire con il sistema.
Le servlet consentono la costruzione di servizi web altamente performanti ed in
grado di funzionare sulla maggior parte degli application server ad oggi sul
mercato. Le JSP permettono invece di costruire pagine web dai contenuti
dinamici. I filtri (Filters) intercettano le richieste degli utenti e consentono di
definire controlli di qualsiasi tipo su di esse. Infine i web-event-Listener
funzionano come un qualsiasi eventListener Java, ovvero si mettono in ascolto su
un particolare tipo di evento web, segnalando la sua attivazione.
Gli EJB forniscono supporto per la creazione di componenti server-side che
possono essere generati indipendentemente da uno specifico database, transaction
server o piattaforma su cui verranno installati.
In realtà esiste un’ulteriore alternativa alle quattro riportate per la quale però non
si può parlare di tecnologia dedicate, ed è rappresentata dalle componenti serverside sviluppate utilizzando java.
Il fatto che J2EE sia indipendente dalla piattaforma, e che l’applicazione sia
basata su un modello a più livelli, rende lo sviluppo di un’applicazione J2EE
ancora più facile, grazie anche ai servizi sottostanti messi a disposizione per
ciascun tipo di componente dal suo Container. Il secondo strato dell’architettura
logica è rappresentato appunto dai contenitori, ovvero supporti tecnologici ai
Component appartenenti al primo strato. I container sono interfacce tra un
componente e le funzionalità a basso livello specifiche della piattaforma che
supportano il componente.
Infine i connettori (Adapter) consentono alle soluzioni basate sulla tecnologia
J2EE di preservare e proteggere investimenti in tecnologie già esistenti fornendo
uno strato di connessione verso applicazioni-server o middleware di varia natura,
dai database relazionali, tramite adapter JDBC, fino ai server LDAP, tramite
adapter JNDI.
Pagina 126
Gli Application Server (AS) non sono altro che dei prodotti basati sullo standard
J2EE, ovvero sono dei software che utilizzano e coordinano nel migliore dei modi
tutte le tecnologie J2EE, rendendo più semplice il lavoro degli sviluppatori. Gli
application-server compatibili con questa tecnologia riuniscono tutti e tre gli strati
in un una unica piattaforma standard e quindi indipendente dal codice
proprietario, consentendo lo sviluppo di componenti in grado di girare in
qualunque container compatibile con J2EE indipendentemente dal fornitore di
software, e di interagire con una vasta gamma di servizi pre-esistenti tramite i
connettori.
8.3 L’Application Programming Model
Il modello di programmazione APM prevede che un’applicazione J2EE sia
strutturata secondo i seguenti livelli (o tier):
1. livello Client: componenti eseguiti sulla macchina client.
2. livello Web: componenti eseguiti sul server J2EE.
3. livello Business: componenti eseguiti sul server J2EE.
4. livello Enterprise Information System (EIS): software presente sui
Database Server.
Va sottolineato il fatto che, sebbene un’applicazione J2EE possa essere suddivisa
nei quattro livelli sopra elencati, solitamente viene considerata una struttura di tre
livelli, in quanto i componenti sono distribuiti su tre locazioni differenti: macchine
client, macchina con il server J2EE, macchine con database.
Le figure seguenti esemplificano la struttura di due applicazioni enterprise multitier, strutturate secondo lo standard J2EE.
Pagina 127
Application
Figura 8-3. Esempio di applicazione enterprise multi-tier
Figura 8-4. Esempio di applicazione enterprise multi-tier
Pagina 128
8.3.1
Livello Client
Appartengono allo strato client le applicazioni che forniscono all’utente una
interfaccia verso il sistema enterprise e rappresentano quindi la percezione che
l’utente ha dell’applicazione J2EE.
Tali applicazioni si suddividono in due classi di appartenenza:
•
applicazioni web-based
•
applicazioni non-webbased
Le prime sono quelle applicazioni che utilizzano il browser come strato di
supporto alla interfaccia verso l’utente ed i cui contenuti vengono generati
dinamicamente da Servlet o Java Server Pages o staticamente in HTML.
Le seconde (non-web-based) sono invece basate su applicazioni stand-alone che
sfruttano lo strato di rete disponibile sul client per interfacciarsi direttamente con
il business-tier dell’applicazione J2EE senza passare per il Web-Tier.
8.3.2
Livello Web
Le componenti web-tier di J2EE sono rappresentate da pagine JSP, server-side
applet e Servlet. Le pagine HTML che invocano Servlet o JSP secondo lo
standard J2EE non sono considerate web-components, ed il motivo è il seguente:
come illustrato nei paragrafi precedenti si considerano componenti, oggetti
caricabili e gestibili all’interno di un contenitore. In questo caso, Servlet e JSP
hanno il loro ambiente runtime all’interno del Servlet Container che provvede al
loro ciclo di vita, nonché alla fornitura di servizi quali client-request e clientresponse, al contrario le pagine HTML, destinate ad essere visualizzate nel
browser dell’utente, non utilizzano questa struttura di supporto.
La piattaforma J2EE prevede quattro tipi di applicazioni web:
1. Basic HTML
2. HTML con JSP e Servlet
3. JSP con componenti JavaBeans
4. High Structured Application.
Di queste, le prime tre sono dette “applicazioni web-centric”, quelle appartenenti
al quarto tipo sono dette “applicazioni EJB Centric”. La scelta di un tipo di
applicazione piuttosto che di un altro dipende ovviamente da vari fattori tra cui la
Pagina 129
complessità del problema, le risorse del Team di sviluppo, la longevità della
applicazione e il dinamismo dei contenuti da gestire e proporre.
8.3.3
Livello Business
Nell’ambito di un’applicazione enterprise il livello business è lo strato che
fornisce i seguenti servizi specifici:
•
gestione delle transazioni
•
controllo della concorrenza
•
gestione della sicurezza
•
gestione di logiche specifiche per la manipolazione dei dati
Mediante un approccio di tipo Object Oriented è possibile decomporre tali logiche
o logiche di business in un insieme di componenti ed elementi chiamati “business
object”. La tecnologia fornita da Sun per implementare i “business object” è
quella che in precedenza è stata definita come EJBs (Enterprise Java Beans). Tali
componenti si occupano di:
•
Ricevere dati da un client
•
Processare tali dati
•
Inviare i dati allo strato EIS per la loro memorizzazione su base dati
E viceversa:
•
Acquisire dati da un database appartenente allo strato EIS
•
Processare tali dati
•
Inviare tali dati al programma client che ne abbia fatto richiesta.
La figura seguente esemplifica quanto appena illustrato.
Pagina 130
Figura 8-5. Funzionamento del business-tier
Esistono tre tipi principali di EJBs :
1. Entity Beans
2. Session Beans
3. MessagedrivenBeans
Un Session Bean rappresenta una comunicazione temporanea con un client.
Quando il client termina la sua esecuzione, il Session Bean e i suoi dati sono
persi. L’Entity Bean, a differenza del Session Bean, rappresenta dei dati
persistenti, memorizzati in una riga di una tabella del database. Se il client termina
o il server viene chiuso, i servizi sottostanti assicurano che i dati dell’Entity Bean
vengano salvati. Un Message-Driven Bean combina le caratteristiche di un
Session Bean e di un Java Message Service (JMS) Message Listener, permettendo
così a un componente business di ricevere messaggi JMS in modo asincrono.
Un Enterprise Bean vive all’interno del container che provvede al ciclo vitale
della componente e ad una varietà di latri servizi, quali la gestione della
concorrenza e la scalabilità. L’EJB Container è a sua volta parte di un EJB server
che fornisce tutti i servizi di naming e di directory, dei quali si parlerà in seguito.
8.3.4
Livello EIS
Le applicazioni enterprise implicano per definizione l’accesso ad altre
applicazioni, dati o servizi sparsi all’interno delle infrastrutture informatiche del
fornitore di servizi. Le informazioni gestite ed i dati contenuti all’interno di tali
Pagina 131
infrastrutture rappresentano la “ricchezza” del fornitore, e come tale vanno trattati
con estrema cura garantendone la integrità. Il livello EIS si preoccupa proprio di
gestire i questi dati e renderli disponibili al business-tier.
Gli scenari di riferimento sono svariati e comprendono vari modelli di
configurazione che le architetture enterprise possono assumere per soddisfare le
necessità più disparate. Un modello classico è quello dei sistemi di commercio
elettronico, rappresentato in figura.
Figura 8-6. Modello del commercio elettronico
8.4 Le API J2EE
Le API (Application Programming Interface) fornite dallo standard J2EE offrono
supporto al programmatore per lavorare con le più comuni tecnologie utilizzate
nell’ambito della programmazione distribuita e dei servizi di interconnessione via
rete.
Segue nei prossimi paragrafi una panoramica delle API più significative.
8.4.1
JDBC (Java DataBase Connectivity)
La tecnologia JDBC è un adapter che permette di lavorare con database
relazionali. Le API JDBC consentono al programmatore di inviare query ad un
Pagina 132
database relazionale, di effettuare modifiche dei dati all’interno di tabelle, di
lanciare stored-procedure e di ottenere meta-informazioni relativamente al
database o alle entità che lo compongono.
Architetturalmente le API JDBC sono suddivise in due strati principali:
1. il primo fornisce una interfaccia verso il programmatore
2. il secondo di livello più basso fornisce invece una serie di API per i
produttori di driver verso database relazionali e nasconde all’utente i
dettagli del driver in uso. Questa caratteristica rende la tecnologia
indipendente rispetto al motore relazionale che il programmatore deve
interfacciare. I driver JDBC possono essere suddivisi in 4 tipi
fondamentali come illusrtato nella seguente tabella:
Tipo 4
Tipo 3
Tipo 2
Tipo
Direct-to-Database Pure Java Driver
Pure Java Driver for Database Middleware;
JDBC-ODBC Bridge plus ODBC Driver;
1 A native-API partly Java technology-enabled driver.
Tabella 8-1. Classificazione API JDBC
I driver di tipo 4 e 3 appartengono a quella gamma di driver che convertono le
chiamate JDBC nel protocollo di rete utilizzato direttamente da un server
relazionale o un “middleware” che fornisca connettività attraverso la rete verso
uno o più database e sono scritti completamente in Java. La figura seguente
mostra la loro architettura.
Pagina 133
Figura 8-7. Driver JDBC di tipo 3 e 4
I driver di tipo 2 sono driver scritti parzialmente in Java e funzionano da
interfaccia verso API native di specifici prodotti. I driver di tipo 1, anch’essi
scritti parzialmente in Java, hanno funzioni di bridge verso il protocollo ODBC
rilasciato da Microsoft. Questi driver sono anche detti JDBC/ODBC Bridge e
rappresentano una buona alternativa in situazioni in cui non siano disponibili
driver di tipo 3 o 4.
La figura seguente mostra l’architettura di drivers di tipo 1 e 2.
Pagina 134
Figura 8-8. Driver JDBC di tipo 1 e 2
8.4.2
RMI (Remote Method Invocation)
RMI (Remote Method Invocation) fornisce il supporto per sviluppare applicazioni
in grado di invocare metodi di oggetti distribuiti su virtual-machine differenti
sparse per la rete. Grazie a questa tecnologia è possibile realizzare architetture
distribuite in cui un client invoca metodi di oggetti residenti su un server, che a
sua volta può essere client nei confronti di un altro server.
Oltre a garantire tutte i vantaggi tipici di una architettura distribuita, essendo
fortemente incentrato su Java RMI, consente di trasportare in ambiente distribuito
tutte le caratteristiche di portabilità e semplicità legate allo sviluppo di
componenti Object Oriented:
1) RMI è in grado di passare oggetti e ritornare valori durante una chiamata a
metodo oltre che a tipi di dati predefiniti. Questo significa che dati
Pagina 135
strutturati e complessi come le Hashtable possono essere passati come un
singolo argomento senza dover decomporre l’oggetto in tipi di dati
primitivi.
2) RMI consente di delegare l’implementazione di una classe dal client al
server o viceversa. Questo fornisce una enorme flessibilità al
programmatore che scriverà solo una volta il codice per implementare un
oggetto che sarà immediatamente visibile sia a client che al server.
3) RMI estende le architetture distribuite consentendo l’uso di thread da parte
di un server RMI per garantire la gestione ottimale della concorrenza tra
oggetti distribuiti.
4) RMI abbraccia la filosofia “Write Once Run Anywhere” di Java: ogni
sistema RMI è portabile su ogni Java Virtual Machine.
8.4.3
Java IDL (Interface Definition Language)
RMI rappresenta una soluzione per la creazione di sistemi ad oggetti distribuiti
con la limitazione che tali oggetti debbano essere scritti in Java. Tale soluzione
non si adatta invece alle architetture in cui gli oggetti distribuiti siano scritti con
linguaggi arbitrari. Per far fronte a tali situazioni, la Sun offre anche la soluzione
basata su CORBA (Common Object Request Broker Architecture) [93] per la
chiamata ad oggetti remoti.
CORBA
è uno standard largamente utilizzato introdotto dall’OMG (Object
Management Group) e prevede la definizione delle interfacce verso oggetti remoti
mediante un IDL (Interface Definition Language) indipendente dalla piattaforma e
dal linguaggio di riferimento con cui l’oggetto è stato implementato.
L’implementazione di questa tecnologia rilasciata da Sun comprende un ORB
(Object Request Broker) in grado di interagire con altri ORB presenti sul mercato,
nonché di un pre-compilatore IDL che traduce una descrizione IDL di una
interfaccia remota in una classe Java che ne rappresenti il dato.
Pagina 136
8.4.4
JNDI
(Java
Naming
and
Directory
Interface)
JNDI è quell’insieme di API che forniscono l’accesso a servizi generici di
Naming o Directory attraverso la rete. Consentono all’applicazione che ne abbia
bisogno, di ottenere oggetti o dati tramite il loro nome o di ricercare oggetti o dati
mediante l’uso di attributi a loro associati. Ad esempio tramite JNDI è possibile
accedere ad informazioni relative ad utenti di rete, server o workstation, sottoreti o
servizi generici.
Come per JDBC le API JNDI non nascono per fornire accesso in modo specifico
ad un particolare servizio, ma costituiscono un set generico di strumenti in grado
di interfacciarsi a servizi mediante “driver” rilasciati dal produttore del servizio e
che mappano le API JNDI nel protocollo proprietario di ogni specifico servizio.
Tali driver vengono detti “Service Providers” e forniscono accesso a protocolli
come LDAP, NIS, Novell NDS oltre che ad una gran quantità di servizi come
DNS, RMI o CORBA Registry.
8.4.5
JMS (Java Message Service)
Le API JMS forniscono supporto alle applicazioni enterprise nella gestione
asincrona della comunicazione verso servizi di “messaging” o nella creazione di
nuovi MOM (Message Oriented Middleware).
Grazie a JMS è possibile scrivere applicazioni di business “message-based”
altamente portabili fornendo un’alternativa a RMI, che risulta necessaria in
determinati ambiti applicativi. Nel modello proposto da J2EE l’accesso alle
informazioni contenute all’interno di questo strato è possibile tramite oggetti
chiamati connettori che rappresentano un’architettura standard per integrare
applicazioni e componenti enterprise eterogenee con sistemi informativi enterprise
anche loro eterogenei.
8.5 Servlet API: il package javax.servlet
Il package javax.servlet è il package di base delle Servlet API, e contiene le classi
per definire Servlet standard indipendenti dal protocollo. Tecnicamente una
Pagina 137
Servlet generica è una classe definita a partire dall’interfaccia Servlet contenuta
all’interno del package javax.servlet. Questa interfaccia contiene i prototipi di tutti
i metodi necessari alla esecuzione delle logiche di business, nonché alla gestione
del ciclo di vita dell’oggetto dal momento della sua istanziazione, sino al
momento della sua terminazione.
I metodi definiti in questa interfaccia devono essere supportati da tutte le servlet o
possono essere ereditati attraverso la classe astratta GenericServlet che
rappresenta una implementazione base di una servlet generica. Il package include
inoltre una serie di classi utili alla comunicazione tra client e server, nonché
alcune interfacce che definiscono i prototipi di oggetti utilizzati per tipizzare le
classi che saranno necessarie alla specializzazione della servlet generica in servlet
dipendenti da un particolare protocollo.
La figura seguente mostra l’architettura del package javax.servlet.
Figura 8-9. Il package javax.servlet
La particolare specializzazione della servlet generica che interessa in questo
ambito è quella fornita dal package javax.servlet.http. Quest’ultimo supporta lo
sviluppo di Servlet che, specializzando la classe base astratta GenericServlet
Pagina 138
definita nel package javax.servlet, utilizzano il protocollo HTTP. Le classi di
questo package estendono le funzionalità di base di una servlet supportando tutte
le caratteristiche della trasmissione di dati con protocollo HTTP compresi
cookies, richieste e risposte HTTP nonché metodi HTTP (get, post, head, put).
Formalmente quindi, una servlet specializzata per generare contenuti specifici per
il
mondo
web
sarà
ottenibile
estendendo
la
classe
base
astratta
javax.servlet.http.HttpServlet.
La figura seguente mostra la gerarchia del package.
Figura 8-10. Il package javax.servlet.http
Non si vuole descrivere ovviamente l’intero package, si desidera semplicemente
presentare quelle classi rilevanti per l’implementazione del modello RBAC. I
prossimi paragrafi presentano dunque le classi di maggiore interesse.
Pagina 139
8.5.1
HttpServletResponse
Questa classe definisce il canale di comunicazione tra la servlet ed il client che ha
inviato la richiesta e mette a disposizione della servlet i metodi necessari per
inviare al client i risultati prodotti dalla manipolazione dei dati di input. Una
istanza dell’oggetto ServletResponse viene definita per implementazione della
interfaccia HttpServletResponse definita all’interno del package javax.servlet.http
che definisce una specializzazione della interfaccia derivata rispetto al protocollo
http.
8.5.2
HttpServletRequest
La classe di oggetti di tipo HttpServletRequest rappresenta una richiesta http.
Mediante i metodi messi a disposizione da questa interfaccia, è possibile accedere
ai contenuti della richiesta http inviata dal client compreso eventuali parametri o
entità trasportate all’interno del pacchetto HTTP. I metodi ServletInputStream
getInputStream e BufferedReader getReader permettono di accedere ai dati
trasportati dal protocollo. Il metodo getParameter consente di ricavare i valori dei
parametri contenuti all’interno della query string della richiesta referenziandoli
tramite il loro nome. Esistono inoltre altri metodi che consentono di ottenere meta
informazioni relative alla richiesta
8.5.3
Sessioni utente
Le Servlet mettono a disposizione del programmatore la possibilità di racchiudere
l’attività di un client per tutta la sua durata all’interno di sessioni utente. Una
servlet può utilizzare una sessione per memorizzare dati persistenti, dati specifici
relativi all’applicazione e recuperarli in qualsiasi istante sia necessario.
Quando si crea una sessione utente, l’oggetto generato viene messo in uno stato di
“new” che sta ad indicare che la sessione è stata creata ma non è attiva. Dal punto
di vista puramente formale è ovvio che per essere attiva la sessione deve essere
accettata dal client ovvero una sessione viene accettata dal client solo nel
momento in cui invia al server per la prima volta l’identificativo della sessione.
Pagina 140
Ogni volta che un client effettua una richiesta http, se in precedenza è stata
definita una sessione utente legata al particolare client, il servlet container
identifica il client e determina quale sessione è stata associata ad esso.
Ogni sessione creata dal container è associata in modo univoco ad un
identificativo o ID. Due sessioni non possono essere associate ad uno stesso ID.
8.5.3.1
HttpSession
La classe httpSession viene definita dall’interfaccia javax.servlet.http.HttpSession,
che comprende tra gli altri i seguenti metodi:
•
String getId()
•
long getCreationTime()
•
long getLastAccessedTime()
•
int getMaxInactiveInterval()
•
boolean isNew()
E’ importante notare che i metodi che ritornano un valore che rappresenta un
“tempo” rappresentano il dato in secondi. Sarà quindi necessario operare le
necessarie conversioni per determinare informazioni tipo date ed ore.
Il significato dei metodi descritti risulta chiaro leggendo il nome del metodo. Il
primo ritorna l’identificativo della sessione, il secondo il tempo in secondi
trascorso dalla creazione della sessione, il terzo il tempo in secondi trascorso
dall’ultimo accesso alla sezione, mentre il quarto l’intervallo massimo di tempo di
inattività della sessione. Il metodo isNew restituisce un valore booleano che indica
lo stato della sessione, ovvero se è o meno attiva.
Altri metodi che possono risultare utili sono i seguenti:
•
void putValue(String name, Object value)
•
void removeValue(String name)
•
String[] getValueNames(String name)
•
Object getValue(String name)
Consentono di memorizzare o rimuovere oggetti nella forma di coppie <nome =
oggetto> all’interno della sessione consentendo ad una servlet di memorizzare dati
(in forma di oggetti) all’interno della sessione per poi utilizzarli ad ogni richiesta
HTTP da parte dell’utente associato alla sessione.
Pagina 141
Questi oggetti saranno inoltre accessibili ad ogni servlet che utilizzi la stessa
sessione utente potendoli recuperare conoscendo il nome associato.
8.5.3.2
Durata di una sessione utente
Una sessione utente rappresenta un oggetto transiente la cui durata deve essere
limitata al periodi di attività dell’utente sul server. Utilizzando i metodi:
•
void invalidate()
•
int setMaxInactiveInterval(int interval)
è possibile invalidare una sessione o disporre che una volta superato l’intervallo
massimo di inattività la servlet venga automaticamente resa inattiva dal container.
8.5.4
Filter
Tramite l'implementazione della interfaccia javax.servlet.Filter si è in grado di
creare oggetti che filtrino le invocazioni da parte del client HTTP, verso una
risorsa dinamica (Servlet o JSP), ma anche statica (pagine HTML o altro ancora).
Un filtro inoltre può modificare la risposta inviata al client prima che questa sia
effettivamente inviata.
Formalmente un filtro si definisce come un preprocessore di una request http
(prima che questa raggiunga la servlet) e post processore della risposta (prima che
questa venga inviata al client).
Più precisamente un filtro può effettuare le seguenti operazioni
•
Intercettare una chiamata ad una servlet prima che questo sia
effettivamente eseguito
•
Esminare una richiesta prima del suo inoltro alla servlet
•
Modificare la sezione degli header dei vari pacchetti HTTP, prima del loro
inoltro alla servlet
•
Modificare la sezione degli header dei vari pacchetti HTTP, prima della
spedizione al client
•
Intercettare una chiamata di una servlet dopo che tale servlet sia stata
invocato
Un filtro fa dunque parte di una catena (pipeline) di componenti: è possibile
specificare vari filtri in cascata, l’ultimo dei quali è la risorsa target richiesta dal
Pagina 142
client. La pipeline di filtro è definita a livello di configurazione dell’applicazione
Web e questo permette di gestirne il deployment in modo disaccoppiato dallo
sviluppo.
Come
posizionamento
nella
gerarchia
delle
classi
Java,
un
filtro
implementa l’interfaccia javax.servlet.Filter: si tratta essenzialmente di fornire tre
metodi, i soliti init/destroy di primo caricamento/scaricamento del filtro nel
container e il doFilter, dove definire il comportamento applicativo del filtro.
Il metodo doFilter ha tre argomenti, la coppia richiesta/risposta tipica di una
servlet ordinaria (è quindi possibile impiegare un filtro come una servlet, basta
fargli tornare direttamente una risposta al client) e un terzo argomento di tipo
FilterChain, che permette al filtro di appartenere alla pipeline definita a livello di
descrittore di deployment. A questo punto basterà che il filtro richiami il metodo
doFilter (richiesta/risposta) dell’oggetto FilterChain per innescare il successivo
stadio dell’elaborazione e il container richiamerà il prossimo filtro.
8.5.5
Eventi di tipo HTTP session
Gli eventi di tipo HTTP session, implementati tramite istanze della classe
javax.servlet.http.HttpSessionEvent o di sue sottoclassi, scattano in funzione delle
fasi del ciclo di vita dell'oggetto HttpSession corrente, il quale permette di
identificare e tracciare gli utenti di un'applicazione web. Vi sono due interfacce:
1. javax.servlet.http.HttpSessionListener, il cui fine consiste nel notificare il
listener degli eventi globali nell'ambito del ciclo di vita di una sessione
http. Comprende i seguenti metodi:
o public void sessionCreated(javax.servlet.http.HttpSessionEvent
hse): informa che una nuova sessione HTTP, accessibile tramite il
parametro di tipo HttpSessionEvent, è stata creata;
o public void sessionDestroyed(javax.servlet.http.HttpSessionEvent
hse): informa che una sessione HTTP è stata invalidata;
2. public void javax.servlet.http.HttpSessionAttributeListener, il quale
notifica al listener ogni modifica della tabella degli attributi di una
sessione HTTP (anche in questo gli eventi vengono fatti scattare a
modifica avvenuta) . Comprende i seguenti metodi:
Pagina 143
o public void attributeAdded
(javax.servlet.http.HttpSessionBindingEvent hsbe): un nuovo
attributo, i cui dati sono accessibili tramite il parametro di evento, è
stato aggiunto alla sessione HTTP.
o public void attributeRemoved
(javax.servlet.http.HttpSessionBindingEvent hsbe): un attributo, i
cui dati sono ancora accessibili tramite il parametro evento, è stato
eliminato dalla sessione HTTP.
o public void attributeReplaced
(javax.servlet.http.HttpSessionBindingEvent hsbe): un attributo di
sessione HTTP è stato modificato ed i suoi precedenti dati possono
venire recuperati tramite l'oggetto HttpSessionBindingEvent.
8.6 JSP (Java Server Pages)
Una pagina JSP è un semplice file di testo che fonde codice html a codice Java per
formare una pagina dai contenuti dinamici. Questa tecnologia dà la possibilità di
unire codice HTML con codice Java senza che uno interferisca con l’altro e
consente di isolare la rappresentazione dei contenuti dinamici dalle logiche di
presentazione. Il disegnatore potrà concentrarsi solo sulla impaginazione dei
contenuti che saranno inseriti dal programmatore, il quale non dovrà preoccuparsi
dell’aspetto puramente grafico. Le JavaServer Pages consentono dunque di
realizzare applicazioni web dinamiche accedendo a componenti Java contenenti
logiche di business o alla base dati del sistema.
8.6.1
Compilazione di una pagina JSP
Se dal punto di vista del programmatore una pagina JSP è un documento di testo
contenente tag html e codice Java, dal punto di vista del server una pagina JSP è
utilizzata allo stesso modo di una servlet. Di fatto, nel momento del primo accesso
da parte dell’utente, la pagina JSP richiesta viene trasformata in un file Java e
compilata dal compilatore interno della virtual machine. Come prodotto della
compilazione si otterrà una classe Java che rappresenta una servlet di tipo
HttpServlet che crea una pagina html e la invia al client.
Pagina 144
Tipicamente l’application server memorizza su disco tutte le definizioni di classe
ottenute dal processo di compilazione appena descritto per poter riutilizzare il
codice già compilato. L’unica volta che una pagina JSP viene compilata è al
momento del suo primo accesso da parte di un client o dopo modifiche apportate
dal programmatore affinché il client acceda sempre alla ultima versione prodotta.
8.7 Autorizzazione in J2EE
I paragrafi che seguono illustrano il modello base di autorizzazione della
tecnologia J2EE ed un modello più evoluto, JAAS (Java Authentication and
Authorization Service), che è stato inizialmente sviluppato parallelamente alle
versioni J2EE rilasciate dalla Sun e che è stato infine incluso nella sua ultima
versione, la 1.4.
8.7.1
Modello di autorizzazione di base
Il modello di autorizzazione di base per lo standard J2EE è basato sul concetto di
“security role”. Non bisogna farsi trarre in inganno però dall’utilizzo della parola
“ruolo”, perché in realtà siamo di fronte all’usuale concetto di gruppo. Infatti un
security role non è altro che un raggruppamento logico di utenti.
Tramite un descrittore di deployment opportunamente strutturato è possibile
associare un utente ad un security role e definire quali metodi (ad esempio di una
Servlet o di un EJB) sono accessibili a quest’ultimo.
Durante il funzionamento del sistema è possibile verificare che l’invocazione di
un metodo da parte di un utente sia autorizzata, utilizzando i seguenti metodi:
•
Per le Servlet: “isUserInRole” della classe HttpServletRequest.
•
Per gli EJB: “isCallerInRole” della classe EJBContext.
Entrambi i metodi restituiscono un valore booleano che indica se l’utente è o
meno associato al ruolo che sta cercando di ricoprire.
Pagina 145
8.7.2
JAAS
(Java
Authentication
and
Authorization Service)
JAAS fornisce un servizio di autenticazione ed autorizzazione in modalità
“pluggable”, ovvero si aggiunge ai meccanismi già esistenti, rimanendo però
indipendente. Quello che interessa analizzare in questo ambito non è ovviamente
il servizio di autenticazione, bensì quello di autorizzazione.
Bisogna subito sottolineare il fatto che c’è molta confusione sul fatto che JAAS
supporti o meno il controllo d’accesso basato su ruoli. La risposta è negativa, ma è
vero che alcuni aspetti possono trarre in inganno e portare a conclusioni errate. La
tecnologia JAAS offre indubbiamente delle funzionalità che possono essere
ricondotte all’RBAC, ma manca completamente di altri servizi, che invece sono
fortemente caratterizzanti per il controllo d’accesso basato su ruoli.
Ecco dunque quello che JAAS permette di fare in ottica RBAC:
•
Associazione ruoli-permessi: è possibile definire in un “Java policy file”
opportunamente strutturato l’associazione tra un “named principal”
(l’equivalente di un ruolo) ed una serie di “grant entry” (l’equivalente dei
permessi).
•
Associazione utenti-ruoli: in un altro file di configurazione è possibile
associare gli username ai diversi “principal” (= ruoli).
•
Attivazione dei ruoli in una sessione utente: l’attivazione di un ruolo in
una
sessione
è
possibile
tramite
l’utilizzo
del
metodo
java.security.auth.subject.doAs, che registra per l’utente che lo invoca un
nuovo “principal” presso la classe che regola gli accessi alle risorse
protette (AccessControlContext), la quale attribuisce all’utente i permessi
assegnati al “principal”.
Ecco però quello che non è possibile fare:
•
Manca il meccanismo di disattivazione dei ruoli
•
Non vi sono i ruoli di default
•
Non si possono definire gerarchie tra ruoli
•
Manca la possibilità di aggiungere dei vincoli all’attivazione dei ruoli
•
Non è prevista l’attivazione dei permessi
Pagina 146
I punti appena elencati sono in ordine di importanza, infatti la disattivazione dei
ruoli fa parte del Core RBAC, ovvero delle sue funzionalità di base e quindi
imprescindibili. Lo stesso vale per i ruoli di default. Seguono poi il Hierarchical
RBAC ed il Constrained RBAC, anch’essi non supportati, e si finisce con
l’estensione del modello proposta, che ovviamente non poteva essere prevista.
Risulta quindi evidente come non si possa ancora affermare che J2EE supporti i
servizi di un sistema RBAC. D’altro canto la presenza di queste nuove
funzionalità, sebbene ancora insuffcienti, è sicuramente un sintomo del crescente
interesse verso il controllo d’accesso basato su ruoli.
Pagina 147
CAPITOLO 9
L’IMPLEMENTAZIONE DEL
MODELLO ESTESO
In
questo
capitolo
viene
presentata
l’implementazione del modello RBAC esteso.
Verrà descritta in primo luogo l’architettura
generale dell’applicazione, dopodiché verranno
passate in rassegna le singole componenti: il
motore statico e quello dinamico, il plug-in per
l’integrazione con l’application server J2EE ed
i
tool
amministrativi,
nonché
i
file
configurazione.
Pagina 148
di
9.1 Motivazioni
Come evidenziato negli ultimi paragrafi del capitolo precedente, è presente
l’esigenza di un’implementazione del controllo d’accesso basato su ruoli in J2EE,
che non è disponibile, se non in forma molto parziale al momento attuale.
Rimane ora da stabilire come fornire tali funzionalità aggiuntive alle applicazioni
enterprise che girano su un application server J2EE. L’approccio scelto è quello a
plug-in, similmente a quello che era stato adottato per JAAS prima che venisse
integrato con le altre tecnologie J2EE.
Questa soluzione permette inoltre di realizzare un sistema RBAC indipendente dal
contesto applicativo di interesse, in modo da poter essere utilizzato non solo in
ambito web, ma anche in altre applicazioni Java.
La scelta di realizzare un’applicazione indipendente dall’application server è
dettata principalmente dalle seguenti motivazioni:
a) Integrare il sistema RBAC direttamente nel server coincide di fatto con
l’apportare una modifica allo standard J2EE, ma questo non è
auspicabile, in quanto comporterebbe non pochi problemi di
compatibilità con applicazioni J2EE già esistenti.
b) Modificare un application server vuol dire realizzarne una patch, quindi
per ogni un nuova versione di quest’ultimo, potrebbe essere necessario
adattare nuovamente la patch, innescando così un processo di
aggiornamento difficoltoso.
c) Scegliere un particolareapplication server su cui realizzare la patch vuol
dire escludere a priori tutti gli altri e quindi limitare la diffusione del
sistema di controllo d’accesso.
d) Realizzare un’applicazione indipendente dallo specifico ambito di
utilizzo comporta l’indiscutibile vantaggio di poterla integrare con poco
lavoro aggiuntivo in qualsiasi sistema.
Per tutte queste ragioni in prima istanza è stato sviluppato un sistema RBAC
indipendente dall’ambito applicativo di interesse e si è realizzato separatamente
un plug-in, che permette a qualsiasi application server J2EE di integrare le
funzionalità di controllo d’accesso basato su ruoli.
Pagina 149
Il lavoro di implementazione del modello RBAC esteso si è dunque articolato
nelle seguenti fasi:
1. definizione
dell’insieme
di
interfacce
di
programmazione
da
implementare per supportare correttamente il modello.
2. implementazione delle interfacce definite al punto precedente, in modo
da realizzare un sistema RBAC funzionante.
3. implementazione del plug-in per integrare le funzionalità del controllo
d’accesso basato su ruoli in un application server J2EE.
I prossimi paragrafi illustreranno l’architettura dell’intero sistema ed ogni sua
singola componente.
9.2 Architettura del sistema
Ad alto livello il sistema è suddiviso nelle seguenti componenti fondamentali:
•
Un motore RBAC, in realtà diviso in:
o Un motore statico
o Un motore dinamico
•
Due tool amministrativi, ovvero:
o RBACAdmin
o RBACSessionsMonitor
•
Un Database contenente le entità e le relazioni del modello
•
Un gestore delle sessioni utente
•
Un plugin per l’application server J2EE
Il motore RBAC è l’applicativo fondamentale, che permette di verificare i vincoli
del modello. All’avvio il motore statico effettua un controllo d’integrità del
database, verificando il rispetto dei vincoli statici del modello. Se il test ha esito
positivo si avvia anche il motore dinamico, che ha invece il compito di verificare
il rispetto dei vincoli dinamici durante l’arco di tutto il funzionamento del sistema,
rispondendo positivamente o negativamente alle richieste degli utenti di compiere
una certa operazione su un oggetto del sistema.
A questo punto va ricordato che il sistema può essere configurato anche
diversamente, in modo tale da verificare i vincoli statici non solo all’avvio del
Pagina 150
sistema, ma anche ad ogni richiesta di accesso degli utenti. La scelta deve essere
effettuata in base a considerazioni circa il trade-off tra prestazioni e sicurezza:
se si vogliono privilegiare le prestazioni si accetterà di verificare i vincoli statici
solo una volta all’avvio dell’applicazione; se invece si vuole essere certi che il
database non venga corrotto durante il funzionamento del sistema, allora si opterà
per la seconda alternativa.
Nei prossimi paragrafi verrà descritta l’architettura interna di ogni motore RBAC.
I tool amministrativi implementati sono due: il primo (RBACAdmin) consente di
amministrare il database contenente i dati necessari per effettuare il controllo
d’accesso e di verificare la correttezza delle modifiche apportate, mentre il
secondo (RBACSessionsMonitor) consente di visualizzare le sessioni utente ed i
ruoli in esse attivi. Per una descrizione dettagliata dei due tool si rimanda ai
paragrafi seguenti.
Il database contiene le entità e le relazioni del modello RBAC, ovvero tutti i dati
necessari per effettuare correttamente il controllo d’accesso ed autorizzare o meno
un utente a compiere una certa operazione su un oggetto del sistema.
La scelta di utilizzare un database piuttosto che semplici file di configurazione è
dettata dalle seguenti motivazioni:
a) L’utilizzo di un DBMS permette di gestire senza sforzi aggiuntivi gli
accessi concorrenti del motore RBAC e del tool amministrativo
RBACAdmin.
b) Si può sfruttare la potenza espressiva del linguaggio SQL per effettuare
interrogazioni anche complesse.
c) È possibile definire direttamente sul DBMS alcuni vincoli statici di
integrità e delegare quindi a quest’ultimo il compito di verificarli. Di
questo si parlerà più approfonditamente nel paragrafo dedicato ai vincoli.
In realtà non tutte le informazioni relative al controllo d’accesso sono
memorizzate nel database. Infatti è necessario distinguere tra i dati persistenti e
quelli temporanei: i primi vengono collocati nel database, mentre i secondi sono
Pagina 151
oggetti direttamente gestiti dal motore dinamico, che li crea e li distrugge durante
il funzionamento del sistema.
In riferimento al capitolo sette, dove veniva descritto il modello RBAC esteso, il
contenuto del database dunque comprende:
•
elenco degli utenti
•
elenco dei ruoli
•
elenco dei ruoli di default degli utenti
•
elenco dei permessi (oggetti + operazioni )
•
elenco delle relazioni UA
•
elenco delle relazioni PA
•
elenco delle relazioni RH
•
elenco dei vincoli
I dati temporanei sono invece i seguenti:
•
elenco sessioni
•
elenco relazioni user_session
•
elenco relazioni session_roles
Va notato il fatto che non è necessario creare tre oggetti diversi per rappresentare i
dati temporanei, ma è sufficiente utilizzare un unico oggetto “Session”, del quale
ovviamente ci saranno più istanze, che contiene, oltre all’identificativo della
sessione, anche il nome dell’utente che l’ha creata e l’elenco dei ruoli in essa
attivi. Il gestore delle sessioni RBAC si preoccupa proprio della gestione di
questo tipo di oggetti.
Infine il plug-in per l’application server J2EE fa da tramite tra quest’ultimo ed il
sistema RBAC, permettendo di effettuare i dovuti controlli d’accesso a fronte di
una richiesta da parte dell’utente. Per una descrizione dettagliata di questo
meccanismo si rimanda ai paragrafi successivi.
La figura seguente mostra l’architettura del sistema nel suo complesso.
Pagina 152
•
•
•
•
•
•
•
•
DATI PERSISTENTI
elenco utenti
elenco ruoli
elenco ruoli di default
elenco permessi (oggetti + operazioni )
elenco relazioni UA
elenco relazioni PA
elenco relazioni RH
elenco vincoli
•
•
•
DATI TEMPORANEI
elenco sessioni
elenco relazioni user_session
elenco relazioni session_roles
Oggetti SESSION, che
inglobano il nome
dell’utente e l’elenco
dei ruoli attivi
DB
Tools di
amministrazione
Sistema RBAC
Plug-in
amministratore
App.
Server
utente
Figura 9-1. Architettura del sistema
9.3 I package
Prima di analizzare i dettagli implementativi del modello viene presentata una
panoramica dei package, in cui è stata suddivisa l’applicazione.
Come si vedrà le diverse interfacce sono state inserite principalmente nel package
it.unibs.ing.carlotti.rbac.core, che contiene tutte le funzionalità di base, ma le
relative implementazioni sono ovviamente distribuite su tutti gli altri package,
secondo i dettami forniti nel capitolo precedente dalla definizione del framework
del modello concettuale.
Ecco dunque l’elenco completo dei package e del loro contenuto:
Pagina 153
•
it.unibs.ing.carlotti.rbac: package principale che contiene il motore
statico e quello dinamico, rispettivamente:
o RBACIntegrity
o RBACEngine
•
it.unibs.ing.carlotti.rbac.web:
package
dedicato
al
plug-in
per
l’integrazione con J2EE; contiene le classi:
o WebFilter
o WebPlugin
•
it.unibs.ing.carlotti.rbac.core: package che contiene le funzionalità di
base del controllo d’accesso basato su ruoli; contiene le seguenti classi ed
interfacce (evidenziate in corsivo):
o EngineComponent
o DynamicConstraint
o IntegrityComponent
o StaticConstraint
o Session
o SessionsManager
o SessionsObserver
o RBACCoreStatic
o RBACCoreDynamic
o RBACSession
o RBACSessionsManager
o RBACIntegrityException
•
it.unibs.ing.carlotti.rbac.hierarchy:
package
che
contiene
l’implementazione del’RBAC gerarchico, includendo le classi relative ai
vincoli sulla gerarchia di ruoli:
o RBACHierarchyStatic
o RBACHierarchyDynamic
o RBACLimitedHerarchy
•
it.unibs.ing.carlotti.rbac.ssd: package che contie l’implementazione dei
vincoli di separazione statica dei compiti:
o RBACSSD
Pagina 154
•
it.unibs.ing.carlotti.rbac.dsd: package che contie l’implementazione dei
vincoli di separazione dinamica dei compiti:
o RBACDSD
•
it.unibs.ing.carlotti.rbac.time: package che contie l’implementazione dei
vincoli temporali:
o RBACTime
•
it.unibs.ing.carlotti.rbac.db: package che riunisce l’implementazione
delle funzioni amministrative e di reportistica, che permettono di accedere
al contenuto del database:
o AdministrativeFunctions
o ReviewFunctions
o RBACAdmin
o RBACReview
o DBUtil
•
it.unibs.ing.carlotti.rbac.admintool: package che contiene le classi
grafiche, che compongono il tool amministrativo RBACAdmin, delle quali
non si fornisce l’elenco.
•
it.unibs.ing.carlotti.rbac.sessionsmonitor: package che contiene le classi
grafiche, che compongono il tool amministrativo RBACSessionsMonitor,
delle quali non si fornisce l’elenco.
•
it.unibs.ing.carlotti.rbac.conf:
package
che
contiene
i
files
di
configurazione del sistema RBAC.
Le classi e le interfacce appena elencate verranno descritte in modo più dettagliato
nei paragrafi seguenti.
Si fornisce infine nella tabella seguente un elenco delle diverse interfacce e delle
classi che le implementano (in corsivo sono state indicate le interfacce).
Pagina 155
Interfacce
IntegrityComponent
StaticConstraint
EngineComponent
DynamicConstraint
Implementazioni
RBACIntegrity, RBACCoreStatic,
StaticContraint
RBACHierarchyStatic,
RBACLimitedHerarchy, RBACSSD
RBACEngine, RBACCoreDynamic,
DynamicContraint
RBACHierarchyDynamic, RBACDSD,
RBACTime
Session
RBACSession
SessionsManager
RBACSessionsManager
SessionsObserver
RBACSessionsMonitor
AdministrativeFunctions
RBACAdmin
ReviewFunctions
RBACReview
Tabella 9-1. Implementazione delle interfacce
9.4 Descrizione dell’implementazione
Si vuole ora fornire una descrizione del sistema RBAC approfondendo
maggiormente gli aspetti prettamente implementativi.
La figura seguente mostra in modo maggiormente dettagliato l’architettura del
sistema RBAC. Sono state evidenziate le classi che permettono di accedere al
database tramite le funzioni di reportistica e quelle amministrative. Il sistema
RBAC è stato suddiviso nei suoi due motori e nel monitor delle sessioni. Il motore
statico è utilizzato da quello dinamico e dal tool amministrativo (RBACAdmin)
per effettuare il controllo d’integrità del database. Il motore dinamico utilizza
inoltre i servizi del gestore delle sessioni, che viene monitorato anche
dall’RBACSessionsMonitor. Il plugin infine accede direttamente ai metodi del
motore dinamico per verificare i relativi vincoli durante il funzionamento del
sistema.
Pagina 156
DB
Funzioni DB
Amministrative
Tool amministrativi
Di Reportistica
Sistema RBAC
RBACAdmin
Motore Statico
RBACSessionMonitor
Motore Dinamico
WEB Plug-in
Gestore sessioni
Figura 9-2. Dettaglio architettura
Nei paragrafi seguenti verranno descritti nell’ordine il plug-in per l’application
server J2EE, il motore statico, quello dinamico ed infine il gestore ed il monitor
delle sessioni.
9.4.1
Il web plug-in
Si è realizzato un plug-in che permette di intercettare le richieste degli utenti nel
web-tier (secondo l’architettura delle applicazioni enterprise definita nel capitolo
precedente) ed effettuare a questo livello il controllo d’accesso richiamando le
opportune funzioni del sistema RBAC, che verrà descritto nei prossimi paragrafi.
Non vengono dunque coperte quelle applicazioni che permettono all’utente di
agire direttamente sul business-tier: in questo caso sarà necessario realizzare un
nuovo plug-in, del tutto simile a quello che viene ora descritto.
Pagina 157
In primo luogo è stata realizzata una classe (WebPlugin), che implementa
l’interfaccia javax.servlet.http.HttpSessionListener, in modo da intercettare gli
eventi (javax.servlet.http.HttpSessionEvent) di creazione e distruzione di una
sessione utente http (javax.servlet.http.HttpSession), come illustrato nel capitolo
precedente. Lo scopo è dunque quello di creare una corrispondenza uno a uno tra
le sessioni HTTP del server e quelle del sistema RBAC. Dall’HttpSessionEvent è
infatti possibile ricavare l’identificatore della sessione HTTP ed utilizzarlo come
identificatore della corrispondente sessione RBAC. In secondo luogo è stata
realizzata
una
classe
(WebFilter),
che
implementa
l’interfaccia
javax.servlet.Filter, in modo da intercettare le richieste di accesso degli utenti
(vedi captiolo precedente) alle risorse del sever ed invocare un opportuno metodo
del sistema RBAC per decidere se accettarle o meno. Ciò è possibile poiché si
hanno a disposizione gli oggetti ServletRequest, dal quale si può ricavare la
sessione HTTP, il suo identificativo, il nome dell’utente, quello dell’oggetto e
dell’operazione richiesta, e ServletResponse, che si può utilizzare per indirizzare
la risposta del server verso la pagina richiesta dall’utente, oppure verso una pagina
di errore. A questo punto è necessario strutturare correttamente il file di
configurazione “web.xml”, in modo da impostare l’applicazione affinché
riconosca il filtro ed il listener definiti in precedenza (vedi figura seguente).
Affinché il deployment dell’applicazione vada a buon fine, questo file deve essere
collocato in un’apposita directory dell’applicazione web. Ad esempio per Tomcat
deve essere collocato nella sotto-directory “WEB-INF” della directory principale
di deployment dell’applicazione stessa, che a sua volta si trova nella sottodirectory “webapps” della directory di installazione del server.
<filter>
<filter-name>
WebFilter
</filter-name>
<filter-class>
it.unibs.carlotti.web.WebFilter
</filter-class>
</filter>
<listener>
<listener-class>
it.unibs.carlotti.web.WebPlugin
</listener-class>
Pagina 158
</listener>
<filter-mapping>
<filter-name>
WebFilter
</filter-name>
<url-pattern>
/*
</url-pattern>
</filter-mapping>
Figura 9-3. Estratto del file "web.xml"
Affinchè un utente possa essere autenticato dal server web, è necessario inserire il
suo nome e la sua password in un opportuno file di configurazione in formato
XML. Ad esempio per Tomcat il file è denominato “tomcat-users.xml” e si trova
nella sottodirectory “conf” della directory di installazione del server stesso.
Infine va sottolineato il fatto che a livello del WebPlugin le sessioni possono non
essere autenticate, perciò non è possibile conoscere il nome dell’utente loggato al
sistema. Per risolvere questo problema viene creato un utente di default, il cui
username è impostato ad “unknown”. Se si desidera che l’utente unknown abbia
dei privilegi di accesso, è dunque necessario inserirlo nel database RBAC ed
assegnargli i relativi ruoli. A livello di WebFilter invece gli utenti possono essere
stati autenticati, di conseguenza è necessario aggiornare il nome dell’utente di una
sessione nel caso in cui sia unknown.
9.4.2
Il motore statico
Il motore statico è stato realizzato utilizzando il “pattern Decorator”, che
permette di attribuire ad un oggetto responsabilità aggiuntive, mantenendo però la
medesima
interfaccia.
IntegrityComponent,
che
In
questo
viene
caso
l’interfaccia
direttamente
comune
implementata
dalla
è
la
classe
RBACCoreStatic. Le funzionalità di quest’ultima possono essere aggiornate
tramite
la
realizzazione
di
una
classe
che
implementa
l’interfaccia
StaticConstraint. Avendo quest’ultima una reference ad un altro oggetto di tipo
IntegrityComponent, è possibile creare una catena di chiamate agli altri
StaticConstraint fino alla classe base RBACCoreStatic.
Pagina 159
La figura seguente mostra la catena di chiamate del metodo checkIntegrity: ogni
oggetto svolge i compiti che gli competono ed invoca lo stesso metodo
sull’oggetto successivo della catena.
RBACSSD
chiamata
CheckIntegrity()
RBACLimitedHierarchy
CheckIntegrity()
RBACHierarchyStatic
CheckIntegrity()
RBACCoreStatic
CheckIntegrity()
Figura 9-4. Catena di chiamate
La figura seguente mostra invece il diagramma delle classi del motore statico, che
evidenzia l’utilizzo del pattern decorator.
Pagina 160
Figura 9-5. Diagramma UML delle classi del motore statico
Questo pattern è la soluzione migliore per rendere l’implementazione del modello
RBAC modulare, facilmente aggiornabile ed espandibile con nuovi vincoli. Infatti
chiunque volesse aggiungere una nuova tipologia di vincolo statico non deve fare
altro che creare una classe che implementa l’interfaccia “StaticConstraint” ed
aggiungerla nel costruttore del motore statico:
new RBACSSD(new RBACLimitedHierarchy(new RBACHierarchyStatic(new
RBACCoreStatic())));
L’unico metodo da implementare è il “checkIntegrity”, che non fa altro che
verificare
gli
opportuni
vincoli
statici
e
lanciare
un’eccezione
(“IntegrityException”) nel caso in cui essi non siano rispettati.
9.4.3
Il motore dinamico
La stessa scelta circa l’utilizzo del pattern Decorator è stata fatta anche per il
motore dinamico, come evidenzia la figura che segue.
Pagina 161
Figura 9-6. Diagramma UML delle classi del motore dinamico
In questo caso chiunque volesse implementare un nuovo vincolo dinamico (o
storico) dovrebbe creare una nuova classe, che implementi l’interfaccia
“DynamicConstraint” ed aggiungerla nel costruttore del motore dinamico, così
come si faceva per quello statico.
Come si può vedere in figura, i metodi da implementare sono maggiori in numero
rispetto al caso precedente, ma non è detto che si debbano inserire controlli
aggiuntivi in ognuno di essi. Ad esempio se si desidera implementare un vincolo
sull’attivazione dei permessi è sufficiente agire sul metodo “activatePermission”,
se invece si vuole intervenire sull’attivazione dei ruoli sarà necessario intervenire
il sui metodi “addActiveRole” ed eventualmente “dropActiveRole”.
Pagina 162
La tabella seguente mostra su quali metodi interviene ogni implementazione
dell’interfaccia EngineComponent. Il simbolo “/” indica che non vengono fatti
controlli o operazioni aggiuntive, ma ovviamente deve essere comunque presente
l’invocazione del metodo opportuno nella catena delle chiamate, così come è stato
mostrato per il motore statico.
Vincoli
Metodi
RBACCore
RBACHierarchy
Dynamic
Dynamic
RBACDSD
RBACTime
/
/
/
/
/
/
/
Vincoli DSD
/
Eistenza
utente,
CreateSession
attivazione
ruoli di
default
DeleteSession
AddActiveRole
DropActiveRole
ActivatePermission
Esistenza
sessione
Esistenza
ruolo
Esistenza
ruolo
Esistenza
permesso
/
Operazioni di
disattivazione
/
/
/
Vincoli
temporali
Esistenza
CheckAccess
utente,
Aggiunge ai
sessione,
controlli Core la
permesso,
possibilità di
ruolo,
trovare un ruolo
attivazione
fra quelli
ruolo e
ereditati
/
/
permesso
Tabella 9-2. Controlli vincoli dinamici
Pagina 163
Da notare è infine il fatto che al metodo activatePermission viene passata, oltre al
nome, anche la reference all’oggetto coinvolto nel vincolo, in modo da supportare
anche eventuali controlli, che hanno la necessità di fare riferimento ad attributi
memorizzati nell’istanza dell’oggetto stesso.
9.4.4
Il gestore e il monitor delle sessioni
Il gestore ed il monitor delle sessioni sono legati dal punto di vista
dell’architettura del sistema dal “pattern Observer”, che permette di definire una
dipendenza one-way tra un oggetto ed i suoi osservatori, in modo tale che il primo
possa informare i secondi qualora cambi stato e questi possano quindi aggiornarsi
correttamente. In pratica, con riferimento alla figura seguente, quando una
sessione viene creata, distrutta o ne vengono aggiornati i ruoli attivi, viene
invocato il metodo notifyObservers, che a sua volta invoca il metodo update di
tutti i SessionObserver che si erano precedentemente registrati tramite il metodo
attach. A questo punto ogni osservatore può aggiornare il suo contenuto
informativo andandolo a prelevare direttamente dal gestore delle sessioni.
La figura seguente mostra il diagramma delle classi del gestore e del monitor delle
sessioni, evidenziando l’utilizzo del pattern Observer.
Figura 9-7. Diagramma UML delle classi di gestore e monitor delle sessioni
Pagina 164
Ogni volta che viene aggiunta o rimossa una sessione il gestore delle sessioni
informa dunque il monitor che è avvenuto un cambiamento e quest’ultimo
aggiorna immediatamente il suo contenuto informativo.
9.4.5
Note implementative
Rimangono da fare due note implementative. La prima riguarda l’utilizzo del
“pattern Singleton”, che assicura la creazione di un sola istanza delle seguenti
componenti architetturali:
•
Motore statico (RBACIntegrity)
•
Motore dinamico (RBACEngine)
•
Gestore delle sessioni (RBACSessionsManager)
•
Funzioni amministrative del database (RBACAdmin)
•
Funzioni di reportistica del database (RBACReview)
La seconda nota invece riguarda in generale l’implementazione del codice, che è
stata realizzata utilizzando le ultime novità apportate al JDK 1.5 (detto anche
Tiger), tra le quali la principale è l’introduzione dei cosiddetti “Generics”, che
permettono di costruire tipi parametrizzati, che vengono controllati già in fase di
compilazione.
9.5 Il database
L’accesso al database è regolato da due classi, RBACAdmin ed RBACReview,
che implementano rispettivamente le funzioni amministrative, definite dal
modello, e quelle di reportistica, che invece non erano definite. Per avere un
elenco completo dei metodi di questa classe (ed anche di tutte le altre) si rimanda
alla documentazione del codice in appendice.
Il database contiene una tabella per ogni entità, relazione e vincolo del modello:
•
RbacUser {ID, name}
•
Role {ID, name}
•
UserDefaultRole {IDuser, IDrole}
•
Permission {ID, name object, operation}
Pagina 165
•
UA {IDuser, IDrole}
•
PA { IDpermission ,IDRole }
•
RH { IDparent, IDchild}
•
SSD { ID, Role1, Role2}
•
DSD {ID, Role1, Role2}
•
Time {IDpermission ,IDRole, FromTime, ToTime}
9.5.1
I vincoli supportati ed il loro formato
Un ultimo aspetto progettuale non completamente definito a livello di modello
concettuale è la scelta dei vincoli da supportare (oltre ovviamente a quelli base) ed
il loro formato.
I vincoli supportati sono i seguenti:
•
Gerarchia limitata: numero massimo di figli e di padri di un ruolo
•
Separazione statica dei compiti
•
Separazione dinamica dei compiti
•
Vincoli temporali di intervallo sull’attivazione dei permessi
Il formato scelto per i vincoli di separazione dei compiti statica e dinamica è
quello della mutua esclusione espressa per coppie di ruoli, così com’è stata
descritta in precedenza nel capitolo sei.
I vincoli temporali invece richiedono di specificare il ruolo ed il permesso che si
desidera attivare, nonché gli istanti temporali (iniziale e finale) che delimitano
l’intervallo all’interno del quale il permesso può essere attivato.
Per quanto riguarda invece i vincoli gerarchici (ovvero quelli sul numero massimo
di padri e figli che può aver un ruolo), essendo molto semplici da esprimere, non
sono stati inseriti nel database, ma in un apposito file di configurazione
("hierarchy.properties"), il cui contenuto viene riportato in figura.
hierarchy.maxParent = 1
hierarchy.maxChild = inf
Figura 9-8. File di configurazione "hierarchy.properties"
Pagina 166
La property “MaxParent” indica il numero massimo di padri di un ruolo, mentre
in modo analogo “MaxChild” indica in numero massimo di figli. La stringa “inf”
sta per “infinito” e serve ad indicare che non c’è un limite massimo per i figli (o i
padri) che può aver un ruolo. Nel caso opposto in cui viene indicato il valore zero
per uno qualsiasi dei due parametri (maxParent e maxChild), un ruolo non può
avere né figli, né padri, appiattendo dunque la gerarchia.
9.6 I tool amministrativi
In questa sezione si vogliono illustrare le funzionalità messe a disposizione dai
tool di amministrazione, l’AdminTool ed il SessionsMonitor.
9.6.1
AdminTool
Il tool di amministrazione AdminTool permette di agire sul database RBAC e
modificarne il contenuto. Per prima cosa è necessario autenticarsi, utilizzando lo
username e la password che sono a protezione del database. L’autenticazione
viene fatta dal DBMS stesso, al quale vengono passate direttamente le credenziali
inserite dall’utente. Questa scelta è dettata dal fatto che chi modifica i dati
memorizzati all’interno del database deve avere i privilegi per accedervi.
Il tool presenta una serie di schede all’interno delle quali viene visualizzato il
contenuto del database e vengono presentate le funzionalità di base per creare
nuovi elementi ed eliminare quelli esistenti. Le schede messe a disposizione sono
le seguenti:
•
Users: gestione degli utenti
•
Roles: gestione dei ruoli
•
Permissions: gestione dei permessi
•
User assignment: assegnazione dei ruoli agli utenti
•
Default roles: assegnazione dei ruoli attivati di default agli utenti
•
Permission assignment: assegnazione dei permessi ai ruoli
•
Role Hierarchy: gestione delle relazioni gerarchiche
•
SSD: gestione dei vincoli di separazione dei compiti statica
•
DSD: gestione dei vincoli di separazione dei compiti dinamica
Pagina 167
•
Time: gestione dei vincoli temporali
La figura seguente mostra un esempio di utilizzo del tool per l’assegnazione di un
ruolo ad un utente.
Figura 9-9. RBACAdmin tool: assegnazione di un ruolo ad un utente
Il tool permette di controllare l’integrità del database, ovvero il rispetto dei vincoli
statici, che esso stesso contiene. Ogni volta che un vincolo è violato compare un
avviso simile a quello mostrato nella figura che segue.
Pagina 168
Figura 9-10. RBACAdmin tool: violazione di un vincolo SSD
9.6.2
SessionMonitor
Il monitor delle sessioni si avvia assieme all’applicativo e mostra in ogni istante
tutte le sessioni attive, indicandone l’identificativo ed il nome dell’utente.
Facendo doppio clic su una sessione, vengono mostrati in una nuova finestra i
ruoli attivi della sessione selezionata.
La figura seguente mostra in secondo piano il browser attraverso il quale l’utente
“giacomo” è acceduto ad una pagina del web server. In primo piano si può vedere
il SessionMonitor che mostra la sessione dell’utente ed i ruoli che essa ha attivato.
Pagina 169
Figura 9-11. RBACSessionsMonitor
9.7 I file di configurazione
I file di configurazione sono contenuti nel package “it.unibs.ing.carlotti.rbac.conf”
ed il loro formato è lo standard “.properties”, che è così definito: ogni riga del file
deve essere composta dal nome di una proprietà, un ‘=’ e un valore da attribuire
alla proprietà indicata. Utilizzando questo formato è possibile utilizzare delle
apposite classi Java che ne rendono la lettura particolarmente semplice ed
immediata.
I diversi file di configurazione sono strutturati in modo gerarchico, ovvero vi è un
file di configurazione principale dal quale dipendono tutti gli altri. Questo file si
deve chiamare necessariamente “rbac.properties” ed il suo contenuto è mostrato
nella figura seguente.
rbac.config.db = postgre.properties
rbac.config.checkalways = false;
rbac.create.db = postgre.sql
Figura 9-12. File di configurazione “rbac.properties”
Pagina 170
Le proprietà contenute in questo file sono le seguenti:
•
rbac.config.db: indica il nome del file che contiene i dati necessari per
accedere al database.
•
rbac.config.checkalways: indica se il controllo di integrità del database
deve essere fatto per ogni accesso di un utente (vedi paragrafi precedenti).
•
rbac.create.db: indica il nome del file SQL che contiene le istruzioni per
creare il database.
Il file indicato dalla proprietà “rbac.config.db” è a sua volta un file properties ed è
strutturato come mostrato in figura.
db.username = giacomo
db.password = rbac05Carlotti
db.url = jdbc:postgresql://localhost/rbac
db.driver = org.postgresql.Driver
Figura 9-13. File di configurazione “postgre.properties”
Il file contiene le seguenti informazioni:
•
db.username: username per accedere al database (non viene utilizzato
dall’AdminTool)
•
db.password: password per accedere al database (non viene utilizzato
dall’AdminTool)
•
db.url: indirizzo del database
•
db.driver: driver JDBC (vedi capitolo precedente) da utilizzare per
interfacciarsi correttamente al DBMS.
Infine fa parte di questo package anche il file “hierarchy.properties”, che è stato
mostrato in precedenza e che contiene le informazioni circa i vincoli che limitano
la gerarchia fra ruoli.
Pagina 171
CAPITOLO 10
TEST E CONCLUSIONI
Questo è il capitolo finale della presente
trattazione, in cui viengono presentati la fase di
test dell’applicazione ed i suoi risultati. Si
traggono dunque le conclusioni sul lavoro
svolto e si propongono tre possibili filoni per
proseguire lo studio sul controllo d’accesso
basato su ruoli.
Pagina 172
10.1 Testing
Il sistema sviluppato è stato testato sia in ambiente Linux, che in ambiente
Windows utilizzando due DMBS differenti, PostgreSQL e MySQL.
La tabella seguente riassume le diverse configurazioni di testing.
LINUX
WINDOWS
Versione
Mandrake 10.0
Windows XP Professional SP2
DBMS
MySQL 4.1.12
PostgreSQL 8.0
JVM
1.5.0 update 04
1.5.0 update 04
Jakarta Tomcat 5.5.9
Jakarta Tomcat 5.5.9
Application
Server
Tabella 10-1. Configurazioni di Testing
Il lavoro si è articolato nelle seguenti fasi:
•
installazione DBMS
•
creazione database e popolazione delle tabelle
•
installazione Application Server
•
realizzazione di una semplice applicazione di test tramite JSP
•
deployment dell’applicazione di test
•
configurazione del sistema RBAC
•
deployment del sistema RBAC
•
testing dell’applicazione
Per l’installazione dei DBMS si rimanda alla chiara e completa documentazione
ufficiale di MySQL [95]e PostgreSQL [96].
La creazione e la popolazione del database sono state effettuate utilizzando i file
di configurazione con estensione “.sql”, di cui si è parlato nel capitolo precedente,
ed il tool amministrativo RBACAdmin, anch’esso descritto nel capitolo
precedente. Sono stati inseriti utenti, permessi e ruoli in numero sufficiente per
Pagina 173
realizzare gerarchie tra questi ultimi ed imporre tutti i possibili vincoli supportati
dal modello RBAC esteso.
Anche per quanto concerne l’installazione di Tomcat si rimanda alla
documentazione del sito ufficiale [94].
L’applicazione di test è stata realizzata scrivendo alcune semplici pagine JSP
(vedi capitolo 8), che mostravano solamente il nome dell’utente che le aveva
accedute tramite un’operazione di “get” o di “post”. Queste pagine sono state
distribuite in fase di deployment in diverse locazioni, alcune pubbliche, altre
accessibili solo da certi utenti autenticati (file “tomcat-users.xml” - vedi paragrafo
9.4.1). In questo modo è stato possibile definire i permessi nel seguente modo:
•
oggetto = url della pagina jsp
•
operazione = get o post
Si rimanda al capitolo precedente per la descrizione dettagliata della
configurazione del sistema RBAC. Infine per quanto riguarda il deployment di
quest’ultimo è sufficiente copiare i files “.class” nella sottodirectory “classes”
della directory “WEB-INF” dell’applicazione di test e configurare correttamente il
file “web.xml”, anch’esso contentuo in questa directory, come illustrato nel
capitolo precedente.
Completate tutte queste operazioni preliminari, è stato effettuato, a seguito di
un’attenta ispezione del codice, un testing funzionale basato sui casi d’uso
dell’applicazione, verificando per ognuno di questi ultimi il corretto
funzionamento del sistema di controllo d’accesso.
Poiché i vincoli di cui testare il funzionamento sono divisi in statici e dinamici, si
è scelta la stessa classificazione anche per i casi d’uso. Una suddivisione ulteriore
è stata fatta per package, in modo da testare incrementalmente il sistema,
aggiungendo di volta in volta nuove funzionalità.
I prossimi paragrafi riportano un elenco dei casi d’uso testati.
10.1.1
Motore statico: Casi d’uso
1. Core RBAC
a. Creazione sessione: il sistema crea la sessione ed attiva gli
eventuali ruoli di default.
Pagina 174
b. Richiesta di un permesso regolare: il sistema autorizza l’utente.
c. Richiesta di un permesso non regolare: il sistema non autorizza
l’utente.
d. Distruzione sessione: vengono disattivati i ruoli attivi e viene
distrutta la sessione.
2. Hierarchical RBAC
a. Richiesta di un permesso appartenente ad un ruolo ereditato: il
sistema autorizza l’utente.
b. Richiesta di un permesso non assegnato o ereditato dall’utente: il
sistema non autorizza l’utente.
3. DSD RBAC
a. Creazione di una sessione in cui i ruoli di default violano i vincoli
DSD: la sessione viene creata senza attivare tutti i ruoli di default.
b. Creazione di una sessione in cui i ruoli di default non violano i
vincoli DSD: la sessione viene creata attivando tutti i ruoli di
default.
c. Attivazione di un ruolo che viola i vincoli DSD: il sistema non
autorizza l’utente.
d. Attivazione di un ruolo che non viola i vincoli DSD: il sistema
autorizza l’utente.
4. Time RBAC
a. Richiesta di un permesso attivabile: il sistema autorizza l’utente.
b. Richiesta di un permesso non attivabile il sistema non autorizza
l’utente.
5. Cancellazioni
a. Eliminazione di un utente
i. L’utente prova ad usare un permesso di un ruolo già attivo:
il sistema non autorizza l’utente.
ii. L’utente prova ad attivare un ruolo: il sistema non autorizza
l’utente.
iii. L’utente prova a creare una sessione: il sistema non
autorizza l’utente.
Pagina 175
iv. L’utente prova a terminare una sessione: la sessione viene
terminata
b. Eliminazione di un ruolo
i. L’utente prova ad usare un permesso del ruolo eliminato,
che però aveva già attivato: il sistema non autorizza
l’utente.
ii. L’utente prova ad attivare il ruolo eliminato: il sistema non
autorizza l’utente.
iii. L’utente prova ad disattivare il ruolo eliminato: il ruolo
viene disattivato.
iv. L’utente prova a creare una sessione in cui il ruolo
eliminato è di default: la sessione viene creata, ma il ruolo
non viene attivato.
c. Eliminazione di un permesso
i. L’utente prova ad utilizzare il permesso: il sistema non
autorizza l’utente.
d. Eliminazione dell’assegnamento di un utente ad un ruolo
i. L’utente prova ad usare un permesso del ruolo non più
assegnatogli, che però aveva già attivato: il sistema non
autorizza l’utente.
ii. L’utente prova ad attivare il ruolo che gli è stato tolto: il
sistema non autorizza l’utente.
iii. L’utente prova ad disattivare il ruolo che gli è stato tolto,
ma che aveva attivo: il ruolo viene disattivato
iv. L’utente prova a creare una sessione in cui il ruolo non più
assegnatogli è di default: la sessione viene creata, ma il
ruolo non viene attivato.
e. Eliminazione dell’assegnazione di un permesso ad un ruolo
i. L’utente prova ad utilizzare il permesso che gli è stato tolto:
il sistema non autorizza l’utente.
Pagina 176
10.1.2
Motore Statico: Casi d’uso
1. Core RBAC
a. Aggiunta di un ruolo di default non assegnato all’utente: il sistema
segnala l’errore all’amministratore.
b. Aggiunta di un ruolo di default precedentemente assegnato
all’utente: il sistema autorizza l’operazione.
2. Hierarchical RBAC
a. Aggiunta di un ruolo di default ereditato dall’utente: il sistema
autorizza l’operazione.
b. Aggiunta di un ruolo di default non ereditato dall’utente: il sistema
segnala l’errore all’amministratore.
3. Limited RBAC
a. Aggiunta di una relazione di ereditarietà consentita: il sistema
autorizza l’operazione.
b. Aggiunta di una relazione di ereditarietà non consentita: il sistema
segnala l’errore all’amministratore.
4. SSD RBAC
a. Assegnazione ad un utente di un ruolo che è in conflitto con uno
già assegnatogli: il sistema segnala l’errore all’amministratore.
b. Assegnazione ad un utente di un ruolo che non è in conflitto con i
ruoli già assegnatigli: il sistema segnala l’errore all’amministratore.
10.1.3
Risultati
Il testing si è rivelato molto utile nel rivelare alcuni bug nell’implementazione,
che difficilmente sarebbero stati scoperti con la sola ispezione del codice.
Al termine della fase di revisione l’applicazione si è dimostrata affidabile e
funzionante in tutte le sue componenti, descritte nei paragrafi precedenti.
Pagina 177
10.2 Considerazioni finali
In conclusione è possibile affermare che gli obiettivi stabiliti all’inizio della tesi
sono stati pienamente raggiunti. In particolare sono stati conseguiti i seguenti
risultati:
•
L’analisi dei modelli di controllo d’accesso basato su ruoli elaborati nel
corso di questo ultimo decennio ha portato all’elaborazione di un modello
RBAC esteso con la caratteristica originale dell’attivazione dei permessi
(vedi capitolo 7), che permette di supportare un numero maggiore di
vincoli, la cui necessità è stata segnalata in letteratura.
•
Si può ritenere un utile contributo anche la tassonomia proposta nel
capitolo 6, in quanto mette ordine e classifica chiaramente i controlli che si
possono effettuare, ponendo l’attenzione sia sul target del vincolo, che
sull’istante temporale in cui esso deve essere verificato.
•
Per quanto riguarda invece l’implementazione, si è in primo luogo
raggiunto l’obiettivo primario di aggiungere una nuova funzionalità di
controllo d’acceso alle tecnologie J2EE, della quale si sentiva la
mancanza. Ne sono la testimonianza numerosi articoli e forum di
discussione nei siti specializzati, dei quali si può trovare un esempio al
link: http://forum.java.sun.com/thread.jspa?threadID=568069&tstart=240.
Il risultato è però ancor più generale, in quanto si è realizzato un sistema di
controllo d’accesso basato su ruoli utilizzabile in qualsiasi contesto
applicativo tramite l’implementazione di semplici plug-in, simili a quello
illustrato nel capitolo 9.
•
Infine si è realizzata un’applicazione:
o Modulare: è possibile scegliere se utilizzare solo il CoreRBAC,
oppure anche le funzionalità degli altri modelli (Hierarchical, SSD,
DSD, Time).
o Facilmente espandibile: è possibile implementare nuovi vincoli
ed integrarli nel sistema.
Pagina 178
o Adattabile a più contesti applicativi: è possibile sfruttare il
sistema RBAC per effettuare il controllo d’accesso non solo in
ambito J2EE.
o Semplice da configurare: il formato dei vincoli è immediatamente
comprensibile e perfettamente aderente al modello concettuale;
inoltre i tool amministrativi visuali facilitano notevolmente il
lavoro dell’amministratore.
Prima di discutere circa i possibili sviluppi futuri dell’applicativo realizzato, si
vuole dare un’ulteriore riscontro dell’attualità del tema oggetto della presente
trattazione e di come esso sia al centro di grandi interessi non solo a livello
accademico, ma anche applicativo.
10.3 L’attualità del tema
Il crescente interesse per il controllo d’accesso basato su ruoli è principalmente
dovuto al fatto che le aziende si trovano ad avere sempre maggiori responsabilità
legali, in concomitanza alla crescita delle minacce informatiche ed alla diffusione
delle tecniche per la gestione delle identità.
Nel novembre del 2004 la Unisys (società che fornisce servizi e soluzioni di IT in
tutto il mondo) ha reso noti i risultati di uno studio che delinea le principali
tendenze in ambito security (sicurezza informatica) nel 2005. Le previsioni
indicano che le aziende dovranno affrontare importanti sfide e rilevanti
investimenti in soluzioni di sicurezza per gestire le problematiche derivanti dalla
crescente fiducia nelle reti integrate che le collegano con clienti e partner
commerciali, dalla diffusione di tecnologie mobili e connettività wireless, dalle
nuove minacce e tentativi di attacco da parte di cyberterroristi e cybercriminali
verso le realtà aziendali ed i governi.
Lo studio Unisys mette in risalto il fatto che la sicurezza oggi è soprattutto una
questione di business. Infatti investire in soluzioni e servizi di security significa
ottimizzare i processi associati all'impiego del patrimonio informativo aziendale
per poterne pianificare la crescita e al contempo gestire i rischi che potrebbero
minare l’immagine dell'azienda.
Pagina 179
Nei prossimi anni si potrà assistere a importanti sfide che avranno un impatto
rilevante in termini legali, economici e tecnologici. Le aziende saranno chiamate
come mai prima d'ora a investire in sicurezza in maniera focalizzata, strategica e
pervasiva. Questo onere sarà necessario per qualunque organizzazione che voglia
diventare ciò che si definisce una “trusted enterprise”, ovvero una realtà nella
quale il “risk management” è parte della strategia business, al fine di creare un
ambiente sicuro che consenta la collaborazione ottimale con partner e clienti.
La tecnica RBAC (Role-Based Access Control) consente l’accesso agli utenti a
determinate applicazioni sulla base della loro funzione professionale anziché
dell’identità personale. Questo sistema può eliminare le complesse modifiche
necessarie quando i diritti di accesso vengono collegati direttamente agli utenti
individuali. L'adozione della tecnica RBAC si è diffusa lentamente a causa della
difficoltà e dei costi legati alla definizione dei ruoli a livello aziendale. In
un'organizzazione con 40.000 dipendenti e svariati sistemi, per esempio,
potrebbero servire anche 12 mesi per definire questi ruoli; tuttavia, associare
40.000 persone a 2.500 ruoli ridurrebbe enormemente il lavoro richiesto per
fornire e gestire gli accessi. Nuove tecnologie permetteranno di ottenere più
rapidamente i vantaggi del sistema RBAC, in particolare una superiore efficienza
operativa e costi inferiori. Uno studio Unisys dedicato alla gestione dell’identità e
degli accessi (IAM - Identity and Access Management) indica un'accelerazione
dell'adozione dei meccanismi RBAC: il 32% degli interpellati ha dichiarato di
essere intenzionato a implementare la tecnica RBAC nel 2005.
Condotto all’inizio del mese di ottobre 2004, lo studio, effettuato da KRC
Research, ha coinvolto 150 responsabili IT di grandi aziende degli Stati Uniti (con
un fatturato annuo di oltre 500 milioni di dollari). Per una copia dei risultati della
ricerca,
è
possibile
visitare
il
sito
Web
di
Unisys
all'indirizzo
“http://www.app1.unisys.com/common/iam/registration.asp”.
Pagina 180
10.4
Sviluppi futuri
Sicuramente il lavoro svolto nell’ambito della tesi rappresenta un punto di
partenza e non un punto di arrivo per lo sviluppo di tecniche RBAC sempre più
sicure ed efficienti. Gli ambiti di ricerca sono dunque numerosi.
Per quanto riguarda gli sviluppi futuri in relazione al modello RBAC si possono
individuare tre filoni principali:
1. il primo è volto alla classificazione e alla standardizzazione del formato
dei vincoli che un sistema RBAC deve supportare;
2. il secondo ha come scopo l’individuazione di un modello amministrativo
distribuito, applicabile alle grandi realtà organizzative, nelle quali non è
concepibile che un’unica figura professionale possa gestire l’intero sistema
informativo aziendale;
3. il terzo ed ultimo filone si preoccupa dell’integrazione del modello RBAC
con altri modelli di controllo d’accesso per creare un sistema ancora più
completo e sicuro.
Per quanto concerne l’applicativo sviluppato, è sicuramente possibile apportare
numerose migliorie a diversi livelli:
1. in primo luogo è possibile implementare tutti i diversi vincoli definiti nella
tassonomia proposta;
2. in secondo luogo è senz’altro utile implementare funzioni grafiche evolute
per i tool amministrativi, come ad esempio funzionalità “drag & drop” e
visualizzazione schematica dei ruoli e della loro gerarchia;
3. infine è possibile realizzare numerosi altri plug-in per integrare
l’applicativo in numerosi altri sistemi e dotarli delle funzionalità del
controllo d’accesso basato su ruoli.
Infine un’ultima verifica delle potenzialità del software implementato sarebbe la
“prova sul campo”, ovvero l’installazione dello stesso in un sistema realmente
utilizzato per la gestione del controllo d’accesso in un’organizzazione di medie o
grandi dimensioni.
Pagina 181
Indice delle figure
Figura 2-1. Il reference monitor ............................................................................ 29
Figura 2-2. Il security kernel................................................................................. 30
Figura 2-3. Utente VS Soggetto............................................................................ 32
Figura 2-4. Tripla di controllo d’accesso secondo Clark e Wilson...................... 35
Figura 3-1. Relazioni tra utenti, ruoli, transazioni ed oggetti di sistema .............. 41
Figura 3-2. Gerarchia di ruoli ............................................................................... 42
Figura 3-3. Esempio di gerarchia tra ruoli ............................................................ 43
Figura 4-1. RBAC96 Framework.......................................................................... 51
Figura 4-2. Esempi di gerarchia di ruoli ............................................................... 53
Figura 4-3. Gerarchie di complessità crescente .................................................... 54
Figura 4-4. RBAC 3: unione dei modelli RBAC 0, 1, 2 ....................................... 56
Figura 5-1. Gerarchia ad albero ............................................................................ 63
Figura 5-2. Gerarchia ad albero invertito.............................................................. 63
Figura 5-3. Gerarchia a reticolo ............................................................................ 63
Figura 5-4. Core RBAC ........................................................................................ 68
Figura 5-5. Hierarchical RBAC ............................................................................ 70
Figura 5-6. Constrained RBAC: SSD ................................................................... 71
Figura 5-7. Constrained RBAC: DSD................................................................... 72
Figura 5-8. Packages dello standard RBAC.......................................................... 80
Figura 6-1. Interpretazione standard dei permessi RBAC ................................... 91
Figura 6-2. Modello dei permessi RBAC modificato ........................................... 91
Figura 6-3. Esempio di mutua esclusione tra cinque diversi ruoli...................... 105
Figura 6-4. Esempio di utilizzo di blacklist ........................................................ 107
Figura 7-1. Modello RBAC del NIST................................................................. 110
Figura 7-2. Architettura statica dello standard NIST .......................................... 111
Figura 7-3. Architettura statica del modello proposto ........................................ 112
Figura 7-4. Architettura dinamica dello standard NIST...................................... 112
Figura 7-5. Architettura dinamica del modello proposto .................................... 113
Figura 7-6. Variante della parte dinamica del modello....................................... 114
Pagina 182
Figura 8-1. L’architettura J2EE .......................................................................... 124
Figura 8-2. Componenti, contenitori e connettori............................................... 125
Figura 8-3. Esempio di applicazione enterprise multi-tier.................................. 128
Figura 8-4. Esempio di applicazione enterprise multi-tier.................................. 128
Figura 8-5. Funzionamento del business-tier ...................................................... 131
Figura 8-6. Modello del commercio elettronico ................................................. 132
Figura 8-7. Driver JDBC di tipo 3 e 4................................................................. 134
Figura 8-8. Driver JDBC di tipo 1 e 2................................................................. 135
Figura 8-9. Il package javax.servlet .................................................................... 138
Figura 8-10. Il package javax.servlet.http........................................................... 139
Figura 9-1. Architettura del sistema.................................................................... 153
Figura 9-2. Dettaglio architettura........................................................................ 157
Figura 9-3. Estratto del file "web.xml" ............................................................... 159
Figura 9-4. Catena di chiamate ........................................................................... 160
Figura 9-5. Diagramma UML delle classi del motore statico............................. 161
Figura 9-6. Diagramma UML delle classi del motore dinamico ........................ 162
Figura 9-7. Diagramma UML delle classi di gestore e monitor delle sessioni ... 164
Figura 9-8. File di configurazione "hierarchy.properties" .................................. 166
Figura 9-9. RBACAdmin tool: assegnazione di un ruolo ad un utente .............. 168
Figura 9-10. RBACAdmin tool: violazione di un vincolo SSD ......................... 169
Figura 9-11. RBACSessionsMonitor .................................................................. 170
Figura 9-12. File di configurazione “rbac.properties” ........................................ 170
Figura 9-13. File di configurazione “postgre.properties” ................................... 171
Pagina 183
Indice delle tabelle
Tabella 1-1. Piano di lavoro .................................................................................. 22
Tabella 2-1. Esempio di matrice di controllo d'accesso di Lampson.................... 28
Tabella 5-1. Funzioni e packages dello standard RBAC ...................................... 82
Tabella 6-1. Categorie di vincoli e dimensione temporale ................................. 100
Tabella 7-1. Corrispondenze tra architettura statica e dinamica ......................... 114
Tabella 8-1. Classificazione API JDBC.............................................................. 133
Tabella 9-1. Implementazione delle interfacce ................................................... 156
Tabella 9-2. Controlli vincoli dinamici............................................................... 163
Tabella 10-1. Configurazioni di Testing ............................................................. 173
Pagina 184
Bibliografia e Riferimenti
L’indice bibliografico seguente non è stato interamente utilizzato nell’ambito
della tesi, in quanto lo studio di tutti i documenti elencati avrebbe richiesto di per
sé un tempo maggiore di quello che si aveva a disposizione per portare a termine
l’intero lavoro. È stato redatto tenendo traccia di tutti i principali riferimenti, che
si sono incontrati durante l’attività di ricerca, allo scopo di creare una sorta di
biblioteca virtuale sul controllo d’accesso in generale e più in particolare su quello
basato su ruoli. L’intento è dunque quello di fornire una valida indicazione per chi
volesse approfondire i diversi temi trattati in modo più o meno approfondito nella
presente relazione.
[1] DoD National Computer Security Center, Department of Defense Trusted
Computer Systems Evaluation Criteria (Orange Book), December 1985,
DoD 5200.28-STD.
[2] Lampson, B. W., "Dynamic Protection Structures," AFIPS Conference
Proceedings, 35, 1969, pp. 27–38.
[3] Ware, W. H., Security Controls for Computer Systems (U): Report of
Defense Science Board Task Force on Computer Security, Santa Monica,
CA: The RAND Corporation, February 1970.
[4] Anderson, J. P., Computer Security Technology Planning Study Volume
II,ESD-TR-73-51, Electronic Systems Division, Air Force Systems
Command, Hanscom Field, Bedford, MA, 01730, October 1972.
[5] Bell, D. E., and L. J. LaPadula, Secure Computer Systems: Mathematical
Foundations and Model, Bedford, MA: The Mitre Corporation, 1973. See
also D. E. Bell and L. J. LaPadula, Secure Computer System: Unified
Exposition and MULTICS Interpretation, MTR-2997 Rev. 1, Bedford,
MA: The MITRE Corporation, March 1976, and ESD-TR-75-306, rev. 1,
Electronic Systems Division, Air Force Systems Command, Hanscom
Field, Bedford, MA 01731.
Pagina 185
[6] Harrison, M., W. Ruzzo, and J. Ullman, Protection in Operating Systems,
CACM 19, No. 8, August 1976, pp. 461–471.
[7] Clark, D. D., and D. R. Wilson, "A Comparison of Commercial and
Military Computer Security Policies," IEEE Symposium of Security and
Privacy, 1987, pp. 184–194.
[8] Dobson, J. E., and J. A. McDermid, "Security Models and Enterprise
Models," in Database Security II: Status & Prospects, C. E. Landwehr
(ed.), North Holland, 1989, pp. 1–39.
[9] Baldwin, R. W., "Naming and Grouping Privileges To Simplify Security
Management in Large Database," in Proceedings IEEE Computer Society
Symposium on Research in Security and Privacy, April 1990, pp. 184–
194.
[10]
Thomsen, D. J., "Role-Based Application Design and
Enforcement," in Database Security, IV: Status and Prospects, S. Jajodia
and C. E. Landwehr (eds.), North Holland, 1991, pp. 151–168.
[11]
Brewer, D. F. C., and M. J. Nash, "The Chinese Wall Security
Policy," Proceedings IEEE Computer Society Symposium on Research in
Security and Privacy,April 1989, pp. 215–228.
[12]
Nash, M., and K. Poland, "Some Conundrums Concerning
Separation of Duty," presented at the IEEE Symposium on Security and
Privacy, Oakland, CA, 1990.
[13]
Ferraiolo, D., D. Gilbert, and N. Lynch, "An Examination of
Federal and Commercial Access Control Policy Needs," in Proceedings of
the NIST-NSA National (USA) Computer Security Conference, 1993, pp.
107–116.
[14]
Ferraiolo, D., and D. R. Kuhn, "Role-Based Access Control," in
Proceedings of the NIST-NSA National (USA) Computer Security
Conference, 1992, pp. 554–563.
[15]
Ferraiolo, D. F., J. Cugini, and D. R. Kuhn, "Role-Based Access
Control (RBAC): Features and Motivations," in Proceedings of the 11th
Annual Computer Security Application Conference, New Orleans, LA,
December 11–15 1995, pp. 241–248.
Pagina 186
[16]
Sandhu, R. S., et al., "Role-Based Access Control: A
Multidimensional View," Proceedings of the 10th Annual Computer
Security Applications Conference, December 1994, pp. 54–62.
[17]
Nyanchama, M., and S. L. Osborn, "Access Rights Administration
in Role-Based Security Systems," Proceedings of the IFIP WG11.3
Working Conference on Database Security, 1994. See also M. Nyanchama
and S. L. Osborn, "The Role Graph Model and Conflict of Interest," ACM
Transactions on Information and System Security (TISSEC), Vol. 2, No.
1, February 1999, pp. 3–33.
[18]
Deinhart, K., et al., "Method and System for Advanced Role-Based
Access Control in Distributed and Centralized Computer Systems," U.S.
Patent 5,911,143, June 8, 1999.
[19]
Sandhu, R., et. al., "Role-Based Access Control Models," IEEE
COmputer, Vol. 29, No. 2, February 1996.
[20]
Barkley, J. F., "Application Engineering in Health Care," Second
Annual CHIN Summit, June 9, 1995.
[21]
Barkley, J. F., and A. V. Cincotta. "Implementation of Role/Group
Permission Association Using Object Access Type," U.S. Patent
6,202,066, 2002.
[22]
Bertino, E., E. Ferrari, and V. Atluri, "A Flexible Model for the
Specification and Enforcement of Authorizations in Workflow
Management Systems," 2nd ACM Workshop on Role-Based Access
Control, November 1997.
[23]
Sandhu, R., D. Ferraiolo, and R. Kuhn, "The NIST Model for Role-
Based Access Control: Towards a Unified Standard," Proc. 5th ACM
Workshop on Role-Based Access Control, July 26–27, 2000.
[24]
U.S. Health Insurance Portability and Accountability Act of 1996
(HIPAA)
[25]
Federal Aviation Administration, National Airspace System (NAS)
Protection Profile Template Supplement, Version 1.0.
[26]
Joshi, J., et al., "Digital Government Security Infrastructure Design
Challenges," IEEE Computer, 33(2), February 2001, pp. 66–72.
Pagina 187
[27]
Joshi, J. B. D., et al., "Security Models for Web-Based
Applications," Communications of the ACM, 44(2), February 2001, pp.
38–44.
[28]
Ferraiolo, D. F., J. F. Barkley, and D. R. Kuhn, "A Role-Based
Access Control Model and Reference Implementation Within a Corporate
Intranet," ACM Transactions on Information and System Security
(TISSEC), Vol. 2, No. 1, February 1999, pp. 34–64.
[29]
Park, J. S., and R. Sandhu, "RBAC on the Web by Smart
Certificates," Proc. ACM Workshop on Role-Based Access Control 1999:
1–9, New York: ACM Press.
[30]
Daniels, J., "This is Not a Game: The Weakest Link," SANS
Institute, August 9, 2001.
[31]
Messmer, E., "Role-Based Access Control on a Roll," Network
World, July 30, 2001
[32]
Anderson, J. P., Computer Security Technology Planning Study,
Volume II, ESD-TR-73-51, Electronic Systems Division, Air Force
Systems Command, Hanscom Field, Bedford, MA, 01730 (October 1972).
[33]
DoD National Computer Security Center, Department of Defense
Trusted Computer Systems Evaluation Criteria, December 1985, DoD
5200.28-STD.
[34]
Lampson, B., "Protection," ACM Operating Sys. Reviews, 8(1),
1974, pp. 18–24.
[35]
Bell, D. E., and L. J. LaPadula, Secure Computer Systems:
Mathematical Foundations and Model, Bedford, MA: The Mitre
Corporation, 1973. See also D. E. Bell and L. J. LaPadula, Secure
Computer System: Unified Exposition and MULTICS Interpretation,
MTR-2997 Rev. 1, Bedford, MA: The MITRE Corporation, March 1976;
also ESD-TR-75-306, rev. 1, Electronic Systems Division, Air Force
Systems Command, Hanscom Field, Bedford, MA, 01731.
[36]
Biba, K. J., Integrity Considerations for Secure Computer Systems,
Bedford, MA: The MITRE Corporation, 1977.
Pagina 188
[37]
Clark, D. D., and D. R. Wilson "A Comparison of Commercial and
Military Computer Security Policies," IEEE Symposium of Security and
Privacy, 1987, pp. 184–194.
[38]
Brewer, D., and M. Nash, "The Chinese Wall Security Policy,"
Proc. IEEE Computer Society Symposium on Research in Security and
Privacy, April 1989, pp. 215–228.
[39]
Badger, L., et al., "A Domain and Type Enforcement Prototype,"
Usenix Computing Systems, Volume 9, Cambridge, MA, 1996.
[40]
Boebert, W., and R. Kain, "A Practical Alternative to Hierarchical
Integrity Policies," Proceedings of the 8th National Computer Security
Conference, October 1985.
[41]
Ostendorp, K. A., et al., "Domain and Type Enforcement
Firewalls," DARPA Information Survivability Conference and Exposition,
2000, DISCEX ‘00, Vol. 1, 1999, pp. 351–361.
[42]
Tidswell, J., and J. Potter, An Approach to Dynamic Domain and
Type Enforcement, Microsoft Research Institute, Department of
Computing, Macquarie University, NSW, Australia, 2000.
[43]
Hoffman, J., "Implementing RBAC on a Type-Enforced system,"
Proceedings of the 13th Annual Computer Security Applications
Conference, December 1997.
[44]
Ferraiolo, D., and R. Kuhn, "Role-Based Access Control," Proc. of
the NIST-NSA Nat. (USA) Comp. Security Conf., 1992, pp. 554–563.
[45]
Ferraiolo, D., J. Cugini, and R. Kuhn. "Role-Based Access Control:
Features and Motivations," Proc. of the Annual Computer Security
Applications Conf., New Orleans: IEEE Press, 1995.
[46]
Sandhu, R., et al., "Role-Based Access Control Models," IEEE
Computer, 29(2), February 1996.
[47]
Baldwin, R. W., "Naming and Grouping Privileges To Simplify
Security Management in Large Databases," Proceedings of the IEEE
Computer Society Symposium on Research in Security and Privacy, April
1990, pp. 184–194.
Pagina 189
[48]
Nyanchama, M., and S. L. Osborn, "Access Rights Administration
in Role-Based Security Systems," Proceedings of the IFIP WG11.3
Working Conference on Database Security, 1994. See also Nyanchama,
M., and S. L. Osborn, "The Role Graph Model and Conflict of Interest,"
ACM Transactions on Information and System Security (TISSEC), Vol. 2,
No. 1, February 1999, pp. 3–33.
[49]
Moffett, J. D., and E. C. Lupu, "The Uses of Role Hierarchies in
Access Control," "Proc. of the 4th ACM Workshop on Role-Based Access
Control", 1999, pp. 153–160.
[50]
McRae, R., The Stanford Model for Access Control
Administration, Stanford University, 2000 (unpublished).
[51]
Proctor, K., "Why All Banks Should Practice Risk Management,"
Hoosier Banker, April 2001.
[52]
Griffin, R. J., Statement of the Honorable Richard J. Griffin,
Inspector General, Department of Veterans Affairs, Before the United
States House of Representatives Committee on Veterans Affairs,
Subcommittee on Oversight and Investigations Hearing on Fraud and
Mismanagement in VA, September 23, 1999.
[53]
Simon, R. T., and M. E. Zurko, "Separation of Duty in Role Based
Environments," Proc. Computer Security Foundations Workshop X,
Rockport, MA, June 1997.
[54]
Moffett, J., and M. Sloman, "Policy Conflict Analysis in
Distributed Systems Management," Journal of Organizational Computing,
Vol. 4, No. 1, (1994), pp. 1–22.
[55]
Kuhn, D. R., "Mutual Exclusion of Roles as a Means of
Implementing Separation of Duty in Role-Based Access Control Systems,"
Proceedings 2nd ACM Workshop on Role-Based Access Control, Fairfax,
VA, 1997. pp. 23–30.
[56]
Giuri, L., and P. Iglio, "A Formal Model for Role-Based Access
Control with Constraints," Proc. of the Computer Security Foundations
Workshop, Piscataway, NJ: IEEE Press, 1996, pp. 136–145.
Pagina 190
[57]
Gligor, V., S. I. Gavrilla, and D. F. Ferraiolo, "On the Formal
Definition of Separation of Duty Policies and Their Composition,"
Proceedings IEEE Symposium on Security and Privacy, May 1998, pp.
172–183.
[58]
Ahn, G. J., and R. Sandhu, "The RSL99 Language for Role-Based
Separation of Duty Constraints," Proceedings of the Fourth ACM
Workshop on Role-Based Access Control, October 28–29, 1999, Fairfax,
Virginia, pp. 43–54.
[59]
Ahn, G. J., and R. Sandhu, "Role-Based Authorization Constraints
Specification," ACM Transactions on Information and System Security
(TISSEC), Vol. 3, No. 4, November 2000.
[60]
Tidswell, J. E., and T. Jaeger, "Integrated Constraints and
Inheritance in DTAC," Proceedings of the Fifth ACM Workshop on RoleBased Access Control, July 26–28, 2000, Berlin, Germany, pp. 93–102.
[61]
Schaad, A., and J. D. Moffett, "The Incorporation of Control
Policies into Access Control Policies," Policy 2001: Workshop on Policies
for Distributed Systems and Networks, Bristol, United Kingdom.
[62]
Botha, R. A., and J. H. P. Eloff, "Separation of Duties for Access
Control Enforcement in Workflow Environments," IBM Systems Journal,
Vol. 40, No. 3, 2001.
[63]
Hunton, J. E., and T. L. Jones, "Recreation, Inc., An Information
Technology Risk Assessment Case Study of Enterprise Resource Planning
(ERP) Systems," AICPA Case Development Program, Case No. 2000-02,
American Institute of Certified Public Accountants, 2000.
[64]
Ferraiolo, D., J. Cugini, and R. Kuhn, "Role-Based Access Control:
Features and Motivations," Proc. of the Annual Computer Security
Applications Conf., Piscataway, NJ: IEEE Press, 1995.
[65]
Sandhu, R., "Transaction Control Expressions For Separation Of
Duties," Proc. 4th Aerospace Computer Security Applications Conference,
Orlando, FL, December 1988, pp. 282–286.
Pagina 191
[66]
Nash, M. J., and K. R. Poland, "Some Conundrums Concerning
Separation of Duty," Proceedings 1990 IEEE Symposium on Security and
Privacy, May 1990, pp. 201–207.
[67]
Cholewka, D. G., R. H. Botha, and J. H. P. Eloff, "A Context-
Sensitive Access Control Model and Prototype Implementation,"
Proceedings of the IFIP TC11 15th International Conference on
Information Security, Beijing, China (2000), pp. 341–350, 2000.
[68]
Georgiadis, C. K., et al., Flexible "Team-Based Access Control
Using Contexts," Proceedings of ACM RBAC97, 1997.
[69]
Kumar, A., N. Karnik, and G. Chafle, "Context Sensitivity in Role-
Based Access," ACM SIGOPS Operating Systems Review, Vol. 36, Issue 3
(July 2002), pp. 53–66
[70]
Papenfus, C., and R. Botha, "An XML-Based Approach to
Enforcing History Based Separation of Duty Policies in Heterogeneous
Workflow Environments," SACJ/SART, No. 26, 2000, pp. 60–68.
[71]
Chandramouli, R., and R. Sandhu, "Role-Based Access Control
Features in Commercial Database Management Systems," 21st National
Information Systems Security Conference, October 6–9, 1998, Crystal
City, Virginia.
[72]
Crampton, J., and G. Loizou, "Authorization and Antichains,"
Operating Systems Review, 35(3), 6–15, 2001.
[73]
Bertino, E., A. Bonatti, and E. Ferrari, "TRBAC: A Temporal Role-
Based Access Control Model," ACM Transactions on Information and
System Security, 4(4), pp. 65–104, September 2001.
[74]
Joshi, J. B., D. Bertino, and A. Ghafoor, "Temporal Hierarchies
and Inheritance Semantics for GTRBAC," Seventh ACM Symposium on
Access Control Models and Technologies, Monterey, CA, 2002.
[75]
Nyanchama, M., and S. L. Osborn, "Information Flow Analysis in
Role-Based Systems," Journal of Computing and Information, 1(1), May
1994, Special Issue: Proc. of the 6th International Conference on
Computing and Information (ICCI), Peterborough, Ontario, Canada.
Pagina 192
[76]
Sandhu, R., "Role Hierarchies and Constraints for Lattice-Based
Access Controls," Proc. of the Fourth European Symposium on Research
in Computer Security, Rome, Italy, September 25–27, 1996.
[77]
Osborn, S., R. Sandhu, and Q. Munawer, "Configuring Role-Based
Access Control To Enforce Mandatory and Discretionary Access Control
Policies," ACM Transactions on Information and System Security, Vol. 3,
No. 2, May 2002, pp. 85–106.
[78]
Ferraiolo, D. F., and V. Hu, The Policy Machine: A Policy Engine
and Language for Generalized Attribute-Based Access Control,
(unpublished) 2002.
[79]
Sandhu, R., and Q. Munawer, "How To Do Discretionary Access
Control Using Roles," Proc. of the 3rd ACM Workshop on Role-Based
Access Control (RBAC-98), Fairfax, VA, October 1998, ACM Press.
[80]
Kuhn, D. R., "Role-Based Access Control on MLS Systems
Without Kernel Changes," Proceedings ACM Workshop on Role-Based
Access Control, 1998, pp. 25–32.
[81]
Osborn, S. L., "Mandatory Access Control and Role-Based Access
Control Revisited," Proceedings of the Second ACM Workshop on RoleBased Access Control, November 1997.
[82]
Meyers, W. J., "RBAC Emulation on Trusted DG/UX,"
Proceedings Second ACM Workshop on Role-Based Access Control,
1997.
[83]
Phillips, Jr., C. E., S. A. Demurjian, and T. C. Ting, "Towards
Information Assurance for Dynamic Coalitions," Proceedings 2002 IEEE
Workshop in Information Assurance, United States Military Academy,
West Point, New York, June 2002.
[84]
Khair M., I. Mavridis, and G. Pangalos, "Design of Secure
Distributed Medical Database System," in Database and Expert Systems
Applications (DEXA ‘98), August 1998.
[85]
Phillips, Jr., C. E., T. C. Ting, and S. A. Demurjian, "Mobile and
Cooperative Systems: Information Sharing and Security in Dynamic
Coalitions," Seventh ACM Symposium on Access Control Models and
Pagina 193
Technologies, June 2002. Also "Information Sharing and Security in
Dynamic Coalitions," University of Connecticut, Technical Report CSETR-02-1, 2002. National Institute of Standards and Technology, Proposed
Standard for Role-Based Access Control
[86]
Jason Crampton “On Permissions, Inheritance and Role
Hierarchies” Information Security Group Royal Holloway, University of
London – CCS 2003
[87]
J. B. D. Joshi, E. Bertino, U. Latif, and A. Ghafoor, "Generalized
Temporal Role-Based Access Control Model," IEEE transaction on
Knowledge and Data Engineering, Vol.17, No. 1, January 2002
[88]
R. Bhatti, J. B. D. Bertino, A. Ghafoor, “X-GTRBAC: An XML-
based Policy Specification Framework and Architecture for EnterpriseWide Access Control”, submitted to ACM Transactions on Information
and System Security, 2003
[89]
Jason Crampton “Constraints in Role-Based Access Control” 8th
ACM Symposium on Access Control Models and Technologies, 2-3 June
2003
[90]
eXstensible Access Control Markup language (XACML) version
2.0” OASIS Standard, 1 Feb 2005
[91]
CTC93 The Canadian Trusted Computer Product Evaluation
Criteria (CTCPEC) Version 3.0e. Canadian System Security Centre,
Communications Security Establishment, Government of Canada, January
1993.
[92]
ISO (International Organization for Standardization), sito internet:
http://www.iso.org/iso/en/ISOOnline.frontpage
[93]
CORBA (Common Object Request Broker Architecture), sito
internet: http://www.omg.org/corba
[94]
Jakarta-Tomcat, sito internet: http://jakarta.apache.org/tomcat/
[95]
MySQL, sito internet: http://www.mysql.com/
[96]
PostgreSQL, sito internet: http://www.postgresql.org/
Pagina 194
APPENDICE A
JavaDoc
DynamicConstraint
Overview Package Class Use Tree Deprecated Index Help
PREV CLASS NEXT CLASS
FRAMES
SUMMARY: NESTED | FIELD | CONSTR | METHOD
DETAIL: FIELD | CONSTR | METHOD
NO FRAMES
All Classes
it.unibs.carlotti.rbac.core
Interface DynamicConstraint
All Superinterfaces:
EngineComponent
All Known Implementing Classes:
RBACDSD, RBACHierarchyDynamic, RBACTime
public interface DynamicConstraint
extends EngineComponent
Questa interfaccia definisce i metodi che devono essere implementati dai vincoli dinamici del
modello
Author:
Giacomo Carlotti
Method Summary
Methods inherited from interface it.unibs.carlotti.rbac.core.EngineComponent
activatePermission, addActiveRole, checkAccess, createSession,
deleteSession, dropActiveRole
Overview Package Class Use Tree Deprecated Index Help
PREV CLASS NEXT CLASS
FRAMES
SUMMARY: NESTED | FIELD | CONSTR | METHOD
DETAIL: FIELD | CONSTR | METHOD
NO FRAMES
All Classes
EngineComponent
Overview Package Class Use Tree Deprecated Index Help
PREV CLASS NEXT CLASS
FRAMES
SUMMARY: NESTED | FIELD | CONSTR | METHOD
DETAIL: FIELD | CONSTR | METHOD
NO FRAMES
All Classes
it.unibs.carlotti.rbac.core
Interface EngineComponent
All Known Subinterfaces:
DynamicConstraint
All Known Implementing Classes:
RBACCoreDynamic, RBACDSD, RBACEngine, RBACHierarchyDynamic, RBACTime
public interface EngineComponent
Questa interfaccia definisce i metodi che devono essere implementati dai componenti del motore che
controlla i vincoli dinamici
Author:
Giacomo Carlotti
Method Summary
boolean activatePermission(java.lang.String roleName, java.lang.
String permissionName, java.lang.Object obj)
Attiva un permesso verificando eventuali vincoli
boolean addActiveRole(java.lang.String roleName, java.lang.
String idSession)
attiva un ruolo per una sessione utente, verificando gli eventuali vincoli
boolean checkAccess(java.lang.String userName, java.lang.
String objectName, java.lang.String operation, java.lang.
String idSession, java.lang.Object obj)
controlla la disponibilità di un permesso per un certo utente e cerca di attivare un
ruolo a cui il permesso è associato
EngineComponent
void createSession(java.lang.String id, java.lang.
String userName)
crea una nuova sessione utente ed prova ad attivare i ruoli di default
void deleteSession(java.lang.String id)
disattiva i ruoli della sessione e la elimina
boolean dropActiveRole(java.lang.String roleName, java.lang.
String idSession)
disattiva un ruolo di una sessione utente
Method Detail
createSession
void createSession(java.lang.String id,
java.lang.String userName)
crea una nuova sessione utente ed prova ad attivare i ruoli di default
Parameters:
id - id della sessione
userName - nome dell'utente
deleteSession
void deleteSession(java.lang.String id)
disattiva i ruoli della sessione e la elimina
Parameters:
id - id della sessione
addActiveRole
boolean addActiveRole(java.lang.String roleName,
java.lang.String idSession)
EngineComponent
attiva un ruolo per una sessione utente, verificando gli eventuali vincoli
Parameters:
roleName - nome del ruolo
idSession - id della sessione
Returns:
true se riesce ad attivare il ruolo, false altrimenti
dropActiveRole
boolean dropActiveRole(java.lang.String roleName,
java.lang.String idSession)
disattiva un ruolo di una sessione utente
Parameters:
roleName - nome del ruolo
idSession - id della sessione
Returns:
true se riesce a disattivare il ruolo, false altrimenti
checkAccess
boolean checkAccess(java.lang.String
java.lang.String
java.lang.String
java.lang.String
java.lang.Object
userName,
objectName,
operation,
idSession,
obj)
controlla la disponibilità di un permesso per un certo utente e cerca di attivare un ruolo a cui il
permesso è associato
Parameters:
userName - nome del ruolo
objectName - nome dell'oggetto
operation - nome dell'operazione
idSession - id della sessione
obj - reference dell'oggetto
Returns:
true il processo di attivazione va a buon fine, false altrimenti
EngineComponent
activatePermission
boolean activatePermission(java.lang.String roleName,
java.lang.String permissionName,
java.lang.Object obj)
Attiva un permesso verificando eventuali vincoli
Parameters:
roleName - ruolo coinvolto nel vincolo
permissionName - permesso coinvolto nel vincolo
obj - reference all'ogggetto
Returns:
true il processo di attivazione va a buon fine, false altrimenti
Overview Package Class Use Tree Deprecated Index Help
PREV CLASS NEXT CLASS
FRAMES
SUMMARY: NESTED | FIELD | CONSTR | METHOD
DETAIL: FIELD | CONSTR | METHOD
NO FRAMES
All Classes
IntegrityComponent
Overview Package Class Use Tree Deprecated Index Help
PREV CLASS NEXT CLASS
FRAMES
SUMMARY: NESTED | FIELD | CONSTR | METHOD
DETAIL: FIELD | CONSTR | METHOD
NO FRAMES
All Classes
it.unibs.carlotti.rbac.core
Interface IntegrityComponent
All Known Subinterfaces:
StaticConstraint
All Known Implementing Classes:
RBACCoreStatic, RBACHierarchyStatic, RBACIntegrity, RBACLimitedHierarchy,
RBACSSD
public interface IntegrityComponent
Questa interfaccia definisce i metodi che devono esssere implementati dai componenti del motore che
controlla i vincoli statici
Author:
Giacomo Carlotti
Method Summary
void checkIntegrity()
Controlla i vincoli statici di integrità del sistema
Method Detail
checkIntegrity
void checkIntegrity()
throws java.lang.Throwable
Controlla i vincoli statici di integrità del sistema
IntegrityComponent
Throws:
java.lang.Throwable
Overview Package Class Use Tree Deprecated Index Help
PREV CLASS NEXT CLASS
FRAMES
SUMMARY: NESTED | FIELD | CONSTR | METHOD
DETAIL: FIELD | CONSTR | METHOD
NO FRAMES
All Classes
IntegrityException
Overview Package Class Use Tree Deprecated Index Help
PREV CLASS NEXT CLASS
FRAMES
SUMMARY: NESTED | FIELD | CONSTR | METHOD
DETAIL: FIELD | CONSTR | METHOD
NO FRAMES
All Classes
it.unibs.carlotti.rbac.core
Class IntegrityException
java.lang.Object
java.lang.Throwable
java.lang.Exception
it.unibs.carlotti.rbac.core.IntegrityException
All Implemented Interfaces:
java.io.Serializable
public class IntegrityException
extends java.lang.Exception
Questa classe rappresenta le eccezioni che possono essere lanciate durante il controllo dei vincoli
statici
Author:
Giacomo Carlotti
See Also:
Serialized Form
Constructor Summary
IntegrityException(java.lang.String arg0)
Costruttore
Method Summary
Methods inherited from class java.lang.Throwable
IntegrityException
fillInStackTrace, getCause, getLocalizedMessage, getMessage,
getStackTrace, initCause, printStackTrace, printStackTrace,
printStackTrace, setStackTrace, toString
Methods inherited from class java.lang.Object
clone, equals, finalize, getClass, hashCode, notify, notifyAll,
wait, wait, wait
Constructor Detail
IntegrityException
public IntegrityException(java.lang.String arg0)
Costruttore
Parameters:
arg0 - messaggio d'errore
Overview Package Class Use Tree Deprecated Index Help
PREV CLASS NEXT CLASS
FRAMES
SUMMARY: NESTED | FIELD | CONSTR | METHOD
DETAIL: FIELD | CONSTR | METHOD
NO FRAMES
All Classes
RBACCoreDynamic
Overview Package Class Use Tree Deprecated Index Help
PREV CLASS NEXT CLASS
FRAMES
SUMMARY: NESTED | FIELD | CONSTR | METHOD
DETAIL: FIELD | CONSTR | METHOD
NO FRAMES
All Classes
it.unibs.carlotti.rbac.core
Class RBACCoreDynamic
java.lang.Object
it.unibs.carlotti.rbac.core.RBACCoreDynamic
All Implemented Interfaces:
EngineComponent
public class RBACCoreDynamic
extends java.lang.Object
implements EngineComponent
Componente Core del motore dinamico
Author:
Giacomo Carlotti
Constructor Summary
RBACCoreDynamic()
Method Summary
boolean activatePermission(java.lang.String roleName, java.lang.
String permissionName, java.lang.Object obj)
Attiva un permesso verificando eventuali vincoli
boolean addActiveRole(java.lang.String roleName, java.lang.
String idSession)
attiva un ruolo per una sessione utente, verificando gli eventuali vincoli
RBACCoreDynamic
boolean checkAccess(java.lang.String userName, java.lang.
String objectName, java.lang.String operation, java.lang.
String idSession, java.lang.Object obj)
controlla la disponibilità di un permesso per un certo utente e cerca di attivare un
ruolo a cui il permesso è associato
void createSession(java.lang.String idSession, java.lang.
String userName)
crea una nuova sessione utente ed prova ad attivare i ruoli di default
void deleteSession(java.lang.String id)
disattiva i ruoli della sessione e la elimina
boolean dropActiveRole(java.lang.String roleName, java.lang.
String idSession)
disattiva un ruolo di una sessione utente
Methods inherited from class java.lang.Object
clone, equals, finalize, getClass, hashCode, notify, notifyAll,
toString, wait, wait, wait
Constructor Detail
RBACCoreDynamic
public RBACCoreDynamic()
Method Detail
activatePermission
public boolean activatePermission(java.lang.String roleName,
java.lang.String permissionName,
java.lang.Object obj)
Description copied from interface: EngineComponent
Attiva un permesso verificando eventuali vincoli
Specified by:
activatePermission in interface EngineComponent
Parameters:
RBACCoreDynamic
roleName - ruolo coinvolto nel vincolo
permissionName - permesso coinvolto nel vincolo
obj - reference all'ogggetto
Returns:
true il processo di attivazione va a buon fine, false altrimenti
addActiveRole
public boolean addActiveRole(java.lang.String roleName,
java.lang.String idSession)
Description copied from interface: EngineComponent
attiva un ruolo per una sessione utente, verificando gli eventuali vincoli
Specified by:
addActiveRole in interface EngineComponent
Parameters:
roleName - nome del ruolo
idSession - id della sessione
Returns:
true se riesce ad attivare il ruolo, false altrimenti
checkAccess
public boolean checkAccess(java.lang.String
java.lang.String
java.lang.String
java.lang.String
java.lang.Object
userName,
objectName,
operation,
idSession,
obj)
Description copied from interface: EngineComponent
controlla la disponibilità di un permesso per un certo utente e cerca di attivare un ruolo a cui il
permesso è associato
Specified by:
checkAccess in interface EngineComponent
Parameters:
userName - nome del ruolo
objectName - nome dell'oggetto
operation - nome dell'operazione
RBACCoreDynamic
idSession - id della sessione
obj - reference dell'oggetto
Returns:
true il processo di attivazione va a buon fine, false altrimenti
createSession
public void createSession(java.lang.String idSession,
java.lang.String userName)
Description copied from interface: EngineComponent
crea una nuova sessione utente ed prova ad attivare i ruoli di default
Specified by:
createSession in interface EngineComponent
Parameters:
idSession - id della sessione
userName - nome dell'utente
deleteSession
public void deleteSession(java.lang.String id)
Description copied from interface: EngineComponent
disattiva i ruoli della sessione e la elimina
Specified by:
deleteSession in interface EngineComponent
Parameters:
id - id della sessione
dropActiveRole
public boolean dropActiveRole(java.lang.String roleName,
java.lang.String idSession)
Description copied from interface: EngineComponent
RBACCoreDynamic
disattiva un ruolo di una sessione utente
Specified by:
dropActiveRole in interface EngineComponent
Parameters:
roleName - nome del ruolo
idSession - id della sessione
Returns:
true se riesce a disattivare il ruolo, false altrimenti
Overview Package Class Use Tree Deprecated Index Help
PREV CLASS NEXT CLASS
FRAMES
SUMMARY: NESTED | FIELD | CONSTR | METHOD
DETAIL: FIELD | CONSTR | METHOD
NO FRAMES
All Classes
RBACCoreStatic
Overview Package Class Use Tree Deprecated Index Help
PREV CLASS NEXT CLASS
FRAMES
SUMMARY: NESTED | FIELD | CONSTR | METHOD
DETAIL: FIELD | CONSTR | METHOD
NO FRAMES
All Classes
it.unibs.carlotti.rbac.core
Class RBACCoreStatic
java.lang.Object
it.unibs.carlotti.rbac.core.RBACCoreStatic
All Implemented Interfaces:
IntegrityComponent
public class RBACCoreStatic
extends java.lang.Object
implements IntegrityComponent
Componente Core del motore statico
Author:
Giacomo Carlotti
Constructor Summary
RBACCoreStatic()
Method Summary
void checkIntegrity()
Controlla i vincoli statici di integrità del sistema
Methods inherited from class java.lang.Object
clone, equals, finalize, getClass, hashCode, notify, notifyAll,
toString, wait, wait, wait
RBACCoreStatic
Constructor Detail
RBACCoreStatic
public RBACCoreStatic()
Method Detail
checkIntegrity
public void checkIntegrity()
throws java.lang.Throwable
Description copied from interface: IntegrityComponent
Controlla i vincoli statici di integrità del sistema
Specified by:
checkIntegrity in interface IntegrityComponent
Throws:
java.lang.Throwable
Overview Package Class Use Tree Deprecated Index Help
PREV CLASS NEXT CLASS
FRAMES
SUMMARY: NESTED | FIELD | CONSTR | METHOD
DETAIL: FIELD | CONSTR | METHOD
NO FRAMES
All Classes
RBACSession
Overview Package Class Use Tree Deprecated Index Help
PREV CLASS NEXT CLASS
FRAMES
SUMMARY: NESTED | FIELD | CONSTR | METHOD
DETAIL: FIELD | CONSTR | METHOD
NO FRAMES
All Classes
it.unibs.carlotti.rbac.core
Class RBACSession
java.lang.Object
it.unibs.carlotti.rbac.core.RBACSession
All Implemented Interfaces:
Session
public class RBACSession
extends java.lang.Object
implements Session
Sessione RBAC
Author:
Giacomo Carlotti
Constructor Summary
RBACSession(java.lang.String id, java.lang.String userName)
Method Summary
java.util. getActiveRoles()
Vector<java.
Restituisce l'elenco dei ruoli attivi della sessione
lang.String>
java.lang. getId()
String
Restituisce l'id della sessione
RBACSession
java.lang. getUserName()
String
Restituisce il nome dell'utente che ha creato la sessione
void setUserName(java.lang.String userName)
Methods inherited from class java.lang.Object
clone, equals, finalize, getClass, hashCode, notify, notifyAll,
toString, wait, wait, wait
Constructor Detail
RBACSession
public RBACSession(java.lang.String id,
java.lang.String userName)
Method Detail
getActiveRoles
public java.util.Vector<java.lang.String> getActiveRoles()
Description copied from interface: Session
Restituisce l'elenco dei ruoli attivi della sessione
Specified by:
getActiveRoles in interface Session
Returns:
l'elenco dei ruoli attivi
getUserName
public java.lang.String getUserName()
Description copied from interface: Session
Restituisce il nome dell'utente che ha creato la sessione
RBACSession
Specified by:
getUserName in interface Session
Returns:
il nome dell'utente
getId
public java.lang.String getId()
Description copied from interface: Session
Restituisce l'id della sessione
Specified by:
getId in interface Session
Returns:
l'id della sessione
setUserName
public void setUserName(java.lang.String userName)
Overview Package Class Use Tree Deprecated Index Help
PREV CLASS NEXT CLASS
FRAMES
SUMMARY: NESTED | FIELD | CONSTR | METHOD
DETAIL: FIELD | CONSTR | METHOD
NO FRAMES
All Classes
RBACSessionsManager
Overview Package Class Use Tree Deprecated Index Help
PREV CLASS NEXT CLASS
FRAMES
SUMMARY: NESTED | FIELD | CONSTR | METHOD
DETAIL: FIELD | CONSTR | METHOD
NO FRAMES
All Classes
it.unibs.carlotti.rbac.core
Class RBACSessionsManager
java.lang.Object
it.unibs.carlotti.rbac.core.RBACSessionsManager
All Implemented Interfaces:
SessionsManager
public final class RBACSessionsManager
extends java.lang.Object
implements SessionsManager
Manager delle Sessioni RBAC
Author:
Giacomo Carlotti
Method Summary
boolean addActiveRole(java.lang.String roleName, java.lang.
String idSession)
Aggiunge un ruolo attivo ad una sessione
void attach(SessionObserver o)
Aggiunge un oesservatore
void createSession(java.lang.String idSession, java.lang.
String userName)
Crea una nuova sessione
void deleteSession(java.lang.String id)
Elimina una sessione
void detach(SessionObserver o)
elimina un osservatore
boolean dropActiveRole(java.lang.String roleName, java.lang.
String idSession)
Elimina un ruolo attivo da una sessione
static SessionsManager getInstance()
RBACSession getSession(java.lang.String id)
Restituisce la sessione desiderata
RBACSessionsManager
java.util. getSessions()
Collection<RBACSession>
Restituisce l'elenco delle sessioni
java.lang.String getSessionUserName(java.lang.String idSession)
restituisce il nome dell'utente di una sessione
void notifyObservers()
Avvisa gli osservatori di un cambiamento di stato
java.util. sessionActiveRoles(java.lang.String idSession)
Collection<java.lang.
restituisce i ruoli attivi di una sessione
String>
java.util. userActiveRoles(java.lang.String userName)
Collection<java.lang.
Restituisce l'elenco dei ruoli attivi di un utente
String>
Methods inherited from class java.lang.Object
clone, equals, finalize, getClass, hashCode, notify, notifyAll, toString, wait,
wait, wait
Method Detail
getInstance
public static SessionsManager getInstance()
attach
public void attach(SessionObserver o)
Description copied from interface: SessionsManager
Aggiunge un oesservatore
Specified by:
attach in interface SessionsManager
Parameters:
o - osservatore
detach
public void detach(SessionObserver o)
Description copied from interface: SessionsManager
elimina un osservatore
Specified by:
detach in interface SessionsManager
RBACSessionsManager
Parameters:
o - osservatore
notifyObservers
public void notifyObservers()
Description copied from interface: SessionsManager
Avvisa gli osservatori di un cambiamento di stato
Specified by:
notifyObservers in interface SessionsManager
getSessions
public java.util.Collection<RBACSession> getSessions()
Description copied from interface: SessionsManager
Restituisce l'elenco delle sessioni
Specified by:
getSessions in interface SessionsManager
Returns:
elenco delle sessioni
getSession
public RBACSession getSession(java.lang.String id)
throws java.lang.Throwable
Description copied from interface: SessionsManager
Restituisce la sessione desiderata
Specified by:
getSession in interface SessionsManager
Parameters:
id - identificativo della sessione
Returns:
la sessione indicata
Throws:
java.lang.Throwable
addActiveRole
public boolean addActiveRole(java.lang.String roleName,
RBACSessionsManager
java.lang.String idSession)
Description copied from interface: SessionsManager
Aggiunge un ruolo attivo ad una sessione
Specified by:
addActiveRole in interface SessionsManager
Parameters:
roleName - nome del ruolo
idSession - id della sessione
Returns:
true se l'operazione va abuon fine, false altrimenti
dropActiveRole
public boolean dropActiveRole(java.lang.String roleName,
java.lang.String idSession)
Description copied from interface: SessionsManager
Elimina un ruolo attivo da una sessione
Specified by:
dropActiveRole in interface SessionsManager
Parameters:
roleName - nome del ruolo
idSession - id della sessione
Returns:
true se l'operazione va abuon fine, false altrimenti
userActiveRoles
public java.util.Collection<java.lang.String> userActiveRoles(java.lang.
String userName)
Description copied from interface: SessionsManager
Restituisce l'elenco dei ruoli attivi di un utente
Specified by:
userActiveRoles in interface SessionsManager
Parameters:
userName - nome dell'utente
Returns:
elenco dei ruoli attivi
sessionActiveRoles
public java.util.Collection<java.lang.String> sessionActiveRoles(java.lang.
String idSession)
RBACSessionsManager
throws java.lang.Throwable
Description copied from interface: SessionsManager
restituisce i ruoli attivi di una sessione
Specified by:
sessionActiveRoles in interface SessionsManager
Parameters:
idSession - id della sessione
Returns:
elenco dei ruoli attivi
Throws:
java.lang.Throwable
getSessionUserName
public java.lang.String getSessionUserName(java.lang.String idSession)
throws java.lang.Throwable
Description copied from interface: SessionsManager
restituisce il nome dell'utente di una sessione
Specified by:
getSessionUserName in interface SessionsManager
Parameters:
idSession - id della sessione
Returns:
nome dell'utente
Throws:
java.lang.Throwable
createSession
public void createSession(java.lang.String idSession,
java.lang.String userName)
Description copied from interface: SessionsManager
Crea una nuova sessione
Specified by:
createSession in interface SessionsManager
Parameters:
idSession - id della sessione
userName - nome dell'utente
deleteSession
public void deleteSession(java.lang.String id)
RBACSessionsManager
Description copied from interface: SessionsManager
Elimina una sessione
Specified by:
deleteSession in interface SessionsManager
Parameters:
id - id della sessione
Overview Package Class Use Tree Deprecated Index Help
PREV CLASS NEXT CLASS
FRAMES
SUMMARY: NESTED | FIELD | CONSTR | METHOD
DETAIL: FIELD | CONSTR | METHOD
NO FRAMES
All Classes
Session
Overview Package Class Use Tree Deprecated Index Help
PREV CLASS NEXT CLASS
FRAMES
SUMMARY: NESTED | FIELD | CONSTR | METHOD
DETAIL: FIELD | CONSTR | METHOD
NO FRAMES
it.unibs.carlotti.rbac.core
Interface Session
All Known Implementing Classes:
RBACSession
public interface Session
Questa interfaccia definisce i metodi per la gestione di una sessione utente
Author:
Giacomo Carlotti
Method Summary
java.util. getActiveRoles()
Vector<java.
Restituisce l'elenco dei ruoli attivi della sessione
lang.String>
java.lang. getId()
String
Restituisce l'id della sessione
java.lang. getUserName()
String
Restituisce il nome dell'utente che ha creato la sessione
Method Detail
getActiveRoles
java.util.Vector<java.lang.String> getActiveRoles()
Restituisce l'elenco dei ruoli attivi della sessione
All Classes
Session
Returns:
l'elenco dei ruoli attivi
getUserName
java.lang.String getUserName()
Restituisce il nome dell'utente che ha creato la sessione
Returns:
il nome dell'utente
getId
java.lang.String getId()
Restituisce l'id della sessione
Returns:
l'id della sessione
Overview Package Class Use Tree Deprecated Index Help
PREV CLASS NEXT CLASS
FRAMES
SUMMARY: NESTED | FIELD | CONSTR | METHOD
DETAIL: FIELD | CONSTR | METHOD
NO FRAMES
All Classes
SessionObserver
Overview Package Class Use Tree Deprecated Index Help
PREV CLASS NEXT CLASS
FRAMES
SUMMARY: NESTED | FIELD | CONSTR | METHOD
DETAIL: FIELD | CONSTR | METHOD
NO FRAMES
All Classes
it.unibs.carlotti.rbac.core
Interface SessionObserver
All Known Implementing Classes:
RBACSessionsMonitor
public interface SessionObserver
Questa interfaccia definisce i metodi da un monitor di sessione
Author:
Giacomo Carlotti
Method Summary
void update()
Aggiorna i dati del monitor di sessione
Method Detail
update
void update()
Aggiorna i dati del monitor di sessione
Overview Package Class Use Tree Deprecated Index Help
PREV CLASS NEXT CLASS
FRAMES
SUMMARY: NESTED | FIELD | CONSTR | METHOD
DETAIL: FIELD | CONSTR | METHOD
NO FRAMES
All Classes
SessionsManager
Overview Package Class Use Tree Deprecated Index Help
PREV CLASS NEXT CLASS
FRAMES
SUMMARY: NESTED | FIELD | CONSTR | METHOD
DETAIL: FIELD | CONSTR | METHOD
NO FRAMES
All Classes
it.unibs.carlotti.rbac.core
Interface SessionsManager
All Known Implementing Classes:
RBACSessionsManager
public interface SessionsManager
Questa interfaccia definisce i metodi che devono essere implementati per gestire le sessione di un sistema RBAC
Author:
Giacomo Carlotti
Method Summary
boolean addActiveRole(java.lang.String roleName, java.lang.
String idSession)
Aggiunge un ruolo attivo ad una sessione
void attach(SessionObserver o)
Aggiunge un oesservatore
void createSession(java.lang.String idSession, java.lang.
String userName)
Crea una nuova sessione
void deleteSession(java.lang.String idSession)
Elimina una sessione
void detach(SessionObserver o)
elimina un osservatore
boolean dropActiveRole(java.lang.String roleName, java.lang.
String idSession)
Elimina un ruolo attivo da una sessione
RBACSession getSession(java.lang.String id)
Restituisce la sessione desiderata
java.util. getSessions()
Collection<RBACSession>
Restituisce l'elenco delle sessioni
java.lang.String getSessionUserName(java.lang.String idSession)
restituisce il nome dell'utente di una sessione
void notifyObservers()
Avvisa gli osservatori di un cambiamento di stato
SessionsManager
java.util. sessionActiveRoles(java.lang.String idSession)
Collection<java.lang.
restituisce i ruoli attivi di una sessione
String>
java.util. userActiveRoles(java.lang.String userName)
Collection<java.lang.
Restituisce l'elenco dei ruoli attivi di un utente
String>
Method Detail
getSessions
java.util.Collection<RBACSession> getSessions()
Restituisce l'elenco delle sessioni
Returns:
elenco delle sessioni
getSession
RBACSession getSession(java.lang.String id)
throws java.lang.Throwable
Restituisce la sessione desiderata
Parameters:
id - identificativo della sessione
Returns:
la sessione indicata
Throws:
java.lang.Throwable
addActiveRole
boolean addActiveRole(java.lang.String roleName,
java.lang.String idSession)
Aggiunge un ruolo attivo ad una sessione
Parameters:
roleName - nome del ruolo
idSession - id della sessione
Returns:
true se l'operazione va abuon fine, false altrimenti
dropActiveRole
SessionsManager
boolean dropActiveRole(java.lang.String roleName,
java.lang.String idSession)
Elimina un ruolo attivo da una sessione
Parameters:
roleName - nome del ruolo
idSession - id della sessione
Returns:
true se l'operazione va abuon fine, false altrimenti
userActiveRoles
java.util.Collection<java.lang.String> userActiveRoles(java.lang.String userName)
Restituisce l'elenco dei ruoli attivi di un utente
Parameters:
userName - nome dell'utente
Returns:
elenco dei ruoli attivi
sessionActiveRoles
java.util.Collection<java.lang.String> sessionActiveRoles(java.lang.String idSession)
throws java.lang.Throwable
restituisce i ruoli attivi di una sessione
Parameters:
idSession - id della sessione
Returns:
elenco dei ruoli attivi
Throws:
java.lang.Throwable
getSessionUserName
java.lang.String getSessionUserName(java.lang.String idSession)
throws java.lang.Throwable
restituisce il nome dell'utente di una sessione
Parameters:
idSession - id della sessione
Returns:
nome dell'utente
Throws:
SessionsManager
java.lang.Throwable
createSession
void createSession(java.lang.String idSession,
java.lang.String userName)
Crea una nuova sessione
Parameters:
idSession - id della sessione
userName - nome dell'utente
deleteSession
void deleteSession(java.lang.String idSession)
Elimina una sessione
Parameters:
idSession - id della sessione
attach
void attach(SessionObserver o)
Aggiunge un oesservatore
Parameters:
o - osservatore
detach
void detach(SessionObserver o)
elimina un osservatore
Parameters:
o - osservatore
notifyObservers
void notifyObservers()
SessionsManager
Avvisa gli osservatori di un cambiamento di stato
Overview Package Class Use Tree Deprecated Index Help
PREV CLASS NEXT CLASS
FRAMES
SUMMARY: NESTED | FIELD | CONSTR | METHOD
DETAIL: FIELD | CONSTR | METHOD
NO FRAMES
All Classes
StaticConstraint
Overview Package Class Use Tree Deprecated Index Help
PREV CLASS NEXT CLASS
FRAMES
SUMMARY: NESTED | FIELD | CONSTR | METHOD
DETAIL: FIELD | CONSTR | METHOD
NO FRAMES
All Classes
it.unibs.carlotti.rbac.core
Interface StaticConstraint
All Superinterfaces:
IntegrityComponent
All Known Implementing Classes:
RBACHierarchyStatic, RBACLimitedHierarchy, RBACSSD
public interface StaticConstraint
extends IntegrityComponent
Questa interfaccia definisce i metodi che devono essere implementati dai vincoli statici del modello
Author:
Giacomo Carlotti
Method Summary
Methods inherited from interface it.unibs.carlotti.rbac.core.IntegrityComponent
checkIntegrity
Overview Package Class Use Tree Deprecated Index Help
PREV CLASS NEXT CLASS
FRAMES
SUMMARY: NESTED | FIELD | CONSTR | METHOD
DETAIL: FIELD | CONSTR | METHOD
NO FRAMES
All Classes
AdministrativeFunctions
Overview Package Class Use Tree Deprecated Index Help
PREV CLASS NEXT CLASS
FRAMES
SUMMARY: NESTED | FIELD | CONSTR | METHOD
DETAIL: FIELD | CONSTR | METHOD
NO FRAMES
All Classes
it.unibs.carlotti.rbac.db
Interface AdministrativeFunctions
All Known Implementing Classes:
RBACAdmin
public interface AdministrativeFunctions
Questa interfaccia definisce le funzioni amministrative del sistema RBAC
Author:
Giacomo Carlotti
Method Summary
void addDSDSet(java.lang.String role1, java.lang.String role2)
Aggiunge un vincolo di separazione dinamica dei compiti
void addInheritance(java.lang.String roleParent, java.lang.
String roleChild)
Aggiunge una relazione gerarchica
void addPermission(java.lang.String name, java.lang.
String objectName, java.lang.String operationName)
Aggiunge un permesso
void addRole(java.lang.String name)
Aggiunge un nuovo ruolo
void addSSDSet(java.lang.String role1, java.lang.String role2)
Aggiunge un vincolo di separazione statica dei compiti
void addTimeConstraint(java.lang.String role, java.lang.
String permission, java.lang.String from, java.lang.
String to)
Agginge un vincolo temporale
AdministrativeFunctions
void addUser(java.lang.String name)
Aggiunge un nuovo utente
void assignDefaultRole(java.lang.String userName, java.lang.
String roleName)
Assegna un ruolo di default ad un utente
void assignUser(java.lang.String userName, java.lang.
String roleName)
Assegna un utente ad un ruolo
void deassignDefaultRole(java.lang.String userName, java.lang.
String roleName)
Elimina l'associazione tra un utente e un ruolo di default
void deassignUser(java.lang.String userName, java.lang.
String roleName)
Elimina l'associazione tra un utente da un ruolo
void deleteDSDSet(java.lang.String role1, java.lang.String role2)
Elimina un vincolo di separazione dinamica dei compiti
void deleteInheritance(java.lang.String roleParent, java.lang.
String roleChild)
Elimina una relazione gerarchica
void deletePermission(java.lang.String name)
elimina un permesso
void deleteRole(java.lang.String name)
Elimina un ruolo
void deleteSSDSet(java.lang.String role1, java.lang.String role2)
Elimina un vincolo di separazione statica dei compiti
void deleteTimeConstraint(java.lang.String role, java.lang.
String permission)
Elimina un vincolo temporale
void deleteUser(java.lang.String name)
Elimina un utente
void grantPermission(java.lang.String permissionName, java.lang.
String roleName)
Assegna un permesso a un ruolo
void revokePermission(java.lang.String permissionName, java.lang.
String roleName)
Revoca un permesso ad un ruolo
AdministrativeFunctions
Method Detail
addRole
void addRole(java.lang.String name)
throws java.lang.Throwable
Aggiunge un nuovo ruolo
Parameters:
name - nome del ruolo
Throws:
java.lang.Throwable
deleteRole
void deleteRole(java.lang.String name)
throws java.lang.Throwable
Elimina un ruolo
Parameters:
name - nome del ruolo
Throws:
java.lang.Throwable
addUser
void addUser(java.lang.String name)
throws java.lang.Throwable
Aggiunge un nuovo utente
Parameters:
name - nome dell'utente
Throws:
java.lang.Throwable
AdministrativeFunctions
deleteUser
void deleteUser(java.lang.String name)
throws java.lang.Throwable
Elimina un utente
Parameters:
name - nome dell'utente
Throws:
java.lang.Throwable
addPermission
void addPermission(java.lang.String name,
java.lang.String objectName,
java.lang.String operationName)
throws java.lang.Throwable
Aggiunge un permesso
Parameters:
name - nome del permesso
objectName - nome dell'oggetto
operationName - nome dell'operazione
Throws:
java.lang.Throwable
deletePermission
void deletePermission(java.lang.String name)
throws java.lang.Throwable
elimina un permesso
Parameters:
name - nome del permesso
Throws:
java.lang.Throwable
AdministrativeFunctions
assignUser
void assignUser(java.lang.String userName,
java.lang.String roleName)
throws java.lang.Throwable
Assegna un utente ad un ruolo
Parameters:
userName - nome dell'utente
roleName - nome del ruolo
Throws:
java.lang.Throwable
deassignUser
void deassignUser(java.lang.String userName,
java.lang.String roleName)
throws java.lang.Throwable
Elimina l'associazione tra un utente da un ruolo
Parameters:
userName - nome dell'utente
roleName - nome del ruolo
Throws:
java.lang.Throwable
assignDefaultRole
void assignDefaultRole(java.lang.String userName,
java.lang.String roleName)
throws java.lang.Throwable
Assegna un ruolo di default ad un utente
Parameters:
AdministrativeFunctions
userName - nome dell'utente
roleName - nome del ruolo
Throws:
java.lang.Throwable
deassignDefaultRole
void deassignDefaultRole(java.lang.String userName,
java.lang.String roleName)
throws java.lang.Throwable
Elimina l'associazione tra un utente e un ruolo di default
Parameters:
userName - nome dell'utente
roleName - nome del ruolo
Throws:
java.lang.Throwable
grantPermission
void grantPermission(java.lang.String permissionName,
java.lang.String roleName)
throws java.lang.Throwable
Assegna un permesso a un ruolo
Parameters:
permissionName - nome del permesso
roleName - nome del ruolo
Throws:
java.lang.Throwable
revokePermission
void revokePermission(java.lang.String permissionName,
java.lang.String roleName)
throws java.lang.Throwable
AdministrativeFunctions
Revoca un permesso ad un ruolo
Parameters:
permissionName - nome del permesso
roleName - nome del ruolo
Throws:
java.lang.Throwable
addInheritance
void addInheritance(java.lang.String roleParent,
java.lang.String roleChild)
throws java.lang.Throwable
Aggiunge una relazione gerarchica
Parameters:
roleParent - ruolo padre
roleChild - ruolo figlio
Throws:
java.lang.Throwable
deleteInheritance
void deleteInheritance(java.lang.String roleParent,
java.lang.String roleChild)
throws java.lang.Throwable
Elimina una relazione gerarchica
Parameters:
roleParent - ruolo padre
roleChild - ruolo figlio
Throws:
java.lang.Throwable
addSSDSet
AdministrativeFunctions
void addSSDSet(java.lang.String role1,
java.lang.String role2)
throws java.lang.Throwable
Aggiunge un vincolo di separazione statica dei compiti
Parameters:
role1 - ruolo mutuamente esclusivo
role2 - ruolo mutuamente esclusivo
Throws:
java.lang.Throwable
deleteSSDSet
void deleteSSDSet(java.lang.String role1,
java.lang.String role2)
throws java.lang.Throwable
Elimina un vincolo di separazione statica dei compiti
Parameters:
role1 - ruolo mutuamente esclusivo
role2 - ruolo mutuamente esclusivo
Throws:
java.lang.Throwable
addDSDSet
void addDSDSet(java.lang.String role1,
java.lang.String role2)
throws java.lang.Throwable
Aggiunge un vincolo di separazione dinamica dei compiti
Parameters:
role1 - ruolo mutuamente esclusivo
role2 - ruolo mutuamente esclusivo
Throws:
java.lang.Throwable
AdministrativeFunctions
deleteDSDSet
void deleteDSDSet(java.lang.String role1,
java.lang.String role2)
throws java.lang.Throwable
Elimina un vincolo di separazione dinamica dei compiti
Parameters:
role1 - ruolo mutuamente esclusivo
role2 - ruolo mutuamente esclusivo
Throws:
java.lang.Throwable
addTimeConstraint
void addTimeConstraint(java.lang.String role,
java.lang.String permission,
java.lang.String from,
java.lang.String to)
throws java.lang.Throwable
Agginge un vincolo temporale
Parameters:
role - nome del ruolo
permission - nome del permesso
from - istante iniziale dell'intervallo di validità del permesso
to - istante finale dell'intervallo di validità del permesso
Throws:
java.lang.Throwable
deleteTimeConstraint
void deleteTimeConstraint(java.lang.String role,
java.lang.String permission)
throws java.lang.Throwable
AdministrativeFunctions
Elimina un vincolo temporale
Parameters:
role - nome del ruolo
permission - nome del permesso
Throws:
java.lang.Throwable
Overview Package Class Use Tree Deprecated Index Help
PREV CLASS NEXT CLASS
FRAMES
SUMMARY: NESTED | FIELD | CONSTR | METHOD
DETAIL: FIELD | CONSTR | METHOD
NO FRAMES
All Classes
DBUtil
Overview Package Class Use Tree Deprecated Index Help
PREV CLASS NEXT CLASS
FRAMES
SUMMARY: NESTED | FIELD | CONSTR | METHOD
DETAIL: FIELD | CONSTR | METHOD
NO FRAMES
All Classes
it.unibs.carlotti.rbac.db
Class DBUtil
java.lang.Object
it.unibs.carlotti.rbac.db.DBUtil
public class DBUtil
extends java.lang.Object
Questa classe implementa i metodi base per l'accesso ad un database
Author:
Giacomo Carlotti
Constructor Summary
DBUtil(java.lang.String username, java.lang.String password, java.
lang.String url, java.lang.String driver)
Costruttore
Method Summary
java. executeQuery(java.lang.String query)
sql.
Esegue una query generica sul database
ResultSet
void executeUpdate(java.lang.String query)
Esegue una query di aggiornamento del database
Methods inherited from class java.lang.Object
clone, equals, finalize, getClass, hashCode, notify, notifyAll,
toString, wait, wait, wait
DBUtil
Constructor Detail
DBUtil
public DBUtil(java.lang.String username,
java.lang.String password,
java.lang.String url,
java.lang.String driver)
throws java.sql.SQLException,
java.lang.ClassNotFoundException
Costruttore
Parameters:
username - nome dell'utente del db
password - password dell'utente del db
url - indirizzo del db
driver - jdbc drivers
Throws:
java.sql.SQLException
java.lang.ClassNotFoundException
Method Detail
executeQuery
public java.sql.ResultSet executeQuery(java.lang.String query)
throws java.lang.Throwable
Esegue una query generica sul database
Parameters:
query - query da eseguire
Returns:
risultato della query
Throws:
java.lang.Throwable
DBUtil
executeUpdate
public void executeUpdate(java.lang.String query)
throws java.lang.Throwable
Esegue una query di aggiornamento del database
Parameters:
query - query da eseguire
Throws:
java.lang.Throwable
Overview Package Class Use Tree Deprecated Index Help
PREV CLASS NEXT CLASS
FRAMES
SUMMARY: NESTED | FIELD | CONSTR | METHOD
DETAIL: FIELD | CONSTR | METHOD
NO FRAMES
All Classes
RBACAdmin
Overview Package Class Use Tree Deprecated Index Help
PREV CLASS NEXT CLASS
FRAMES
SUMMARY: NESTED | FIELD | CONSTR | METHOD
DETAIL: FIELD | CONSTR | METHOD
NO FRAMES
All Classes
it.unibs.carlotti.rbac.db
Class RBACAdmin
java.lang.Object
it.unibs.carlotti.rbac.db.RBACAdmin
All Implemented Interfaces:
AdministrativeFunctions
public final class RBACAdmin
extends java.lang.Object
implements AdministrativeFunctions
La classe contiene i metodi che servono a modificare il contenuto del database RBAC a scopo
amministrativo
Author:
Giacomo Carlotti
Field Summary
(package
db
private)
DBUtil
Method Summary
void addDSDSet(java.lang.String role1, java.lang.
String role2)
Aggiunge un vincolo di separazione dinamica dei compiti
RBACAdmin
void addInheritance(java.lang.String roleParent, java.
lang.String roleChild)
Aggiunge una relazione gerarchica
void addPermission(java.lang.String name, java.lang.
String objectName, java.lang.String operationName)
Aggiunge un permesso
void addRole(java.lang.String name)
Aggiunge un nuovo ruolo
void addSSDSet(java.lang.String role1, java.lang.
String role2)
Aggiunge un vincolo di separazione statica dei compiti
void addTimeConstraint(java.lang.String role, java.lang.
String permission, java.lang.String from, java.
lang.String to)
Agginge un vincolo temporale
void addUser(java.lang.String name)
Aggiunge un nuovo utente
void assignDefaultRole(java.lang.String userName, java.
lang.String roleName)
Assegna un ruolo di default ad un utente
void assignUser(java.lang.String userName, java.lang.
String roleName)
Assegna un utente ad un ruolo
void createDB()
void deassignDefaultRole(java.lang.String userName,
java.lang.String roleName)
Elimina l'associazione tra un utente e un ruolo di default
void deassignUser(java.lang.String userName, java.lang.
String roleName)
Elimina l'associazione tra un utente da un ruolo
void deleteDSDSet(java.lang.String role1, java.lang.
String role2)
Elimina un vincolo di separazione dinamica dei compiti
void deleteInheritance(java.lang.String roleParent,
java.lang.String roleChild)
Elimina una relazione gerarchica
RBACAdmin
void deletePermission(java.lang.String name)
elimina un permesso
void deleteRole(java.lang.String name)
Elimina un ruolo
void deleteSSDSet(java.lang.String role1, java.lang.
String role2)
Elimina un vincolo di separazione statica dei compiti
void deleteTimeConstraint(java.lang.String role, java.
lang.String permission)
Elimina un vincolo temporale
void deleteUser(java.lang.String name)
Elimina un utente
static RBACAdmin getInstance(java.lang.String username, java.lang.
String password)
void grantPermission(java.lang.String permissionName,
java.lang.String roleName)
Assegna un permesso a un ruolo
void revokePermission(java.lang.String permissionName,
java.lang.String roleName)
Revoca un permesso ad un ruolo
Methods inherited from class java.lang.Object
clone, equals, finalize, getClass, hashCode, notify, notifyAll,
toString, wait, wait, wait
Field Detail
db
final DBUtil db
Method Detail
getInstance
RBACAdmin
public static RBACAdmin getInstance(java.lang.String username,
java.lang.String password)
throws java.lang.Throwable
Throws:
java.lang.Throwable
createDB
public void createDB()
throws java.lang.Throwable
Throws:
java.lang.Throwable
addRole
public void addRole(java.lang.String name)
throws java.lang.Throwable
Description copied from interface: AdministrativeFunctions
Aggiunge un nuovo ruolo
Specified by:
addRole in interface AdministrativeFunctions
Parameters:
name - nome del ruolo
Throws:
java.lang.Throwable
deleteRole
public void deleteRole(java.lang.String name)
throws java.lang.Throwable
Description copied from interface: AdministrativeFunctions
Elimina un ruolo
RBACAdmin
Specified by:
deleteRole in interface AdministrativeFunctions
Parameters:
name - nome del ruolo
Throws:
java.lang.Throwable
addUser
public void addUser(java.lang.String name)
throws java.lang.Throwable
Description copied from interface: AdministrativeFunctions
Aggiunge un nuovo utente
Specified by:
addUser in interface AdministrativeFunctions
Parameters:
name - nome dell'utente
Throws:
java.lang.Throwable
deleteUser
public void deleteUser(java.lang.String name)
throws java.lang.Throwable
Description copied from interface: AdministrativeFunctions
Elimina un utente
Specified by:
deleteUser in interface AdministrativeFunctions
Parameters:
name - nome dell'utente
Throws:
java.lang.Throwable
RBACAdmin
addPermission
public void addPermission(java.lang.String name,
java.lang.String objectName,
java.lang.String operationName)
throws java.lang.Throwable
Description copied from interface: AdministrativeFunctions
Aggiunge un permesso
Specified by:
addPermission in interface AdministrativeFunctions
Parameters:
name - nome del permesso
objectName - nome dell'oggetto
operationName - nome dell'operazione
Throws:
java.lang.Throwable
deletePermission
public void deletePermission(java.lang.String name)
throws java.lang.Throwable
Description copied from interface: AdministrativeFunctions
elimina un permesso
Specified by:
deletePermission in interface AdministrativeFunctions
Parameters:
name - nome del permesso
Throws:
java.lang.Throwable
assignUser
public void assignUser(java.lang.String userName,
java.lang.String roleName)
throws java.lang.Throwable
RBACAdmin
Description copied from interface: AdministrativeFunctions
Assegna un utente ad un ruolo
Specified by:
assignUser in interface AdministrativeFunctions
Parameters:
userName - nome dell'utente
roleName - nome del ruolo
Throws:
java.lang.Throwable
deassignUser
public void deassignUser(java.lang.String userName,
java.lang.String roleName)
throws java.lang.Throwable
Description copied from interface: AdministrativeFunctions
Elimina l'associazione tra un utente da un ruolo
Specified by:
deassignUser in interface AdministrativeFunctions
Parameters:
userName - nome dell'utente
roleName - nome del ruolo
Throws:
java.lang.Throwable
assignDefaultRole
public void assignDefaultRole(java.lang.String userName,
java.lang.String roleName)
throws java.lang.Throwable
Description copied from interface: AdministrativeFunctions
Assegna un ruolo di default ad un utente
Specified by:
assignDefaultRole in interface AdministrativeFunctions
Parameters:
RBACAdmin
userName - nome dell'utente
roleName - nome del ruolo
Throws:
java.lang.Throwable
deassignDefaultRole
public void deassignDefaultRole(java.lang.String userName,
java.lang.String roleName)
throws java.lang.Throwable
Description copied from interface: AdministrativeFunctions
Elimina l'associazione tra un utente e un ruolo di default
Specified by:
deassignDefaultRole in interface AdministrativeFunctions
Parameters:
userName - nome dell'utente
roleName - nome del ruolo
Throws:
java.lang.Throwable
grantPermission
public void grantPermission(java.lang.String permissionName,
java.lang.String roleName)
throws java.lang.Throwable
Description copied from interface: AdministrativeFunctions
Assegna un permesso a un ruolo
Specified by:
grantPermission in interface AdministrativeFunctions
Parameters:
permissionName - nome del permesso
roleName - nome del ruolo
Throws:
java.lang.Throwable
RBACAdmin
revokePermission
public void revokePermission(java.lang.String permissionName,
java.lang.String roleName)
throws java.lang.Throwable
Description copied from interface: AdministrativeFunctions
Revoca un permesso ad un ruolo
Specified by:
revokePermission in interface AdministrativeFunctions
Parameters:
permissionName - nome del permesso
roleName - nome del ruolo
Throws:
java.lang.Throwable
addInheritance
public void addInheritance(java.lang.String roleParent,
java.lang.String roleChild)
throws java.lang.Throwable
Description copied from interface: AdministrativeFunctions
Aggiunge una relazione gerarchica
Specified by:
addInheritance in interface AdministrativeFunctions
Parameters:
roleParent - ruolo padre
roleChild - ruolo figlio
Throws:
java.lang.Throwable
deleteInheritance
public void deleteInheritance(java.lang.String roleParent,
java.lang.String roleChild)
throws java.lang.Throwable
RBACAdmin
Description copied from interface: AdministrativeFunctions
Elimina una relazione gerarchica
Specified by:
deleteInheritance in interface AdministrativeFunctions
Parameters:
roleParent - ruolo padre
roleChild - ruolo figlio
Throws:
java.lang.Throwable
addSSDSet
public void addSSDSet(java.lang.String role1,
java.lang.String role2)
throws java.lang.Throwable
Description copied from interface: AdministrativeFunctions
Aggiunge un vincolo di separazione statica dei compiti
Specified by:
addSSDSet in interface AdministrativeFunctions
Parameters:
role1 - ruolo mutuamente esclusivo
role2 - ruolo mutuamente esclusivo
Throws:
java.lang.Throwable
deleteSSDSet
public void deleteSSDSet(java.lang.String role1,
java.lang.String role2)
throws java.lang.Throwable
Description copied from interface: AdministrativeFunctions
Elimina un vincolo di separazione statica dei compiti
Specified by:
deleteSSDSet in interface AdministrativeFunctions
RBACAdmin
Parameters:
role1 - ruolo mutuamente esclusivo
role2 - ruolo mutuamente esclusivo
Throws:
java.lang.Throwable
addDSDSet
public void addDSDSet(java.lang.String role1,
java.lang.String role2)
throws java.lang.Throwable
Description copied from interface: AdministrativeFunctions
Aggiunge un vincolo di separazione dinamica dei compiti
Specified by:
addDSDSet in interface AdministrativeFunctions
Parameters:
role1 - ruolo mutuamente esclusivo
role2 - ruolo mutuamente esclusivo
Throws:
java.lang.Throwable
deleteDSDSet
public void deleteDSDSet(java.lang.String role1,
java.lang.String role2)
throws java.lang.Throwable
Description copied from interface: AdministrativeFunctions
Elimina un vincolo di separazione dinamica dei compiti
Specified by:
deleteDSDSet in interface AdministrativeFunctions
Parameters:
role1 - ruolo mutuamente esclusivo
role2 - ruolo mutuamente esclusivo
Throws:
java.lang.Throwable
RBACAdmin
addTimeConstraint
public void addTimeConstraint(java.lang.String role,
java.lang.String permission,
java.lang.String from,
java.lang.String to)
throws java.lang.Throwable
Description copied from interface: AdministrativeFunctions
Agginge un vincolo temporale
Specified by:
addTimeConstraint in interface AdministrativeFunctions
Parameters:
role - nome del ruolo
permission - nome del permesso
from - istante iniziale dell'intervallo di validità del permesso
to - istante finale dell'intervallo di validità del permesso
Throws:
java.lang.Throwable
deleteTimeConstraint
public void deleteTimeConstraint(java.lang.String role,
java.lang.String permission)
throws java.lang.Throwable
Description copied from interface: AdministrativeFunctions
Elimina un vincolo temporale
Specified by:
deleteTimeConstraint in interface AdministrativeFunctions
Parameters:
role - nome del ruolo
permission - nome del permesso
Throws:
java.lang.Throwable
Overview Package Class Use Tree Deprecated Index Help
RBACAdmin
PREV CLASS NEXT CLASS
FRAMES
SUMMARY: NESTED | FIELD | CONSTR | METHOD
DETAIL: FIELD | CONSTR | METHOD
NO FRAMES
All Classes
RBACReview
Overview Package Class Use Tree Deprecated Index Help
PREV CLASS NEXT CLASS
FRAMES
SUMMARY: NESTED | FIELD | CONSTR | METHOD
DETAIL: FIELD | CONSTR | METHOD
NO FRAMES
All Classes
it.unibs.carlotti.rbac.db
Class RBACReview
java.lang.Object
it.unibs.carlotti.rbac.db.RBACReview
All Implemented Interfaces:
ReviewFunctions
public final class RBACReview
extends java.lang.Object
implements ReviewFunctions
La classe contiene metodi di reportistica, che non modificano il contenuto del database RBAC
Author:
Giacomo Carlotti
Field Summary
static java. SEPARATORE
lang.String
Method Summary
java.util. assignedPermissionRoles(java.lang.String userName, java.
Collection<java.lang. lang.String permissionName)
String>
Restituisce i nomi dei ruoli assegnati ad un utente, ai quali è assegnato il
permesso indicato
java.util. assignedRoles(java.lang.String userName)
Collection<java.lang.
Restituisce i nomi dei ruoli assegnati direttamente ad un utente
String>
java.util. authorizedPermissionRoles(java.lang.String userName, java.
Collection<java.lang. lang.String permissionName)
String>
Restituisce i nomi dei ruoli ereditati da un utente, ai quali è assegnato il permesso
indicato
java.util. authorizedRoles(java.lang.String userName)
Collection<java.lang.
Restituisce l'elenco dei ruoli autorizzati per un utente
String>
RBACReview
java.util. defaultUserRoles(java.lang.String userName)
Collection<java.lang.
Restituisce i nomi dei ruoli di default assegnati ad un utente
String>
java.util. getConflictingDSDRoles(java.lang.String role)
Collection<java.lang.
Restituisce i nomi dei ruoli mutuamente esclusivi ad un ruolo secondo i vincoli
String> DSD
java.util. getConflictingSSDRoles(java.lang.String role)
Collection<java.lang.
Restituisce i nomi dei ruoli mutuamente esclusivi ad un ruolo secondo i vincoli
String> SSD
java.util. getDefaultRoles()
Collection<java.lang.
Restituisce l'elenco delle relazioni utente-ruolo_di_default
String>
java.util. getDSDs()
Collection<java.lang.
Restituisce l'elenco dei vincoli di DSD
String>
java.lang.String getFromTime(java.lang.String role, java.lang.
String permission)
Restituisce il limite inferiore del vincolo temporale
static ReviewFunctions getInstance()
int getMaxChildren()
Calcola il numero massimo di ruoli figli presenti all'interno della gerarchia
int getMaxParents()
Calcola il numero massimo di ruoli padri presenti all'interno della gerarchia
java.util. getPAs()
Collection<java.lang.
Restituisce l'elenco delle relazioni ruolo-permesso
String>
java.lang.String getPermissionId(java.lang.String name)
Restituisce l'id di un permesso dato il nome
java.lang.String getPermissionName(java.lang.String operation, java.lang.
String object)
Restituisce il nome di un permesso dati i nomi dell'oggetto e dell'operazione
java.util. getPermissions()
Collection<java.lang.
Restituisce l'elenco dei permessi
String>
java.util. getRHs()
Collection<java.lang.
Restituisce l'elenco delle relazioni gerarchiche
String>
java.lang.String getRoleId(java.lang.String name)
Restituisce l'id di un ruolo dato il nome
java.util. getRoles()
Collection<java.lang.
Restituisce l'elenco dei ruoli
String>
java.util. getSSDs()
Collection<java.lang.
Restituisce l'elenco dei vincoli di SSD
String>
RBACReview
java.util. getTimes()
Collection<java.lang.
Restituisce l'elenco dei vincoli temporali
String>
java.lang.String getToTime(java.lang.String role, java.lang.
String permission)
Restituisce il limite superiore del vincolo temporale
java.util. getUAs()
Collection<java.lang.
Restituisce l'elenco delle relazioni utente-ruolo
String>
java.lang.String getUserId(java.lang.String name)
Restituisce l'id di un utente dato il nome
java.util. getUsers()
Collection<java.lang.
String>
Methods inherited from class java.lang.Object
clone, equals, finalize, getClass, hashCode, notify, notifyAll, toString, wait,
wait, wait
Field Detail
SEPARATORE
public static final java.lang.String SEPARATORE
See Also:
Constant Field Values
Method Detail
getInstance
public static ReviewFunctions getInstance()
throws java.lang.Throwable
Throws:
java.lang.Throwable
getPermissionName
public java.lang.String getPermissionName(java.lang.String operation,
java.lang.String object)
throws java.lang.Throwable
Description copied from interface: ReviewFunctions
RBACReview
Restituisce il nome di un permesso dati i nomi dell'oggetto e dell'operazione
Specified by:
getPermissionName in interface ReviewFunctions
Parameters:
operation - nome dell'operazione
object - nome dell'oggetto
Returns:
il nome del permesso
Throws:
java.lang.Throwable
assignedRoles
public java.util.Collection<java.lang.String> assignedRoles(java.lang.
String userName)
throws java.lang.Throwable
Description copied from interface: ReviewFunctions
Restituisce i nomi dei ruoli assegnati direttamente ad un utente
Specified by:
assignedRoles in interface ReviewFunctions
Parameters:
userName - nome dell'utente
Returns:
elenco dei ruoli
Throws:
java.lang.Throwable
defaultUserRoles
public java.util.Collection<java.lang.String> defaultUserRoles(java.lang.
String userName)
throws java.lang.Throwable
Description copied from interface: ReviewFunctions
Restituisce i nomi dei ruoli di default assegnati ad un utente
Specified by:
defaultUserRoles in interface ReviewFunctions
Parameters:
userName - nome dell'utente
Returns:
elenco dei ruoli di default
Throws:
java.lang.Throwable
RBACReview
assignedPermissionRoles
public java.util.Collection<java.lang.String> assignedPermissionRoles(java.lang.
String userName,
java.lang.
String permissionName)
throws java.lang.
Throwable
Description copied from interface: ReviewFunctions
Restituisce i nomi dei ruoli assegnati ad un utente, ai quali è assegnato il permesso indicato
Specified by:
assignedPermissionRoles in interface ReviewFunctions
Parameters:
userName - nome dell'utente
permissionName - nome del permesso
Returns:
elenco dei nomi dei ruoli assegnati ad un utente
Throws:
java.lang.Throwable
authorizedRoles
public java.util.Collection<java.lang.String> authorizedRoles(java.lang.
String userName)
throws java.lang.Throwable
Description copied from interface: ReviewFunctions
Restituisce l'elenco dei ruoli autorizzati per un utente
Specified by:
authorizedRoles in interface ReviewFunctions
Parameters:
userName - nome dell'utente
Returns:
l'elenco dei ruoli autorizzati per un utente
Throws:
java.lang.Throwable
authorizedPermissionRoles
public java.util.Collection<java.lang.String> authorizedPermissionRoles(java.lang.
String userName,
java.lang.
String permissionName)
throws java.lang.
Throwable
RBACReview
Description copied from interface: ReviewFunctions
Restituisce i nomi dei ruoli ereditati da un utente, ai quali è assegnato il permesso indicato
Specified by:
authorizedPermissionRoles in interface ReviewFunctions
Parameters:
userName - nome dell'utente
permissionName - nome del permesso
Returns:
elenco dei ruoli ereditati da un utente
Throws:
java.lang.Throwable
getMaxChildren
public int getMaxChildren()
throws java.lang.Throwable
Description copied from interface: ReviewFunctions
Calcola il numero massimo di ruoli figli presenti all'interno della gerarchia
Specified by:
getMaxChildren in interface ReviewFunctions
Returns:
numero massimo di ruoli figli
Throws:
java.lang.Throwable
getMaxParents
public int getMaxParents()
throws java.lang.Throwable
Description copied from interface: ReviewFunctions
Calcola il numero massimo di ruoli padri presenti all'interno della gerarchia
Specified by:
getMaxParents in interface ReviewFunctions
Returns:
numero massimo di ruoli padri
Throws:
java.lang.Throwable
getConflictingSSDRoles
public java.util.Collection<java.lang.String> getConflictingSSDRoles(java.lang.
RBACReview
String role)
throws java.lang.
Throwable
Description copied from interface: ReviewFunctions
Restituisce i nomi dei ruoli mutuamente esclusivi ad un ruolo secondo i vincoli SSD
Specified by:
getConflictingSSDRoles in interface ReviewFunctions
Parameters:
role - il nome del ruolo
Returns:
l'elenco dei ruoli mutuamenti esclusivi
Throws:
java.lang.Throwable
getConflictingDSDRoles
public java.util.Collection<java.lang.String> getConflictingDSDRoles(java.lang.
String role)
throws java.lang.
Throwable
Description copied from interface: ReviewFunctions
Restituisce i nomi dei ruoli mutuamente esclusivi ad un ruolo secondo i vincoli DSD
Specified by:
getConflictingDSDRoles in interface ReviewFunctions
Parameters:
role - il nome del ruolo
Returns:
l'elenco dei ruoli mutuamente esclusivi
Throws:
java.lang.Throwable
getFromTime
public java.lang.String getFromTime(java.lang.String role,
java.lang.String permission)
throws java.lang.Throwable
Description copied from interface: ReviewFunctions
Restituisce il limite inferiore del vincolo temporale
Specified by:
getFromTime in interface ReviewFunctions
Parameters:
role - ruolo del vincolo temporale
permission - permesso del vincolo temporale
RBACReview
Returns:
limite inferiore del vincolo temporale
Throws:
java.lang.Throwable
getToTime
public java.lang.String getToTime(java.lang.String role,
java.lang.String permission)
throws java.lang.Throwable
Description copied from interface: ReviewFunctions
Restituisce il limite superiore del vincolo temporale
Specified by:
getToTime in interface ReviewFunctions
Parameters:
role - ruolo del vincolo temporale
permission - permesso del vincolo temporale
Returns:
limite superiore del vincolo temporale
Throws:
java.lang.Throwable
getUsers
public java.util.Collection<java.lang.String> getUsers()
throws java.lang.Throwable
Specified by:
getUsers in interface ReviewFunctions
Throws:
java.lang.Throwable
getRoles
public java.util.Collection<java.lang.String> getRoles()
throws java.lang.Throwable
Description copied from interface: ReviewFunctions
Restituisce l'elenco dei ruoli
Specified by:
getRoles in interface ReviewFunctions
Returns:
l'elenco dei ruoli
Throws:
RBACReview
java.lang.Throwable
getPermissions
public java.util.Collection<java.lang.String> getPermissions()
throws java.lang.Throwable
Description copied from interface: ReviewFunctions
Restituisce l'elenco dei permessi
Specified by:
getPermissions in interface ReviewFunctions
Returns:
l'elenco dei permessi
Throws:
java.lang.Throwable
getDefaultRoles
public java.util.Collection<java.lang.String> getDefaultRoles()
throws java.lang.Throwable
Description copied from interface: ReviewFunctions
Restituisce l'elenco delle relazioni utente-ruolo_di_default
Specified by:
getDefaultRoles in interface ReviewFunctions
Returns:
l'elenco delle relazioni utente-ruolo_di_default
Throws:
java.lang.Throwable
getUAs
public java.util.Collection<java.lang.String> getUAs()
throws java.lang.Throwable
Description copied from interface: ReviewFunctions
Restituisce l'elenco delle relazioni utente-ruolo
Specified by:
getUAs in interface ReviewFunctions
Returns:
l'elenco delle relazioni utente-ruolo
Throws:
java.lang.Throwable
RBACReview
getPAs
public java.util.Collection<java.lang.String> getPAs()
throws java.lang.Throwable
Description copied from interface: ReviewFunctions
Restituisce l'elenco delle relazioni ruolo-permesso
Specified by:
getPAs in interface ReviewFunctions
Returns:
l'elenco delle relazioni ruolo-permesso
Throws:
java.lang.Throwable
getRHs
public java.util.Collection<java.lang.String> getRHs()
throws java.lang.Throwable
Description copied from interface: ReviewFunctions
Restituisce l'elenco delle relazioni gerarchiche
Specified by:
getRHs in interface ReviewFunctions
Returns:
l'elenco delle relazioni gerarchiche
Throws:
java.lang.Throwable
getSSDs
public java.util.Collection<java.lang.String> getSSDs()
throws java.lang.Throwable
Description copied from interface: ReviewFunctions
Restituisce l'elenco dei vincoli di SSD
Specified by:
getSSDs in interface ReviewFunctions
Returns:
l'elenco dei vincoli di SSD
Throws:
java.lang.Throwable
RBACReview
getDSDs
public java.util.Collection<java.lang.String> getDSDs()
throws java.lang.Throwable
Description copied from interface: ReviewFunctions
Restituisce l'elenco dei vincoli di DSD
Specified by:
getDSDs in interface ReviewFunctions
Returns:
l'elenco dei vincoli di DSD
Throws:
java.lang.Throwable
getTimes
public java.util.Collection<java.lang.String> getTimes()
throws java.lang.Throwable
Description copied from interface: ReviewFunctions
Restituisce l'elenco dei vincoli temporali
Specified by:
getTimes in interface ReviewFunctions
Returns:
l'elenco dei vincoli temporali
Throws:
java.lang.Throwable
getPermissionId
public java.lang.String getPermissionId(java.lang.String name)
throws java.lang.Throwable
Description copied from interface: ReviewFunctions
Restituisce l'id di un permesso dato il nome
Specified by:
getPermissionId in interface ReviewFunctions
Parameters:
name - il nome del permesso
Returns:
l'id del permesso
Throws:
java.lang.Throwable
RBACReview
getUserId
public java.lang.String getUserId(java.lang.String name)
throws java.lang.Throwable
Description copied from interface: ReviewFunctions
Restituisce l'id di un utente dato il nome
Specified by:
getUserId in interface ReviewFunctions
Parameters:
name - il nome dell'utente
Returns:
l'id dell'utente
Throws:
java.lang.Throwable
getRoleId
public java.lang.String getRoleId(java.lang.String name)
throws java.lang.Throwable
Description copied from interface: ReviewFunctions
Restituisce l'id di un ruolo dato il nome
Specified by:
getRoleId in interface ReviewFunctions
Parameters:
name - il nome del ruolo
Returns:
l'id del ruolo
Throws:
java.lang.Throwable
Overview Package Class Use Tree Deprecated Index Help
PREV CLASS NEXT CLASS
FRAMES
SUMMARY: NESTED | FIELD | CONSTR | METHOD
DETAIL: FIELD | CONSTR | METHOD
NO FRAMES
All Classes
ReviewFunctions
Overview Package Class Use Tree Deprecated Index Help
PREV CLASS NEXT CLASS
FRAMES
SUMMARY: NESTED | FIELD | CONSTR | METHOD
DETAIL: FIELD | CONSTR | METHOD
NO FRAMES
All Classes
it.unibs.carlotti.rbac.db
Interface ReviewFunctions
All Known Implementing Classes:
RBACReview
public interface ReviewFunctions
Questa interfaccia definisce le funzioni di reportistica del sistema RBAC
Author:
Giacomo Carlotti
Method Summary
java.util. assignedPermissionRoles(java.lang.String userName, java.lang.
Collection<java. String permissionName)
lang.String>
Restituisce i nomi dei ruoli assegnati ad un utente, ai quali è assegnato il permesso indicato
java.util. assignedRoles(java.lang.String userName)
Collection<java.
Restituisce i nomi dei ruoli assegnati direttamente ad un utente
lang.String>
java.util. authorizedPermissionRoles(java.lang.String userName, java.lang.
Collection<java. String permissionName)
lang.String>
Restituisce i nomi dei ruoli ereditati da un utente, ai quali è assegnato il permesso indicato
java.util. authorizedRoles(java.lang.String userName)
Collection<java.
Restituisce l'elenco dei ruoli autorizzati per un utente
lang.String>
java.util. defaultUserRoles(java.lang.String userName)
Collection<java.
Restituisce i nomi dei ruoli di default assegnati ad un utente
lang.String>
java.util. getConflictingDSDRoles(java.lang.String role)
Collection<java.
Restituisce i nomi dei ruoli mutuamente esclusivi ad un ruolo secondo i vincoli DSD
lang.String>
java.util. getConflictingSSDRoles(java.lang.String role)
Collection<java.
Restituisce i nomi dei ruoli mutuamente esclusivi ad un ruolo secondo i vincoli SSD
lang.String>
java.util. getDefaultRoles()
Collection<java.
Restituisce l'elenco delle relazioni utente-ruolo_di_default
lang.String>
java.util. getDSDs()
Collection<java.
Restituisce l'elenco dei vincoli di DSD
lang.String>
ReviewFunctions
java.lang. getFromTime(java.lang.String role, java.lang.String permission)
String
Restituisce il limite inferiore del vincolo temporale
int getMaxChildren()
Calcola il numero massimo di ruoli figli presenti all'interno della gerarchia
int getMaxParents()
Calcola il numero massimo di ruoli padri presenti all'interno della gerarchia
java.util. getPAs()
Collection<java.
Restituisce l'elenco delle relazioni ruolo-permesso
lang.String>
java.lang. getPermissionId(java.lang.String name)
String
Restituisce l'id di un permesso dato il nome
java.lang. getPermissionName(java.lang.String operation, java.lang.
String String object)
Restituisce il nome di un permesso dati i nomi dell'oggetto e dell'operazione
java.util. getPermissions()
Collection<java.
Restituisce l'elenco dei permessi
lang.String>
java.util. getRHs()
Collection<java.
Restituisce l'elenco delle relazioni gerarchiche
lang.String>
java.lang. getRoleId(java.lang.String name)
String
Restituisce l'id di un ruolo dato il nome
java.util. getRoles()
Collection<java.
Restituisce l'elenco dei ruoli
lang.String>
java.util. getSSDs()
Collection<java.
Restituisce l'elenco dei vincoli di SSD
lang.String>
java.util. getTimes()
Collection<java.
Restituisce l'elenco dei vincoli temporali
lang.String>
java.lang. getToTime(java.lang.String role, java.lang.String permission)
String
Restituisce il limite superiore del vincolo temporale
java.util. getUAs()
Collection<java.
Restituisce l'elenco delle relazioni utente-ruolo
lang.String>
java.lang. getUserId(java.lang.String name)
String
Restituisce l'id di un utente dato il nome
java.util. getUsers()
Collection<java.
lang.String>
Method Detail
getPermissionName
java.lang.String getPermissionName(java.lang.String operation,
ReviewFunctions
java.lang.String object)
throws java.lang.Throwable
Restituisce il nome di un permesso dati i nomi dell'oggetto e dell'operazione
Parameters:
operation - nome dell'operazione
object - nome dell'oggetto
Returns:
il nome del permesso
Throws:
java.lang.Throwable
assignedRoles
java.util.Collection<java.lang.String> assignedRoles(java.lang.String userName)
throws java.lang.Throwable
Restituisce i nomi dei ruoli assegnati direttamente ad un utente
Parameters:
userName - nome dell'utente
Returns:
elenco dei ruoli
Throws:
java.lang.Throwable
defaultUserRoles
java.util.Collection<java.lang.String> defaultUserRoles(java.lang.String userName)
throws java.lang.Throwable
Restituisce i nomi dei ruoli di default assegnati ad un utente
Parameters:
userName - nome dell'utente
Returns:
elenco dei ruoli di default
Throws:
java.lang.Throwable
assignedPermissionRoles
java.util.Collection<java.lang.String> assignedPermissionRoles(java.lang.
String userName,
java.lang.
String permissionName)
throws java.lang.
ReviewFunctions
Throwable
Restituisce i nomi dei ruoli assegnati ad un utente, ai quali è assegnato il permesso indicato
Parameters:
userName - nome dell'utente
permissionName - nome del permesso
Returns:
elenco dei nomi dei ruoli assegnati ad un utente
Throws:
java.lang.Throwable
authorizedRoles
java.util.Collection<java.lang.String> authorizedRoles(java.lang.String userName)
throws java.lang.Throwable
Restituisce l'elenco dei ruoli autorizzati per un utente
Parameters:
userName - nome dell'utente
Returns:
l'elenco dei ruoli autorizzati per un utente
Throws:
java.lang.Throwable
authorizedPermissionRoles
java.util.Collection<java.lang.String> authorizedPermissionRoles(java.lang.
String userName,
java.lang.
String permissionName)
throws java.lang.
Throwable
Restituisce i nomi dei ruoli ereditati da un utente, ai quali è assegnato il permesso indicato
Parameters:
userName - nome dell'utente
permissionName - nome del permesso
Returns:
elenco dei ruoli ereditati da un utente
Throws:
java.lang.Throwable
getMaxChildren
int getMaxChildren()
ReviewFunctions
throws java.lang.Throwable
Calcola il numero massimo di ruoli figli presenti all'interno della gerarchia
Returns:
numero massimo di ruoli figli
Throws:
java.lang.Throwable
getMaxParents
int getMaxParents()
throws java.lang.Throwable
Calcola il numero massimo di ruoli padri presenti all'interno della gerarchia
Returns:
numero massimo di ruoli padri
Throws:
java.lang.Throwable
getConflictingSSDRoles
java.util.Collection<java.lang.String> getConflictingSSDRoles(java.lang.String role)
throws java.lang.
Throwable
Restituisce i nomi dei ruoli mutuamente esclusivi ad un ruolo secondo i vincoli SSD
Parameters:
role - il nome del ruolo
Returns:
l'elenco dei ruoli mutuamenti esclusivi
Throws:
java.lang.Throwable
getConflictingDSDRoles
java.util.Collection<java.lang.String> getConflictingDSDRoles(java.lang.String role)
throws java.lang.
Throwable
Restituisce i nomi dei ruoli mutuamente esclusivi ad un ruolo secondo i vincoli DSD
Parameters:
role - il nome del ruolo
Returns:
l'elenco dei ruoli mutuamente esclusivi
ReviewFunctions
Throws:
java.lang.Throwable
getFromTime
java.lang.String getFromTime(java.lang.String role,
java.lang.String permission)
throws java.lang.Throwable
Restituisce il limite inferiore del vincolo temporale
Parameters:
role - ruolo del vincolo temporale
permission - permesso del vincolo temporale
Returns:
limite inferiore del vincolo temporale
Throws:
java.lang.Throwable
getToTime
java.lang.String getToTime(java.lang.String role,
java.lang.String permission)
throws java.lang.Throwable
Restituisce il limite superiore del vincolo temporale
Parameters:
role - ruolo del vincolo temporale
permission - permesso del vincolo temporale
Returns:
limite superiore del vincolo temporale
Throws:
java.lang.Throwable
getTimes
java.util.Collection<java.lang.String> getTimes()
throws java.lang.Throwable
Restituisce l'elenco dei vincoli temporali
Returns:
l'elenco dei vincoli temporali
Throws:
java.lang.Throwable
ReviewFunctions
getUsers
java.util.Collection<java.lang.String> getUsers()
throws java.lang.Throwable
Throws:
java.lang.Throwable
getRoles
java.util.Collection<java.lang.String> getRoles()
throws java.lang.Throwable
Restituisce l'elenco dei ruoli
Returns:
l'elenco dei ruoli
Throws:
java.lang.Throwable
getPermissions
java.util.Collection<java.lang.String> getPermissions()
throws java.lang.Throwable
Restituisce l'elenco dei permessi
Returns:
l'elenco dei permessi
Throws:
java.lang.Throwable
getDefaultRoles
java.util.Collection<java.lang.String> getDefaultRoles()
throws java.lang.Throwable
Restituisce l'elenco delle relazioni utente-ruolo_di_default
Returns:
l'elenco delle relazioni utente-ruolo_di_default
Throws:
java.lang.Throwable
getUAs
ReviewFunctions
java.util.Collection<java.lang.String> getUAs()
throws java.lang.Throwable
Restituisce l'elenco delle relazioni utente-ruolo
Returns:
l'elenco delle relazioni utente-ruolo
Throws:
java.lang.Throwable
getPAs
java.util.Collection<java.lang.String> getPAs()
throws java.lang.Throwable
Restituisce l'elenco delle relazioni ruolo-permesso
Returns:
l'elenco delle relazioni ruolo-permesso
Throws:
java.lang.Throwable
getRHs
java.util.Collection<java.lang.String> getRHs()
throws java.lang.Throwable
Restituisce l'elenco delle relazioni gerarchiche
Returns:
l'elenco delle relazioni gerarchiche
Throws:
java.lang.Throwable
getSSDs
java.util.Collection<java.lang.String> getSSDs()
throws java.lang.Throwable
Restituisce l'elenco dei vincoli di SSD
Returns:
l'elenco dei vincoli di SSD
Throws:
java.lang.Throwable
ReviewFunctions
getDSDs
java.util.Collection<java.lang.String> getDSDs()
throws java.lang.Throwable
Restituisce l'elenco dei vincoli di DSD
Returns:
l'elenco dei vincoli di DSD
Throws:
java.lang.Throwable
getPermissionId
java.lang.String getPermissionId(java.lang.String name)
throws java.lang.Throwable
Restituisce l'id di un permesso dato il nome
Parameters:
name - il nome del permesso
Returns:
l'id del permesso
Throws:
java.lang.Throwable
getUserId
java.lang.String getUserId(java.lang.String name)
throws java.lang.Throwable
Restituisce l'id di un utente dato il nome
Parameters:
name - il nome dell'utente
Returns:
l'id dell'utente
Throws:
java.lang.Throwable
getRoleId
java.lang.String getRoleId(java.lang.String name)
throws java.lang.Throwable
Restituisce l'id di un ruolo dato il nome
ReviewFunctions
Parameters:
name - il nome del ruolo
Returns:
l'id del ruolo
Throws:
java.lang.Throwable
Overview Package Class Use Tree Deprecated Index Help
PREV CLASS NEXT CLASS
FRAMES
SUMMARY: NESTED | FIELD | CONSTR | METHOD
DETAIL: FIELD | CONSTR | METHOD
NO FRAMES
All Classes
RBACDSD
Overview Package Class Use Tree Deprecated Index Help
PREV CLASS NEXT CLASS
SUMMARY: NESTED | FIELD | CONSTR | METHOD
FRAMES
NO FRAMES
All Classes
DETAIL: FIELD | CONSTR | METHOD
it.unibs.carlotti.rbac.dsd
Class RBACDSD
java.lang.Object
it.unibs.carlotti.rbac.dsd.RBACDSD
All Implemented Interfaces:
DynamicConstraint, EngineComponent
public class RBACDSD
extends java.lang.Object
implements DynamicConstraint
Componente DSD del motore dinamico
Author:
Giacomo Carlotti
Constructor Summary
RBACDSD(EngineComponent ec)
Method Summary
boolean activatePermission(java.lang.String roleName, java.lang.
String permissionName, java.lang.Object obj)
Attiva un permesso verificando eventuali vincoli
boolean addActiveRole(java.lang.String roleName, java.lang.
String idSession)
attiva un ruolo per una sessione utente, verificando gli eventuali vincoli
RBACDSD
boolean checkAccess(java.lang.String userName, java.lang.
String objectName, java.lang.String operation, java.lang.
String idSession, java.lang.Object obj)
controlla la disponibilità di un permesso per un certo utente e cerca di attivare un
ruolo a cui il permesso è associato
void createSession(java.lang.String id, java.lang.
String userName)
crea una nuova sessione utente ed prova ad attivare i ruoli di default
void deleteSession(java.lang.String id)
disattiva i ruoli della sessione e la elimina
boolean dropActiveRole(java.lang.String roleName, java.lang.
String idSession)
disattiva un ruolo di una sessione utente
Methods inherited from class java.lang.Object
clone, equals, finalize, getClass, hashCode, notify, notifyAll,
toString, wait, wait, wait
Constructor Detail
RBACDSD
public RBACDSD(EngineComponent ec)
Method Detail
activatePermission
public boolean activatePermission(java.lang.String roleName,
java.lang.String permissionName,
java.lang.Object obj)
Description copied from interface: EngineComponent
Attiva un permesso verificando eventuali vincoli
Specified by:
activatePermission in interface EngineComponent
Parameters:
RBACDSD
roleName - ruolo coinvolto nel vincolo
permissionName - permesso coinvolto nel vincolo
obj - reference all'ogggetto
Returns:
true il processo di attivazione va a buon fine, false altrimenti
addActiveRole
public boolean addActiveRole(java.lang.String roleName,
java.lang.String idSession)
Description copied from interface: EngineComponent
attiva un ruolo per una sessione utente, verificando gli eventuali vincoli
Specified by:
addActiveRole in interface EngineComponent
Parameters:
roleName - nome del ruolo
idSession - id della sessione
Returns:
true se riesce ad attivare il ruolo, false altrimenti
checkAccess
public boolean checkAccess(java.lang.String
java.lang.String
java.lang.String
java.lang.String
java.lang.Object
userName,
objectName,
operation,
idSession,
obj)
Description copied from interface: EngineComponent
controlla la disponibilità di un permesso per un certo utente e cerca di attivare un ruolo a cui il
permesso è associato
Specified by:
checkAccess in interface EngineComponent
Parameters:
userName - nome del ruolo
objectName - nome dell'oggetto
operation - nome dell'operazione
RBACDSD
idSession - id della sessione
obj - reference dell'oggetto
Returns:
true il processo di attivazione va a buon fine, false altrimenti
createSession
public void createSession(java.lang.String id,
java.lang.String userName)
Description copied from interface: EngineComponent
crea una nuova sessione utente ed prova ad attivare i ruoli di default
Specified by:
createSession in interface EngineComponent
Parameters:
id - id della sessione
userName - nome dell'utente
deleteSession
public void deleteSession(java.lang.String id)
Description copied from interface: EngineComponent
disattiva i ruoli della sessione e la elimina
Specified by:
deleteSession in interface EngineComponent
Parameters:
id - id della sessione
dropActiveRole
public boolean dropActiveRole(java.lang.String roleName,
java.lang.String idSession)
Description copied from interface: EngineComponent
RBACDSD
disattiva un ruolo di una sessione utente
Specified by:
dropActiveRole in interface EngineComponent
Parameters:
roleName - nome del ruolo
idSession - id della sessione
Returns:
true se riesce a disattivare il ruolo, false altrimenti
Overview Package Class Use Tree Deprecated Index Help
PREV CLASS NEXT CLASS
SUMMARY: NESTED | FIELD | CONSTR | METHOD
FRAMES
NO FRAMES
All Classes
DETAIL: FIELD | CONSTR | METHOD
RBACHierarchyDynamic
Overview Package Class Use Tree Deprecated Index Help
PREV CLASS NEXT CLASS
FRAMES
SUMMARY: NESTED | FIELD | CONSTR | METHOD
DETAIL: FIELD | CONSTR | METHOD
NO FRAMES
All Classes
it.unibs.carlotti.rbac.hierarchy
Class RBACHierarchyDynamic
java.lang.Object
it.unibs.carlotti.rbac.hierarchy.RBACHierarchyDynamic
All Implemented Interfaces:
DynamicConstraint, EngineComponent
public class RBACHierarchyDynamic
extends java.lang.Object
implements DynamicConstraint
Componente Hierarchy del motore dinamico
Author:
Giacomo Carlotti
Constructor Summary
RBACHierarchyDynamic(EngineComponent _ec)
Method Summary
boolean activatePermission(java.lang.String roleName, java.lang.
String permissionName, java.lang.Object obj)
Attiva un permesso verificando eventuali vincoli
boolean addActiveRole(java.lang.String roleName, java.lang.
String idSession)
attiva un ruolo per una sessione utente, verificando gli eventuali vincoli
RBACHierarchyDynamic
boolean checkAccess(java.lang.String userName, java.lang.
String objectName, java.lang.String operation, java.lang.
String idSession, java.lang.Object obj)
controlla la disponibilità di un permesso per un certo utente e cerca di attivare un
ruolo a cui il permesso è associato
void createSession(java.lang.String id, java.lang.
String userName)
crea una nuova sessione utente ed prova ad attivare i ruoli di default
void deleteSession(java.lang.String id)
disattiva i ruoli della sessione e la elimina
boolean dropActiveRole(java.lang.String roleName, java.lang.
String idSession)
disattiva un ruolo di una sessione utente
Methods inherited from class java.lang.Object
clone, equals, finalize, getClass, hashCode, notify, notifyAll,
toString, wait, wait, wait
Constructor Detail
RBACHierarchyDynamic
public RBACHierarchyDynamic(EngineComponent _ec)
Method Detail
activatePermission
public boolean activatePermission(java.lang.String roleName,
java.lang.String permissionName,
java.lang.Object obj)
Description copied from interface: EngineComponent
Attiva un permesso verificando eventuali vincoli
Specified by:
activatePermission in interface EngineComponent
Parameters:
RBACHierarchyDynamic
roleName - ruolo coinvolto nel vincolo
permissionName - permesso coinvolto nel vincolo
obj - reference all'ogggetto
Returns:
true il processo di attivazione va a buon fine, false altrimenti
addActiveRole
public boolean addActiveRole(java.lang.String roleName,
java.lang.String idSession)
Description copied from interface: EngineComponent
attiva un ruolo per una sessione utente, verificando gli eventuali vincoli
Specified by:
addActiveRole in interface EngineComponent
Parameters:
roleName - nome del ruolo
idSession - id della sessione
Returns:
true se riesce ad attivare il ruolo, false altrimenti
checkAccess
public boolean checkAccess(java.lang.String
java.lang.String
java.lang.String
java.lang.String
java.lang.Object
userName,
objectName,
operation,
idSession,
obj)
Description copied from interface: EngineComponent
controlla la disponibilità di un permesso per un certo utente e cerca di attivare un ruolo a cui il
permesso è associato
Specified by:
checkAccess in interface EngineComponent
Parameters:
userName - nome del ruolo
objectName - nome dell'oggetto
operation - nome dell'operazione
RBACHierarchyDynamic
idSession - id della sessione
obj - reference dell'oggetto
Returns:
true il processo di attivazione va a buon fine, false altrimenti
createSession
public void createSession(java.lang.String id,
java.lang.String userName)
Description copied from interface: EngineComponent
crea una nuova sessione utente ed prova ad attivare i ruoli di default
Specified by:
createSession in interface EngineComponent
Parameters:
id - id della sessione
userName - nome dell'utente
deleteSession
public void deleteSession(java.lang.String id)
Description copied from interface: EngineComponent
disattiva i ruoli della sessione e la elimina
Specified by:
deleteSession in interface EngineComponent
Parameters:
id - id della sessione
dropActiveRole
public boolean dropActiveRole(java.lang.String roleName,
java.lang.String idSession)
Description copied from interface: EngineComponent
RBACHierarchyDynamic
disattiva un ruolo di una sessione utente
Specified by:
dropActiveRole in interface EngineComponent
Parameters:
roleName - nome del ruolo
idSession - id della sessione
Returns:
true se riesce a disattivare il ruolo, false altrimenti
Overview Package Class Use Tree Deprecated Index Help
PREV CLASS NEXT CLASS
FRAMES
SUMMARY: NESTED | FIELD | CONSTR | METHOD
DETAIL: FIELD | CONSTR | METHOD
NO FRAMES
All Classes
RBACHierarchyStatic
Overview Package Class Use Tree Deprecated Index Help
PREV CLASS NEXT CLASS
FRAMES
SUMMARY: NESTED | FIELD | CONSTR | METHOD
DETAIL: FIELD | CONSTR | METHOD
NO FRAMES
All Classes
it.unibs.carlotti.rbac.hierarchy
Class RBACHierarchyStatic
java.lang.Object
it.unibs.carlotti.rbac.hierarchy.RBACHierarchyStatic
All Implemented Interfaces:
IntegrityComponent, StaticConstraint
public class RBACHierarchyStatic
extends java.lang.Object
implements StaticConstraint
Componente Hierarchy del motore statico
Author:
Giacomo Carlotti
Constructor Summary
RBACHierarchyStatic(IntegrityComponent _ic)
Method Summary
void checkIntegrity()
- controlla che i ruoli di default di un utente siano tra quelli ereditati
Methods inherited from class java.lang.Object
clone, equals, finalize, getClass, hashCode, notify, notifyAll,
toString, wait, wait, wait
RBACHierarchyStatic
Constructor Detail
RBACHierarchyStatic
public RBACHierarchyStatic(IntegrityComponent _ic)
Method Detail
checkIntegrity
public void checkIntegrity()
throws java.lang.Throwable
- controlla che i ruoli di default di un utente siano tra quelli ereditati
Specified by:
checkIntegrity in interface IntegrityComponent
Throws:
java.lang.Throwable
Overview Package Class Use Tree Deprecated Index Help
PREV CLASS NEXT CLASS
FRAMES
SUMMARY: NESTED | FIELD | CONSTR | METHOD
DETAIL: FIELD | CONSTR | METHOD
NO FRAMES
All Classes
RBACLimitedHierarchy
Overview Package Class Use Tree Deprecated Index Help
PREV CLASS NEXT CLASS
FRAMES
SUMMARY: NESTED | FIELD | CONSTR | METHOD
DETAIL: FIELD | CONSTR | METHOD
NO FRAMES
All Classes
it.unibs.carlotti.rbac.hierarchy
Class RBACLimitedHierarchy
java.lang.Object
it.unibs.carlotti.rbac.hierarchy.RBACLimitedHierarchy
All Implemented Interfaces:
IntegrityComponent, StaticConstraint
public class RBACLimitedHierarchy
extends java.lang.Object
implements StaticConstraint
Componente LimitedHierarchy del motore statico
Author:
Giacomo Carlotti
Constructor Summary
RBACLimitedHierarchy(IntegrityComponent _ic)
Method Summary
void checkIntegrity()
Controlla i vincoli statici di integrità del sistema
Methods inherited from class java.lang.Object
clone, equals, finalize, getClass, hashCode, notify, notifyAll,
toString, wait, wait, wait
RBACLimitedHierarchy
Constructor Detail
RBACLimitedHierarchy
public RBACLimitedHierarchy(IntegrityComponent _ic)
throws java.lang.Throwable
Throws:
java.lang.Throwable
Method Detail
checkIntegrity
public void checkIntegrity()
throws java.lang.Throwable
Description copied from interface: IntegrityComponent
Controlla i vincoli statici di integrità del sistema
Specified by:
checkIntegrity in interface IntegrityComponent
Throws:
java.lang.Throwable
Overview Package Class Use Tree Deprecated Index Help
PREV CLASS NEXT CLASS
FRAMES
SUMMARY: NESTED | FIELD | CONSTR | METHOD
DETAIL: FIELD | CONSTR | METHOD
NO FRAMES
All Classes
RBACSSD
Overview Package Class Use Tree Deprecated Index Help
PREV CLASS NEXT CLASS
SUMMARY: NESTED | FIELD | CONSTR | METHOD
FRAMES
NO FRAMES
All Classes
DETAIL: FIELD | CONSTR | METHOD
it.unibs.carlotti.rbac.ssd
Class RBACSSD
java.lang.Object
it.unibs.carlotti.rbac.ssd.RBACSSD
All Implemented Interfaces:
IntegrityComponent, StaticConstraint
public class RBACSSD
extends java.lang.Object
implements StaticConstraint
Componente SSD del motore statico
Author:
Giacomo Carlotti
Constructor Summary
RBACSSD(IntegrityComponent ic, boolean hierarchical)
Method Summary
void checkIntegrity()
Controlla i vincoli statici di integrità del sistema
Methods inherited from class java.lang.Object
clone, equals, finalize, getClass, hashCode, notify, notifyAll,
toString, wait, wait, wait
RBACSSD
Constructor Detail
RBACSSD
public RBACSSD(IntegrityComponent ic,
boolean hierarchical)
Method Detail
checkIntegrity
public void checkIntegrity()
throws java.lang.Throwable
Description copied from interface: IntegrityComponent
Controlla i vincoli statici di integrità del sistema
Specified by:
checkIntegrity in interface IntegrityComponent
Throws:
java.lang.Throwable
Overview Package Class Use Tree Deprecated Index Help
PREV CLASS NEXT CLASS
SUMMARY: NESTED | FIELD | CONSTR | METHOD
FRAMES
NO FRAMES
All Classes
DETAIL: FIELD | CONSTR | METHOD
RBACTime
Overview Package Class Use Tree Deprecated Index Help
PREV CLASS NEXT CLASS
SUMMARY: NESTED | FIELD | CONSTR | METHOD
FRAMES
NO FRAMES
All Classes
DETAIL: FIELD | CONSTR | METHOD
it.unibs.carlotti.rbac.time
Class RBACTime
java.lang.Object
it.unibs.carlotti.rbac.time.RBACTime
All Implemented Interfaces:
DynamicConstraint, EngineComponent
public class RBACTime
extends java.lang.Object
implements DynamicConstraint
Componente Time del motore dinamico
Author:
Giacomo Carlotti
Constructor Summary
RBACTime(EngineComponent ec)
Method Summary
boolean activatePermission(java.lang.String roleName, java.lang.
String permissionName, java.lang.Object obj)
Attiva un permesso verificando eventuali vincoli
boolean addActiveRole(java.lang.String roleName, java.lang.
String idSession)
attiva un ruolo per una sessione utente, verificando gli eventuali vincoli
RBACTime
boolean checkAccess(java.lang.String userName, java.lang.
String objectName, java.lang.String operation, java.lang.
String idSession, java.lang.Object obj)
controlla la disponibilità di un permesso per un certo utente e cerca di attivare un
ruolo a cui il permesso è associato
void createSession(java.lang.String id, java.lang.
String userName)
crea una nuova sessione utente ed prova ad attivare i ruoli di default
void deleteSession(java.lang.String id)
disattiva i ruoli della sessione e la elimina
boolean dropActiveRole(java.lang.String roleName, java.lang.
String idSession)
disattiva un ruolo di una sessione utente
Methods inherited from class java.lang.Object
clone, equals, finalize, getClass, hashCode, notify, notifyAll,
toString, wait, wait, wait
Constructor Detail
RBACTime
public RBACTime(EngineComponent ec)
Method Detail
createSession
public void createSession(java.lang.String id,
java.lang.String userName)
Description copied from interface: EngineComponent
crea una nuova sessione utente ed prova ad attivare i ruoli di default
Specified by:
createSession in interface EngineComponent
Parameters:
id - id della sessione
RBACTime
userName - nome dell'utente
deleteSession
public void deleteSession(java.lang.String id)
Description copied from interface: EngineComponent
disattiva i ruoli della sessione e la elimina
Specified by:
deleteSession in interface EngineComponent
Parameters:
id - id della sessione
addActiveRole
public boolean addActiveRole(java.lang.String roleName,
java.lang.String idSession)
Description copied from interface: EngineComponent
attiva un ruolo per una sessione utente, verificando gli eventuali vincoli
Specified by:
addActiveRole in interface EngineComponent
Parameters:
roleName - nome del ruolo
idSession - id della sessione
Returns:
true se riesce ad attivare il ruolo, false altrimenti
dropActiveRole
public boolean dropActiveRole(java.lang.String roleName,
java.lang.String idSession)
Description copied from interface: EngineComponent
disattiva un ruolo di una sessione utente
RBACTime
Specified by:
dropActiveRole in interface EngineComponent
Parameters:
roleName - nome del ruolo
idSession - id della sessione
Returns:
true se riesce a disattivare il ruolo, false altrimenti
checkAccess
public boolean checkAccess(java.lang.String
java.lang.String
java.lang.String
java.lang.String
java.lang.Object
userName,
objectName,
operation,
idSession,
obj)
Description copied from interface: EngineComponent
controlla la disponibilità di un permesso per un certo utente e cerca di attivare un ruolo a cui il
permesso è associato
Specified by:
checkAccess in interface EngineComponent
Parameters:
userName - nome del ruolo
objectName - nome dell'oggetto
operation - nome dell'operazione
idSession - id della sessione
obj - reference dell'oggetto
Returns:
true il processo di attivazione va a buon fine, false altrimenti
activatePermission
public boolean activatePermission(java.lang.String roleName,
java.lang.String permissionName,
java.lang.Object obj)
Description copied from interface: EngineComponent
Attiva un permesso verificando eventuali vincoli
RBACTime
Specified by:
activatePermission in interface EngineComponent
Parameters:
roleName - ruolo coinvolto nel vincolo
permissionName - permesso coinvolto nel vincolo
obj - reference all'ogggetto
Returns:
true il processo di attivazione va a buon fine, false altrimenti
Overview Package Class Use Tree Deprecated Index Help
PREV CLASS NEXT CLASS
SUMMARY: NESTED | FIELD | CONSTR | METHOD
FRAMES
NO FRAMES
All Classes
DETAIL: FIELD | CONSTR | METHOD
WebFilter
Overview Package Class Use Tree Deprecated Index Help
PREV CLASS NEXT CLASS
FRAMES
SUMMARY: NESTED | FIELD | CONSTR | METHOD
DETAIL: FIELD | CONSTR | METHOD
NO FRAMES
All Classes
it.unibs.carlotti.rbac.web
Class WebFilter
java.lang.Object
it.unibs.carlotti.rbac.web.WebFilter
All Implemented Interfaces:
javax.servlet.Filter
public class WebFilter
extends java.lang.Object
implements javax.servlet.Filter
Questa classe permette di intercettare le chiamate alle risorse del web server ed eseguire i controlli
dei vincoli dinamici del sistema RBAC
Author:
Giacomo Carlotti
Constructor Summary
WebFilter()
Method Summary
void destroy()
void doFilter(javax.servlet.ServletRequest arg0, javax.servlet.
ServletResponse arg1, javax.servlet.FilterChain arg2)
WebFilter
void init(javax.servlet.FilterConfig arg0)
Methods inherited from class java.lang.Object
clone, equals, finalize, getClass, hashCode, notify, notifyAll,
toString, wait, wait, wait
Constructor Detail
WebFilter
public WebFilter()
Method Detail
init
public void init(javax.servlet.FilterConfig arg0)
throws javax.servlet.ServletException
Specified by:
init in interface javax.servlet.Filter
Throws:
javax.servlet.ServletException
doFilter
public void doFilter(javax.servlet.ServletRequest arg0,
javax.servlet.ServletResponse arg1,
javax.servlet.FilterChain arg2)
throws java.io.IOException,
javax.servlet.ServletException
Specified by:
doFilter in interface javax.servlet.Filter
Throws:
java.io.IOException
javax.servlet.ServletException
WebFilter
destroy
public void destroy()
Specified by:
destroy in interface javax.servlet.Filter
Overview Package Class Use Tree Deprecated Index Help
PREV CLASS NEXT CLASS
FRAMES
SUMMARY: NESTED | FIELD | CONSTR | METHOD
DETAIL: FIELD | CONSTR | METHOD
NO FRAMES
All Classes
WebPlugin
Overview Package Class Use Tree Deprecated Index Help
PREV CLASS NEXT CLASS
FRAMES
SUMMARY: NESTED | FIELD | CONSTR | METHOD
DETAIL: FIELD | CONSTR | METHOD
NO FRAMES
All Classes
it.unibs.carlotti.rbac.web
Class WebPlugin
java.lang.Object
it.unibs.carlotti.rbac.web.WebPlugin
All Implemented Interfaces:
java.util.EventListener, javax.servlet.http.HttpSessionListener
public class WebPlugin
extends java.lang.Object
implements javax.servlet.http.HttpSessionListener
Questa classe intercetta gli eventi di creazione e distruzione delle sessioni http degli utenti e permette di
istanziare e distruggere le corrispondenti sessioni del sistema RBAC
Author:
Giacomo Carlotti
Constructor Summary
WebPlugin()
Method Summary
void sessionCreated(javax.servlet.http.HttpSessionEvent arg0)
void sessionDestroyed(javax.servlet.http.HttpSessionEvent arg0)
Methods inherited from class java.lang.Object
WebPlugin
clone, equals, finalize, getClass, hashCode, notify, notifyAll,
toString, wait, wait, wait
Constructor Detail
WebPlugin
public WebPlugin()
Method Detail
sessionCreated
public void sessionCreated(javax.servlet.http.HttpSessionEvent arg0)
Specified by:
sessionCreated in interface javax.servlet.http.HttpSessionListener
sessionDestroyed
public void sessionDestroyed(javax.servlet.http.HttpSessionEvent arg0)
Specified by:
sessionDestroyed in interface javax.servlet.http.
HttpSessionListener
Overview Package Class Use Tree Deprecated Index Help
PREV CLASS NEXT CLASS
FRAMES
SUMMARY: NESTED | FIELD | CONSTR | METHOD
DETAIL: FIELD | CONSTR | METHOD
NO FRAMES
All Classes
APPENDICE B.1
Diagrammi UML dei
packages
APPENDICE B.2
Diagrammi UML delle classi