Progetto e realizzazione di un linguaggio formale per il...

U N I V E R S I TÀ D E G L I S T U D I D I F I R E N Z EFacoltà di Scienze Matematiche, Fisiche e Naturali

Corso di Laurea Magistrale in Informatica

Tesi di Laurea

P R O G E T T O E R E A L I Z Z A Z I O N E D I U N L I N G U A G G I OF O R M A L E P E R I L C O N T R O L L O D E G L I A C C E S S I

B A S AT O S U P O L I T I C H E

andrea margheri

Relatore: Prof. Rosario Pugliese

Correlatore: Dott. Francesco Tiezzi

Anno Accademico 2011-2012

Andrea Margheri: Progetto e realizzazione di un linguaggio formale per il control-lo degli accessi basato su politiche, Corso di Laurea Magistrale in Informatica, ©Anno Accademico 2011-2012

Non trovare il difetto,trova il rimedio.

Un sentito ringraziamento al Prof. Pugliese e al Dott. Francesco Tiezzi per avermiseguito e guidato nel mondo di XACML per tutti questi mesi di lavoro. Un sentitoringraziamento anche al Dott. Massimiliano Masi per il prezioso supporto durante illavoro di tesi.

Grazie alla mia famiglia per il supporto durante questi anni di studi e a tutti i colleghidel corso magistrale per due bellissimi anni assieme.

I N D I C E

1 introduzione 3

2 controllo degli accessi 5

2.1 Modelli per il controllo degli accessi . . . . . . . . . . . . . . . . . 5

2.2 XACML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.2.1 Il processo di autorizzazione . . . . . . . . . . . . . . . . . 9

2.2.2 Il linguaggio delle politiche . . . . . . . . . . . . . . . . . . 12

2.2.3 Standard collegati a XACML . . . . . . . . . . . . . . . . . 15

2.3 Caso di studio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.3.1 Il progetto epSOS . . . . . . . . . . . . . . . . . . . . . . . . 16

3 sintassi e semantica di xacml 21

3.1 Sintassi di XACML . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.1.1 Politiche e Insiemi di Politiche . . . . . . . . . . . . . . . . 21

3.1.2 Regole . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3.1.3 Target . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3.1.4 Obbligazioni . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

3.1.5 Richieste e Risposte . . . . . . . . . . . . . . . . . . . . . . 28

3.1.6 Politiche del caso di studio . . . . . . . . . . . . . . . . . . 30

3.2 Semantica di XACML . . . . . . . . . . . . . . . . . . . . . . . . . 35

3.2.1 Target . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

3.2.2 Rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

3.2.3 Policy e Policy Set . . . . . . . . . . . . . . . . . . . . . . . 38

3.2.4 Obligation e Advice . . . . . . . . . . . . . . . . . . . . . . 42

3.2.5 Policy Enforcement Point . . . . . . . . . . . . . . . . . . . 43

3.2.6 Valutazione delle politiche del caso di studio . . . . . . . . 44

3.3 Multiple Decision Profile . . . . . . . . . . . . . . . . . . . . . . . . 44

4 un linguaggio formale per il controllo degli accessi 47

4.1 Sintassi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

4.2 Traduzione delle politiche del caso di studio . . . . . . . . . . . . 51

4.3 Semantica formale . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

4.3.1 Target . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

4.3.2 Obbligazioni . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

4.3.3 Regole, Politiche e Insiemi di Politiche . . . . . . . . . . . 58

4.3.4 Policy Enforcement Point . . . . . . . . . . . . . . . . . . . 62

4.4 Valutazione formale delle richieste del caso di studio . . . . . . . 66

5 ambiente di valutazione e strumenti di sviluppo 69

5.1 Ambiente di valutazione . . . . . . . . . . . . . . . . . . . . . . . . 69

5.1.1 Test di conformità . . . . . . . . . . . . . . . . . . . . . . . 76

5.2 Strumenti di sviluppo . . . . . . . . . . . . . . . . . . . . . . . . . 76

1

2 Indice

5.2.1 Introduzione al framework Xtext . . . . . . . . . . . . . . . 77

5.2.2 Plugin per Eclipse . . . . . . . . . . . . . . . . . . . . . . . 78

5.3 Applicazione al caso di studio . . . . . . . . . . . . . . . . . . . . 79

6 conclusioni 87

6.1 Sviluppi futuri . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

6.2 Lavori collegati . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

a funzioni di match e linguaggio per le espressioni 91

b richieste d’accesso per il caso di studio 95

1I N T R O D U Z I O N E

La diffusione di servizi web e di piattaforme di lavoro distribuite ha generatosistemi sempre più connessi e integrati tra loro. Per proteggere le informazionisensibili, spesso gestite da questi sistemi, servono tra l’altro strumenti adeguatiper il controllo degli accessi. La grande attenzione riservata a queste tematiche,ha portato allo sviluppo di nuovi modelli e tecnologie per la gestione degliaccessi.

Un modello di controllo degli accessi è basato su regole d’accesso che deter-minano, in base a varie tipologie di controlli, chi ha il permesso di fare certeazioni sulle risorse controllate. Nel corso degli anni sono stati proposti diver-si modelli per far fronte alle problematiche emerse con lo sviluppo di nuovetecnologie, quali appunto i sistemi distribuiti su larga scala. L’evoluzione deimodelli non ha apportato variazioni al tipo di accessi che si possono controllare,ma all’espressività dei linguaggi per la definizione delle regole.

I primi modelli di controllo erano basati su liste degli accessi, che associavanoa ogni risorsa una lista con tutti gli utenti che potevano effettuare operazioni.L’approccio era semplice, ma la quantità di dati da gestire era eccessiva, nonpermettendo al modello di scalare in sistemi di grandi dimensione. L’introdu-zione del modello basato su ruoli, cioè l’associazione di insiemi di risorse asoggetti raggruppati per ruolo, ha migliorato la scalabilità. La definizione deiruoli ha però come difetto che le regole sono meno specifiche, quindi difficilida applicare per singole risorse. Maggiore flessibilità nella definizione delle re-gole di accesso è stata possibile con l’introduzione del modello ad attributi, chedefinisce le regole sulla base di insiemi di caratteristiche di qualunque catego-ria, senza specializzarsi soltanto sui ruoli. Il modello ad attributi però non offreuna buona scalabilità, dato che non c’è una tecnica specifica di definizione eorganizzazione delle regole. Questo ha portato al modello delle politiche, cioèa insiemi organizzati di regole su attributi. Attualmente, il modello basato supolitiche è il più utilizzato.

La necessità di integrazione e collaborazione tra sistemi ha portato alla ri-chiesta di standard per la definizione del modello basato su politiche. Moltistandard sono stati proposti e attualmente quello più utilizzato è eXtensibleAccess Control Markup Language (XACML), che fornisce un linguaggio per la

3

4 introduzione

definizione delle politiche e i requisiti funzionali per una corretta valutazionedelle stesse. L’utilizzo di XML per la sintassi permette allo standard di essereapplicato in svariati contesti, a discapito però di una facile specifica e manuten-zione delle politiche. Inoltre, i requisiti funzionali, e più in generale il processodi valutazione degli accessi, sono descritti in linguaggio informale, prestando-si così a interpretazioni differenti su certi aspetti dei requisiti. Questo fatto èanche confermato dalla presenza di differenze in alcuni tool esistenti per lavalutazione di politiche XACML.

Sulla base delle suddette considerazioni è nata l’idea del lavoro sviluppatoin questa tesi: semplificare la scrittura delle politiche e definire una semanticaformale per il processo di valutazione delle richieste d’accesso rispetto alle poli-tiche. Nel dettaglio, si propone un linguaggio fortemente basato su XACML, madefinito su una sintassi alternativa, che permette la definizione della semanticaformale del processo di valutazione.

L’utilizzo della semantica formale elimina anche l’ambiguità, introdotta dal-l’utilizzo del linguaggio naturale, del documento di specifica dello standardXACML. Inoltre, la semantica offre anche la possibilità di definire controllisulle politiche, per assicurarsi che l’effetto globale definito dalle politiche siaeffettivamente quello richiesto dai requisiti di sicurezza.

La sola definizione del linguaggio non è però uno strumento utilizzabile incasi reali. Si è quindi deciso di definire un’architettura Java che implementiil processo di valutazione e uno strumento di sviluppo per il supporto allascrittura delle politiche.

Il resto di questo documento è così organizzato. Nel Capitolo 2, dopo unabreve introduzione ai modelli di controllo degli accessi, si descrive il model-lo delle politiche definito in XACML e il rispettivo processo autorizzativo. Permeglio descrivere le caratteristiche dello standard e del nostro linguaggio, siintroduce, sempre nel Capitolo 2, un caso di studio medico ispirato a un pro-getto europeo per l’integrazione di sistemi sanitari nazionali. Nel Capitolo 3

è presentato in dettaglio lo standard, sia negli aspetti sintattici che semantici.Nel Capitolo 4 si descrive il linguaggio alternativo e la semantica formale peril processo autorizzativo. L’architettura di valutazione e gli altri strumenti disupporto sono invece illustrati nel Capitolo 5. Il documento si conclude poi conil Capitolo 6 dove sono riportati brevemente alcuni lavori collegati a XACML e ipossibili sviluppi futuri del lavoro svolto.

2C O N T R O L L O D E G L I A C C E S S I

Il controllo degli accessi a risorse e servizi è un aspetto fondamentale in ogniarchitettura software, al fine di assicurare l’integrità e la sicurezza dei dati. Stan-dard e architetture specifiche sono stati sviluppati nel corso degli anni, renden-do quest’area di ricerca sempre in continuo sviluppo. Per meglio comprendereil problema del controllo degli accessi descriviamo nella sezione seguente l’evo-luzione storica dei modelli di controllo e successivamente presentiamo in det-taglio il modello basato su politiche utilizzato dallo standard eXtensible AccessControl Markup Language (XACML). A seguire, è introdotto il caso di studio chesarà utilizzato in tutto il resto della tesi per esemplificare gli argomenti trattati.

2.1 modelli per il controllo degli accessi

Le informazioni gestite dai computer sono un bene di vitale importanza perogni azienda, sia essa pubblica o privata. La perdita di informazioni riserva-te può comportare perdita di competitività sul mercato o in caso di dati con-fidenziali, come informazioni sanitarie, dar luogo a reati perseguibili anchepenalmente. Lo sviluppo di sistemi informatici che collaborano tra loro poneall’attenzione anche un ulteriore problema: come far collaborare sistemi di sicu-rezza. Il crescere della complessità dei sistemi, della quantità di dati da gestiree dei meccanismi di condivisione delle informazioni, ha portato i modelli dicontrollo degli accessi ad evolvere nel tempo.

La letteratura in merito a questi modelli non fa riferimento a un unico e con-diviso dizionario delle definizioni e degli acronimi. In molti articoli, le stessesigle possono avere significati completamente diversi, ad esempio la sigla ABAC

in [10] non rappresenta Attribute Based Access Control, significato comune-mente diffuso, ma Authorization Based Access Control. Inoltre, vari documentisono in contrasto tra loro sulla definizione del modello basato su politiche e ledifferenze rispetto alla versione basata su attributi. Per seguire un’unica lineaguida, la descrizione dei modelli riportata in questa sezione segue la panora-mica offerta dal National Institute of Standards and Technology (NIST) in [15]. Si èscelto questo documento perché rilasciato da un’agenzia adibita alla gestione ealla promozione di standard tecnologici per l’industria americana, riconosciuta

5

6 controllo degli accessi

a livello internazionale per il suo operato. Questa descrizione, inoltre, corri-sponde al nostro punto di vista sull’evoluzione dei modelli. Vediamo adesso lecaratteristiche principali delle soluzioni proposte.

I primi modelli di controllo degli accessi sono stati modelli discrezionali,Discretionary Access Control (DAC), dove l’accesso alle risorse è basato unica-mente sull’identità del soggetto o del gruppo, e dei diritti che esso possiede sul-la risorsa. Il capostipite di questi modelli è il metodo Access Control Lists (ACL)che consiste nella forma più elementare di controllo degli accessi: ogni risorsacontrollata ha associata una lista di soggetti con le possibili azioni da eseguiresu tale risorsa. Questo modello ha il vantaggio di definire un controllo moltofine sulle risorse e non richiede specifiche infrastrutture tecnologiche per essererealizzato. Per questo motivo fu tra i primi metodi ad essere supportato diret-tamente nei sistemi operativi. La dettagliata definizione delle regole di accessoè però causa di notevoli svantaggi, come l’alto numero di controlli necessariquando si accede a molte risorse contemporaneamente e la grande quantità didati da conservare. Queste caratteristiche non permettono quindi al metodo discalare facilmente all’aumentare delle risorse e degli utenti.

Il passo successivo nello sviluppo è stato quello di definire il modello in baseal ruolo che un utente ha nel sistema, e quindi definire l’accesso alle risorsein base ai ruoli: il modello Role Based Access Control (RBAC). Questo model-lo sopperisce alla carenza principale di limitata scalabilità di ACL, visto chepiù persone possono avere lo stesso ruolo e di conseguenza accedere alle stes-se risorse. I diritti di accesso sono definiti per il ruolo e permettono di creareuna struttura gerarchica tra i ruoli, così da ereditare i diritti del predecessoree strutturare i permessi. Dal punto di vista delle implementazioni, un limita-to modello RBAC è presente in tutti gli attuali sistemi operativi, pensiamo adesempio al ruolo Administrator in Windows o a root nei sistemi Unix. A livellodi reti aziendali, invece, si ha la necessità di infrastrutture apposite per la con-divisione dei ruoli e dei relativi diritti, ma ormai sono molte le piattaforme cheoffrono questi servizi. La maggior scalabilità del modello, dovuta alla presen-za dei ruoli, ha però aumentato la granularità dell’approccio; per assegnare apersone specifiche poche risorse è sempre necessario definire un nuovo ruolo.Utilizzando la versione gerarchica è possibile definire vari sotto-ruoli, ma nonpermettono comunque una facile identificazione dei singoli utenti.

Il controllo degli accessi non può basarsi soltanto su ruoli, visti i problemi digranularità, ma si deve affidare a più valori diversi: gli attributi. Gli attributi so-no un insieme di caratteristiche associate al richiedente, all’azione da eseguiree alla risorsa stessa. Questo modello prende il nome di Attribute Based AccessControl (ABAC). La richiesta di accesso fornisce al gestore degli accessi, diret-tamente o indirettamente, una serie di attributi necessari per valutare l’esitofinale dell’autorizzazione. Le regole possono essere definite per una qualsiasicombinazione di attributi, offrendo la possibilità di creare regole specifiche per

2.1 modelli per il controllo degli accessi 7

certe risorse o approcci più generali sullo stile del modello RBAC, consideran-do il ruolo come uno degli attributi. A differenza dei modelli precedenti, neisistemi operativi attuali un servizio ABAC non è implementato, anche se per im-plementarlo non si ha la necessità di particolari infrastrutture tecnologiche disupporto. In sistemi di grandi dimensioni è comunque utile un servizio per sta-bilire definizioni comuni degli attributi (Authoritative Attribute Source, AAS),allo scopo di armonizzare lo sviluppo delle regole.

La definizione di regole di sicurezza mediante attributi è un metodo piùefficiente rispetto a RBAC, ma l’organizzazione delle regole non scala in sistemidi grandi dimensioni, in quanto non vi è un metodo per gestirne la struttura.

Il modello Policy Based Access Control (PBAC) si presenta come una stan-dardizzazione e riorganizzazione del modello ABAC, per permettere una piùsemplice gestione delle regole. Il sistema di controllo è formato da politiche,cioè insiemi di regole su attributi, e valuta le richieste autorizzative combinan-do le decisioni delle politiche applicabili alla richiesta. Ogni politica calcola lasua decisione in base ad attributi forniti dalla richiesta o da altre entità esterne,che forniscono solitamente valori d’ambiente. Rispetto al modello ABAC, le po-litiche possono essere identificate e utilizzate in più entità distinte all’internodi un sistema, offrendo una maggior scalabilità del modello.

Molte aziende e organizzazioni utilizzano sistemi per il controllo degli acces-si basati sul modello PBAC. Quando questi sistemi interagiscono tra loro, anchei sistemi di controllo degli accessi devono comunicare tra loro, ma in assenzadi standard su cui poter basare l’implementazione di questi servizi non si avràmai un comportamento interpretabile correttamente da entrambi i lati. Per stan-dardizzare il processo di valutazione delle richieste e la definizione delle poli-tiche di sicurezza, sono state fatte varie proposte negli scorsi anni. Tra questespecifiche quella che è diventa standard nell’uso comune è XACML, realizzatoe mantenuto dal consorzio Organization for the Advancement of StructuredInformation Standards (OASIS).

Il modello PBAC potrebbe in futuro evolversi su vari fronti, ad esempio in-tegrando nuove modalità di creazione e indicizzazione delle politiche. Attual-mente non sono però disponibili varianti significative del modello, tranne quel-le proposte per ambienti applicativi specifici, come sistemi militari e safety-critical. Queste proposte, che andremo brevemente a presentare, non sono peròconsiderate nuovi modelli di controllo, ma soltanto applicazioni specifiche.

Una di queste proposte è l’applicazione del modello PBAC a sistemi critici.In questo ambito è necessario associare livelli di rischio a ogni processo didecisione e legare la valutazione delle richieste a parametri specifici di rischio.Il modello Risk Adaptive Access Control (RAdAC) è stato proposto per questoscopo, ma la vasta sfida tecnologica per il livello infrastrutturale necessario allagestione del rischio, ha fatto sì che non si abbiano ancora applicazioni utilizzateda analizzare.


Un altro problema di PBAC è l’assenza di un controllo autorizzativo tra i varilivelli di valutazione presenti. In applicazioni militari, per assicurare l’integri-tà e la sicurezza delle informazioni, la valutazione delle politiche deve esserecondizionata anche dall’autenticazione ricevuta da chi esegue ogni operazionedurante il processo. Questo approccio è trattato nel modello authoriZation Ba-sed Access Control (ZBAC), ma attualmente si hanno implementazioni soltantoin ambito militare.

Questi ultimi modelli sono nati per ambienti applicativi ristretti e non pre-sentano particolari innovazioni rispetto a PBAC, che invece è di largo utilizzonei moderni sistemi di controllo degli accessi. Per comprendere quali siano lepotenzialità e le caratteristiche del modello andiamo a presentare lo standardXACML, che ne è l’esempio più significativo.

2.2 xacml

Lo standard XACML definisce un linguaggio in sintassi XML per politiche disicurezza e un processo di valutazione delle richieste autorizzative secondo ilmodello PBAC. La prima versione è stata pubblicata da OASIS nel 2003 e allosviluppo hanno collaborato molte tra le più grandi aziende del settore IT. Laversione attualmente stabile è la 2.0 [17] del 2005, ma dal 2010 è già disponibileuna bozza della versione 3.0, che da giugno 2012 è stata aggiornata alla versionefinale per la revisione pubblica [22].

Nello standard XACML la richiesta di accesso a una risorsa è formata da uninsieme di attributi che descrivono il soggetto, l’azione e la risorsa coinvolti.L’esito del processo di autorizzazione è dato dalla combinazione delle regoleapplicabili a tale richiesta.

Nella versione attuale, a differenza della precedente, il processo di autorizza-zione della richiesta può dipendere non solo dalle regole applicate sugli attri-buti, ma anche dal risultato di azioni accessorie eseguite in fase di applicazionedella decisione. Nel caso queste azioni non fossero eseguite con successo, siavrebbe la negazione dell’accesso alle risorse; vedremo in dettaglio queste si-tuazioni nelle prossime sezioni. Questa possibilità crea una maggior dinamicitàdelle politiche, in quanto l’autorizzazione non dipende soltanto dalle regoledefinite, ma anche da azioni eseguite a tempo di valutazione.

Con l’eccezione del caso precedente, non sono presenti notevoli differenze trale ultime due versioni, se non in costrutti sintattici diversi per migliorare l’effi-cienza di specifica delle politiche; queste differenze sono presentate in dettaglionel capitolo successivo.

Nel prosieguo della tesi la versione di riferimento di XACML è la 3.0 [22].A seguire è descritto il modello applicativo dello standard e la sua strutturainterna.

2.2 xacml 9

2.2.1 Il processo di autorizzazione

Un sistema di controllo degli accessi deve essere considerato come un com-ponente indipendente di un sistema architetturale più ampio. La tipologia dicomponenti presenti nel sistema dipende dalla natura dell’architettura realizza-ta, ma componenti per la comunicazione e autenticazione saranno sicuramentepresenti, per fornire gli strumenti necessari alla costruzione di altre funzionali-tà. Se dal punto di vista della comunicazione molto è legato all’infrastrutturadi rete utilizzata, per l’autenticazione si può utilizzare lo standard Security As-sertion Markup Language (SAML) [16] di OASIS. Questo standard permette lagestione e il trasferimento di attributi d’identità nelle comunicazioni tra i com-ponenti, e quindi anche per le richieste autorizzative. Lo standard XACML siinserisce all’interno di questo contesto applicativo, con il compito di valuta-re le richieste di autorizzazione; gli attributi di identificazione eventualmentepresenti possono condizionare l’esito del processo.

Andiamo adesso nel dettaglio di quello che è il modello di sistema propostonello standard.

Il dominio applicativo di XACML non comprende esclusivamente il ruolo divalutazione della richiesta autorizzativa, ma coinvolge altri ruoli, come l’appli-cazione della decisione presa, la gestione delle politiche e il dialogo con l’e-sterno. Lo standard descrive un insieme di ruoli e le interazioni tra di essi,allo scopo di delineare la struttura del sistema di controllo, senza però forzarespecifiche soluzioni implementative.

Il dialogo con applicazioni esterne al sistema di controllo degli accessi e l’ap-plicazione delle decisioni calcolate per le richieste, sono associate al ruolo delPolicy Enforcement Point (PEP). La realizzazione del processo di valutazioneautorizzativa è associata al ruolo del Policy Decision Point (PDP), che è quellodefinito con maggior dettaglio nello standard. Infine, la gestione di informazio-ni esterne alle politiche, ma necessarie per la valutazione, è associata al PolicyInformation Point (PIP). Il flusso delle informazioni tra i ruoli è gestito, comevedremo più avanti, dal context handler.

La definizione di ruoli e non di entità ben precise, permette di definire lefunzionalità del sistema, lasciando la possibilità di integrarle, a seconda delleimplementazioni, nei componenti opportuni. Ad esempio, si può avere un siste-ma definito per richieste non sviluppate in formato XACML, che devono quindiessere trasformate nella sintassi richiesta dal PDP. Questo compito può esseresvolto dal PEP oppure dal context handler prima della chiamata del PDP.

Il processo di autorizzazione si basa sui valori degli attributi presenti nellerichieste e può dipendere anche dal contesto di valutazione esterno alle richie-ste. Con contesto si intende l’insieme delle informazioni collegate all’ambientedi valutazione delle richieste; un tipico esempio è l’attributo tempo che indicala data e l’ora corrente. L’attributo è l’unità che contiene le informazioni nel


Figura 2.1: Data-Flow XACML

contesto e nelle richieste ed è formato da una coppia nome-valore. Lo standarddefinisce una sintassi specifica per gli attributi, ma non è necessario utilizzarlanelle implementazioni.

Il flusso delle informazioni tra i ruoli prima presentati descrive il processodi valutazione alla XACML raffigurato in Figura 2.1. Lo standard non definisceil comportamento e i requisiti di ogni ruolo presente in figura, ma soltanto diquei ruoli strettamente coinvolti nel processo di decisione. Il PDP, che calcolala decisione associata a ogni richiesta, è dettagliato in ogni comportamento erequisito funzionale, a differenza degli altri ruoli definiti soltanto per requisitigenerali.

La definizione del PDP si basa su una sintassi specifica degli elementi request(richiesta), response (risposta) e attribute (attributo) presenti in Figura 2.1. Per ef-fettuare il processo di valutazione riceve le politiche dal Policy AdministrationPoint (PAP). Di questo ruolo non è stabilito alcun requisito funzionale per la suaimplementazione, ma solo la sintassi delle politiche.

La gestione delle politiche nel PAP, cioè salvataggio, aggiornamento, modi-

2.2 xacml 11

fica e recupero, dipendono dai vincoli applicativi e dalle tecnologie utilizzate.Una proposta di OASIS a tal riguardo è descritta nello standard amministrativocollegato [24]; questo standard è descritto con maggior dettaglio nelle sezionisuccessive.

Durante la valutazione delle politiche il PDP può avere la necessità di ricevereinformazioni aggiuntive su risorse. Perciò, usa il context handler per interrogareil PIP, che ricerca il valore degli attributi richiesti; anche in questo caso le moda-lità implementative possono essere molteplici. Il PAP e le entità collegate al con-text handler potrebbero essere oggetto di una definizione più completa in futuristandard OASIS, ad esempio, in [27] vi è una discussione su quali caratteristichedovrebbe avere il futuro PAP.

La ricezione delle richieste e l’applicazione delle decisioni calcolate sono com-piti del PEP. Questo ruolo non è definito completamente nello standard, ma so-no descritte le linee guida generali da seguire. Il PEP per applicare la decisionericevuta con l’elemento response in Figura 2.1, ha il compito di eseguire e valuta-re tutte le azioni accessorie presenti e, in base all’esito delle azioni, permetterel’accesso alla risorsa o negarlo.

Il PEP, in generale, è un livello di astrazione che implementa le azioni noneseguibili direttamente dal PDP e gestisce la comunicazione con l’esterno. Sepensiamo ad esempio a un servizio web che implementa il modello di valuta-zione XACML, il PEP può essere lo stub che riceve le richieste, spacchetta i variattributi organizzandoli in richieste per il PDP e, una volta ricevuta la decisione,la comunica al client.

La definizione delle azioni eseguibili dal PEP non è formalizzata e nelle politi-che sono definiti soltanto l’identificatore dell’azione e gli argomenti. Per l’esecu-zione corretta dell’azione, si deve avere un accordo tra chi implementa il PEP echi scrive le politiche, allo scopo di associare stesso significato agli identificatori.

La comunicazione tra PDP, PEP, PIP e gli altri ruoli presenti in Figura 2.1, èresa possibile dal context handler. Questo ruolo non ha compiti specifici oltre adorganizzare le richieste e gestire la comunicazione di risposte e attributi. Nelleimplementazioni dei tool che supportano XACML, questo ruolo è solitamentedefinito all’interno del PDP o del PEP a seconda delle scelte.

La descrizione precedente ha chiarito i compiti svolti dai vari ruoli, vediamoadesso come collaborano tra loro per decidere l’esito di una richiesta, sulla basedelle politiche d’accesso definite nel PAP e disponibili per il PDP. Una situazionestandard del flusso di informazioni generato dal processo di valutazione di unrichiesta, è la seguente:

La richiesta è inviata al PEP e inoltrata al context handler, che provve-de a formattarla nella sintassi XACML e a inviarla al PDP. Se durantela valutazione il PDP necessita di attributi aggiuntivi, questi sono ri-chiesti al context handler, che se non li ha ricevuti dal PEP, interrogail PIP. Quando tutti gli attributi sono stati ottenuti e la valutazione


della richiesta è terminata, il PDP completa la sua esecuzione e in-via al context handler la risposta, comprensiva della decisione e dieventuali azioni accessorie. La risposta è ricevuta dal PEP, che ese-gue le eventuali azioni e garantisce l’accesso alla risorsa oppure no,a seconda dell’esito dei vari passaggi.

Dalla descrizione precedente segue che il contesto di applicazione dello stan-dard è il più vario possibile, non ci sono vincoli sul tipo di attributi o azionieseguibili, ma soltanto sulla sintassi delle politiche e sui requisiti funzionali delPDP.

Il recupero delle politiche dal PAP è una azione molto importante e lemodalità scelte in fase di implementazione possono inficiare la performance.

L’approccio dei ruoli e la suddivisione dei compiti definita in precedenza,hanno permesso una vasta diffusione dell’utilizzo di XACML, sia in ambito ac-cademico che commerciale. Alcuni esempi di tool per la valutazione e il sup-porto allo sviluppo di politiche XACML sono mostrati in [1], mentre esempi diapplicazioni industriali sono riportati in [3].

2.2.2 Il linguaggio delle politiche

Gli elementi valutabili di più basso livello del linguaggio sono le rule, raggrup-pate in policy che a loro volta possono essere contenute in insiemi chiamatipolicy set; nei policy set inoltre si possono anche raggruppare altri policy set. Lavalutazione delle rule determina l’effetto, permit o deny, da cui inizia il processodi decisione. Dalla combinazione degli effetti delle rule e, risalendo l’albero divalutazione, delle policy e dei policy set, è possibile ottenere la decisione finaledel PDP. La composizione degli elementi del linguaggio si può raffigurare comein Figura 2.2, che andremo adesso a descrivere.

Per quanto riguarda la notazione, per riferirsi agli elementi XML specificidi XACML è utilizzato il termine inglese in italico, mentre il termine italiano,riportato alla prima occorrenza del termine tra parentesi, è utilizzato in sensolato rispetto al modello PBAC.

La rule (regola) rappresenta la componente elementare della policy (politica)ed è formata dal target1, che ne definisce l’applicabilità mediante espressionisu attributi, dalla condition (condizione), un’espressione booleana che ne perfe-ziona l’applicabilità, ed infine dall’effect (effetto), permit o deny, che è il valorerestituito dalla rule in caso di valutazione positiva delle altre componenti. L’ap-plicabilità di un elemento a una richiesta significa che tale elemento è utilizzatodal PDP per il calcolo della decisione autorizzativa.

1 Il termine italiano utilizzato è la stessa parola target, utilizzata in italico per riferirsi all’elementospecifico XACML, con caratteri normali altrimenti.

2.2 xacml 13

Figura 2.2: Struttura del linguaggio XACML

Le rule sono organizzate in policy, che sono composte da un target e dall’iden-tificatore dell’algoritmo di combinazione dei risultati della valutazione dellerule contenute.

L’ultimo livello di aggregazione è il policy set (inisiemi di politiche), che èutilizzato per raccogliere le policy e i policy set stessi. Come per le policy, si hala presenza di un target e di un algoritmo per il combinig dei risultati dellepolicy. In ogni rule, policy e policy set si ha anche la presenza di obligation eadvice (entrambi i termini tradotti con obbligazione), che definiscono le azioniaccessorie, già citate nelle sezioni precedenti, che deve eseguire il PEP.

Per introdurre maggior dipendenza dal contesto della valutazione delle ri-chieste, rispetto alla versione precedente di XACML le obligation sono state modi-ficate con l’introduzione di espressioni invece che valori letterali fissi, ed è statointrodotto l’elemento advice per fornire informazioni aggiuntive non vincolan-ti per la decisione finale. Questi elementi permettono di ottenere mediante ilPDP attributi dal contesto, che altrimenti non sarebbero ottenibili nel PEP e dieseguire azioni esterne al processo di valutazione del PDP, cioè nel PEP. L’esi-to dell’esecuzione di queste azioni influisce sull’applicazione della decisione,infatti in caso di errori di esecuzione non è accordato l’accesso alla risorsa. Aquesto fa eccezione l’advice che in caso di errore non ha conseguenze sull’ap-


plicazione della richiesta, garantendo maggior elasticità nella definizione delleazioni accessorie. L’implementazione del PEP può comunque essere specializza-ta secondo il contesto applicativo, richiedendo una gestione diversa di questielementi.

Per facilitare la lettura, nel prosieguo della tesi si utilizzerà il solo termineobligation per indicare anche l’elemento advice, a meno di esplicite distinzioni.

I quattro possibili valori di decisione generati dal processo di valutazione delPDP sono i seguenti:

- permit: l’accesso alla risorsa è permesso;

- deny: l’accesso alla risorsa è vietato;

- indeterminate: il PDP ha riscontrato un errore durante la valutazione dellarichiesta;

- not-applicable: il PDP non dispone di politiche applicabili alla richiesta.

Una situazione di indeterminate può essere causata da errori sintattici, assen-za di alcune risorse o anomalie nell’esecuzione di alcune operazioni. In molticasi si tratta di banali errori dovuti alla definizione delle policy, da cui nell’ulti-ma versione dello standard, per dettagliare maggiormente la situazione che hagenerato un risultato indeterminate, è stata introdotta la seguente sintassi estesaper il valore indeterminate:

- indeterminate-P: è un indeterminate dovuto a una politica o una regola cheperò potrebbe essere valutata come permit ma non deny;

- indeterminate-D: è un indeterminate dovuto a una politica o una regola cheperò potrebbe essere valutata come deny ma non permit;

- indeterminate-DP: è un indeterminate dovuto a una politica o una regolache però potrebbe essere valutata sia come permit che deny.

I valori estesi riportano quello che potrebbe essere il valore di decisionedell’elemento, così da facilitare la verifica delle politiche.

La semantica della valutazione delle richieste si basa in larga parte sugli al-goritmi di combinazione, infatti essi stabiliscono quale elemento deve esserevalutato, come gestire eventuali risultati indeterminate e come unire più valoridi decisione diversi. Nello standard sono presenti alcuni algoritmi per model-lare situazioni frequenti, ma si può gestire situazioni specifiche con algoritmipersonalizzati.

Nella sfera di influenza di XACML ci sono anche altri standard minori pergestire casistiche particolari, ne vedremo due nella sezione successiva.

2.2 xacml 15

2.2.3 Standard collegati a XACML

Con lo sviluppo della versione 3.0 di XACML è stato introdotto il supporto adalcune funzionalità aggiuntive rispetto al solo processo di decisione. Si tratta dioperazioni collegate al processo di decisione, di cui si può richiedere l’utilizzomediante alcuni attributi presenti nella sintassi di XACML. A titolo di esempiosi considera la decisione combinata di più richieste [23] e la delegation [24], chepermette la gestione della modifica e dell’aggiornamento delle politiche nelPAP.

La decisione combinata di più richieste consiste nel sottoporre al PDP uninsieme di richieste, del quale si richiede un unico valore di decisione. La sceltadi questa opzione è possibile mediante un attributo presente nella richiesta,senza dover modificare i ruoli prima presentati. Le operazioni stabilite in [23],che devono essere eseguite dal PDP e dal context handler, saranno illustrate indettaglio nella Sezione 3.3.

La delegation invece è un approccio per la gestione dei diritti sulle politiche,cioè per stabilire chi è autorizzato ad aggiornare le regole di accesso a una risor-sa. Si può realizzare questo obiettivo associando a ogni politica un proprietario,mediante l’attributo XML PolicyIssuer, a partire dal quale si calcola chi ha idiritti per svolgere certe azioni.

La gestione dei diritti sulle risorse avviene per delega, cioè si definisconodelle politiche amministrative allo scopo di delegare a un soggetto i diritti digestione di una risorsa. Una politica amministrativa è della stessa forma diuna politica di controllo degli accessi, si attribuisce quindi la delega definen-do anche controlli su altri attributi del contesto, oltre a quelli della risorsa. Unsoggetto delegato può a sua volta delegare altri, dando origine a strutture gerar-chiche tra politiche amministrative; la radice di questa struttura è una politicasenza proprietario, che viene considerata come affidabile.

Quando una richiesta di autorizzazione deve essere valutata, se si applicaquesto standard amministrativo, prima di valutare le politiche, si controlla sesono state definite da soggetti autorizzati a farlo. Sulla base delle politiche d’ac-cesso applicabili, si ricostruisce, utilizzando le politiche amministrative presenti,il grafo di riduzione delle deleghe, cioè si ricostruiscono le autorizzazioni asso-ciate a chi ha definito la politica d’accesso. Nel dettaglio, si prende una coppiadi politiche e si controlla se una politica delega, al proprietario dell’altra, i dirit-ti di gestione della risorsa indicata nella richiesta autorizzativa. Si completa ilgrafo valutando tutte le coppie di politiche, e si selezionano per la valutazionedella richiesta soltanto le politiche d’accesso affidabili, cioè quelle per le qualiè possibile creare un cammino di politiche amministrative fino a una politicasenza proprietario, perciò affidabile.

Per implementare questo processo di controllo amministrativo, deve esseregestito il riconoscimento del proprietario di ogni politica e la definizione di


identificatori specifici per gli attributi, allo scopo di distinguere le politicheamministrative da quelle d’accesso.

2.3 caso di studio

La collaborazione tra sistemi informatici è pratica comune per la condivisionedi informazioni e per la creazione di nuovi servizi. Questa direzione di svilup-po è stata adottata anche per i sistemi sanitari delle nazioni europee, al finedi condividere le informazioni su pazienti, prescrizioni e malattie rilevate sulterritorio. Gli strumenti che si vogliono creare permettono di incrementare laqualità del servizio per il paziente, sia nella nazione di residenza che all’estero.

Lo sviluppo di questi progetti, oltre alle questioni normative, coinvolge lar-gamente le problematiche del controllo degli accessi e le soluzioni tecnologicheda adottare. Vista l’importanza dell’obiettivo e la connessione agli argomen-ti affrontati nella tesi, si utilizza il progetto europeo Smart Open Services forEuropean Patients (epSOS) [25] come caso di studio. Presentiamo quindi conmaggior dettaglio le finalità del progetto e le scelte tecnologiche effettuate.

2.3.1 Il progetto epSOS

Il progetto di un servizio sanitario europeo integrato è nato a inizio anni due-mila e nel corso del 2008, con la nascita di epSOS, siamo passati dalla fase concet-tuale a quella di progettazione vera e propria. La finalità del progetto è quelladi creare le basi, tecnologiche e giuridiche, per supportare l’interoperabilitàdei sistemi sanitari degli stati membri. Le soluzioni tecniche e organizzativeproposte, dal 2011, sono in fase di test con un progetto pilota su larga scala.

Lo sviluppo di epSOS guiderà verso la completa digitalizzazione i servizi sa-nitari nazionali, favorendo così nuove tipologie di servizi offerti, ad esempiola telemedicina, cioè fornire supporto al paziente tramite strumenti informatici,e la digitalizzazione delle ricette mediche. I servizi che si potranno offrire conqueste tecnologie incrementeranno la qualità del sistema sanitario usufruibiledai cittadini europei.

Conseguire questi obiettivi comporta una sfida tecnologica e anche legisla-tiva rilevante, viste le differenze giuridiche tra le nazioni nel trattamento deidati personali. In questo ambito, gli organi legislativi europei si sono adoperatiper armonizzare i sistemi normativi e definire le modalità di applicazione delprogetto. Dal punto di vista tecnologico, invece, si ha l’obbligo di assicurarestringenti requisiti di sicurezza nell’accesso ai dati, dei tempi di risposta nell’e-laborazione delle richieste e nella gestione di grandi quantità di dati. Vediamoadesso nel dettaglio la definizione del sistema di sicurezza.

2.3 caso di studio 17

Figura 2.3: Schema logico della comunicazione in epSOS

Il sistema di sicurezza

Il sistema di scambio di informazioni tra nazioni si basa sulla creazione di unCircle of Trust (cerchio della fiducia) tra gli stati, cioè una piattaforma mediantela quale avviene il dialogo tra i vari sistemi nazionali. Dentro questo domi-nio, ogni nazione è rappresentata da un National Contact Point (NCP), cioè ungateway che gestisce i messaggi in entrata e in uscita dal sistema nazionale.

Ogni NCP assicura i requisiti richiesti per la comunicazione con gli altri NCP e,prima di diffondere informazioni all’infrastruttura nazionale, valuta l’autorizza-zione di quei dati, nel rispetto dello norme nazionali. Per garantire la sicurezzadel sistema, si separa il sistema di gestione nazionale da quello per la comuni-cazione esterna, definendo un livello intermedio di controllo sugli accessi. Tuttigli scambi di messaggi, inoltre, sono soggetti a un controllo di autenticazione,cioè ci si assicura dell’identità di chi effettua la richiesta; da questi attributi diidentità dipende anche il risultato della decisione autorizzativa.

La definizione delle politiche di sicurezza nazionali compete alle singole na-zioni, mentre il sistema di controllo degli accessi e la comunicazione tra gli NCP

sono definiti secondo i requisiti funzionali epSOS. Per l’implementazione delcontrollo degli accessi, cioè per la definizione delle politiche e delle richieste, èstato scelto lo standard XACML. Lo standard si inserisce all’interno dello schemalogico di Figura 2.3, dove è rappresentato il ruolo del sistema di controllo degliaccessi per la comunicazione tra due NCP nazionali.

Ogni nazione implementa il proprio NCP suddividendo la parte di comuni-cazione con gli altri NCP dal sistema nazionale vero e proprio. Tra le due com-ponenti si pone il sistema di controllo degli accessi, che valuta l’autorizzazionedei messaggi in transito. Quando si vuole interrogare un sistema straniero, il si-stema nazionale controlla l’autenticazione del soggetto, utilizzando lo standard


Figura 2.4: Caso d’uso per Patient Summary (PS)

SAML, e se i controlli autorizzativi hanno esito positivo, il messaggio viene codi-ficato secondo le specifiche epSOS e inviato all’altro NCP. Quest’ultimo valuteràla richiesta in base alle proprie politiche e, se il paziente e il sistema danno ilconsenso alla diffusione dei dati, la risposta è inviata al mittente.

Le politiche di sicurezza nazionali sono definite, secondo le specifiche epSOS,sui dati medici dei pazienti, distinguendo quelli critici, cioè da trattare secondoappropriate direttive, da quelli non critici e dai dati amministrativi. I diritti diaccesso ai dati, sono definiti in base al ruolo che il richiedente ricopre nel servi-zio sanitario nazionale; ad esempio un dottore può aver accesso ai dati medicidi un paziente, a differenza del personale amministrativo. Di ogni paziente isistemi nazionali gestiscono, tra le altre, le seguenti tipologie di informazioni:

- Patient Summary (PS): la cartella clinica completa del paziente, contenentetutte le informazioni sui trattamenti effettuati;

- ePrescription (eP): la prescrizione di un medicinale per un paziente, conla specifica delle modalità e dei tempi di somministrazione.

In base alle regole di diffusione delle informazioni, definite dal paziente e dalsistema nazionale, sono definite le politiche di sicurezza XACML.

Nel progetto epSOS sono definiti i comportamenti del sistema anche per altretipologie di informazioni, ma in questa tesi approfondiamo la gestione del-la cartella clinica e della prescrizione elettronica, presentando un caso d’usospecifico.

2.3 caso di studio 19

Il caso d’uso di PS è descritto con il sequence diagram in Figura 2.4 e mettein risalto, rispetto alla Figura 2.3, l’utilizzo dei ruoli di XACML. In questo casod’uso si ha che un dottore chiede la cartella clinica di un paziente, tramite loNCP della nazione B, al NCP della nazione A di origine del paziente. La richiestacontiene gli attributi di identificazione del dottore e l’identificativo del paziente.Una volta controllata l’autenticità della richiesta, si provvede a recuperare leinformazioni necessarie, delle quali se ne valuta la possibilità di diffusione inbase alle politiche di sicurezza definite. Per calcolare tale decisione si interrogal’unità PEP della nazione A, la quale applicando la decisione del PDP, restituiscela decisione finale al NCP di A, che la comunica al NCP di B. La risposta finale aldottore è vincolata dalla valutazione delle regole della nazione B, infatti si puòavere alcune restrizioni normative che devono essere applicate.

Questo caso d’uso rappresenta la situazione reale in cui un paziente origi-nario della nazione A si trova nella nazione B e necessita di cure. Il dottoreche effettua la visita può richiedere la cartella del paziente alla nazione A. Idati clinici e le eventuali prescrizioni del paziente ricevuti, offrono maggioriinformazioni al dottore per effettuare il consulto richiesto.

Per quanto riguarda la richiesta di prescrizioni elettroniche, la sequenza delleoperazioni è simile alla precedente, e non se ne presenta il caso d’uso. In questacaso la richiesta può anche essere fatta da un soggetto che ricopre il ruolo difarmacista.

Il caso d’uso delle prescrizioni rappresenta la situazione in cui ad un pazien-te sono stati prescritti dei farmaci nella propria nazione e devono essere ritiratidurante una permanenza all’estero. Per rilasciare il farmaco, il farmacista si col-lega alla piattaforma epSOS e controlla la presenza della prescrizione. Quandoconsegna al paziente i farmaci, la dispensazione è comunicata alla nazione diorigine.

Il caso di studio presentato in questa sezione è così dettagliato nei capitolisuccessivi. Nel Capitolo 3 sono presentate le politiche di sicurezza e la lorovalutazione mediante il tool HERASAF [26]. Nel Capitolo 4 la definizione dellepolitiche secondo la sintassi del nostro linguaggio ed infine nel Capitolo 5 lavalutazione delle richieste con la libreria Java che abbiamo sviluppato.

3S I N TA S S I E S E M A N T I C A D I X A C M L

Il modello di controllo degli accessi alla base dello standard XACML, trattatonel capitolo precedente, ha delimitato l’ambito entro cui stiamo operando e lefunzionalità offerte dal sistema. In questo capitolo ci occupiamo di definire lasintassi del linguaggio delle politiche e la semantica informale del processo divalutazione delle richieste autorizzative.

La sintassi è definita in XML e si suddivide tra la parte di definizione di rule,policy e policy set, elementi contenuti nel PAP, e quella di request e response. Ilprocesso di valutazione delle richieste è definito specificando i requisiti funzio-nali del PDP necessari per la valutazione dei target, delle condizioni, ecc, e perl’applicazione degli algoritmi di combinazione.

Descriviamo prima gli elementi dello standard e le loro caratteristicheprincipali, e a seguire il processo per valutare le richieste.

3.1 sintassi di xacml

Gli elementi valutabili della sintassi di XACML sono le rule, le policy, i policy sete i loro sotto-elementi come i target e le obligation. Gli elementi request e responsesono definiti per il dialogo con il PDP.

3.1.1 Politiche e Insiemi di Politiche

Le politiche e gli insiemi di politiche presenti nel PDP, recuperati dal PAP, sonogli elementi da cui inizia il processo di valutazione delle richieste. Infatti, ilPDP può essere visto come un policy set con target vuoto che racchiude le altrepolitiche considerate nella valutazione.

Questi elementi sono definiti rispettivamente con i costrutti XML <Policy>

e <Policyset>. La loro struttura è la stessa, con la sola differenza che le policycontengono rule mentre i policy set sono formati da policy o altri policy set. Glielementi sintattici necessari a identificare una policy sono

- un identificatore della policy, utilizzato come riferimento per includere inaltri policy set la policy in questione;

21

22 sintassi e semantica di xacml

- un target, per definire l’applicabilità della policy alle richieste;

- un algoritmo per la combinazione delle rule presenti nella policy;

- una sequenza, anche vuota, di rule;

- eventuali obligation.

L’identificatore e l’algoritmo sono definiti come attributi dell’elemento XMLmentre gli altri sono degli elementi figli di policy. L’algoritmo di combinazionedetermina il flusso del processo di valutazione delle richieste e quale sia ladecisione finale della politica.

Tra i sotto-elementi di policy, oltre a quelli sopra elencati, ve ne sono anchealtri per la scelta di parametri opzionali di valutazione. Ad esempio si ha il<PolicyIssuer>, necessario per l’implementazione della delegation descritta in[24], o la definizione di parametri per l’invocazione di algoritmi di combina-zione personalizzati. Non andiamo nel dettaglio di queste specifiche in quantonon necessarie ai fini della tesi.

Gli attributi dell’elemento policy set sono simili a quelli elencati sopra per poli-cy, con la differenza che gli algoritmi di combinazione sono definiti su politichee non su regole. Alcuni esempi di politiche e insiemi di politiche sono riportatinella Sezione 3.1.6.

3.1.2 Regole

L’elemento di base per formare le politiche XACML è la rule. Gli elementi che lacompongono sono l’effetto, il target, la condizione e le obbligazioni.

L’effetto è la decisione restituita alla politica che contiene la regola, quandola regola è valutata con successo. L’effetto può essere permit o deny. Per defi-nire a quali richieste si applica la regola, oltre al target, vi è anche l’elementocondition, che consiste in una funzione booleana su attributi o funzioni di at-tributi. In particolare, la condizione è un’espressione dove è possibile definirecontrolli su attributi della richiesta o del contesto, per specializzare il controllodell’applicabilità.

Le tipologie di espressioni che si possono definire sono raccolte sotto l’ele-mento <Expression>. Tra le altre, si ha la specifica di funzioni con l’elemen-to <Apply>, il recupero dei valori degli attributi con <AttributeSelector> o<AttributeDesignator>, e l’utilizzo di riferimenti a funzioni, che erano sta-te definite con l’elemento <Variable> all’esterno di rule. Esempi di rule sonoriportati nella Sezione 3.1.6.

3.1 sintassi di xacml 23

Listato 3.1: Esempio di Target<Target>

<AnyOf><Al lO f>

<Match MatchId=" u r n : o a s i s : n am e s : t c : x a cm l : 1 . 0 : f u n c t i o n : s t r i n g −equa l "><At t r i b u t eVa l u e DataType=" h t t p : //www.w3 . org /2001/XMLSchema#s t r i n g ">

a dm i n i s t r a t o r</ A t t r i b u t eVa l u e><At t r i b u t eD e s i g n a t o r MustBePresent=" f a l s e "

Category=" u r n : o a s i s : n am e s : t c : x a cm l : 3 . 0 : a t t r i b u t e −c a t e g o r y : s u b j e c t"

A t t r i b u t e I d=" u r n : o a s i s : n am e s : t c : x a cm l : 3 . 0 : s u b j e c t : r o l e "DataType=" h t t p : //www.w3 . org /2001/XMLSchema#s t r i n g " />

</Match></A l lO f><Al lO f>

. . .</ A l lO f>

</AnyOf><AnyOf>

<Al lO f><Match MatchId=" u r n : o a s i s : n am e s : t c : x a cm l : 1 . 0 : f u n c t i o n : s t r i n g −equa l ">

<At t r i b u t eVa l u e DataType=" h t t p : //www.w3 . org /2001/XMLSchema#s t r i n g ">P16

</ A t t r i b u t eVa l u e><A t t r i b u t e S e l e c t o r MustBePresent=" f a l s e "

Category=" u r n : o a s i s : n am e s : t c : x a cm l : 3 . 0 : a t t r i b u t e −c a t e g o r y : r e s o u r c e "

Path="md: reco rd /md :pa t i e n t /md:pat ientDocID / t e x t ( ) "DataType=" h t t p : //www.w3 . org /2001/XMLSchema#s t r i n g " />

</Match>. . .

</ A l lO f></AnyOf>

</Target>

3.1.3 Target

Il target definisce a quali richieste l’elemento che lo contiene è applicabile; atal scopo si definiscono delle condizioni sugli attributi della richiesta mediantefunzioni, seguendo una struttura ben definita che andiamo adesso a descrivere.

L’elemento target è formato da una sequenza, eventualmente vuota, di ele-menti <AnyOf>, che a loro volta contengono una sequenza di elementi <AllOf>.Questi ultimi elementi contengono infine una sequenza di <Match>, ovverodi specifiche funzioni booleane di controllo sugli attributi della richiesta. Unesempio di struttura generale di un target è mostrato nel Listato 3.1.

L’elemento <Match> per essere ben definito necessita dei seguenti attributi:

- l’identificatore della funzione di match da applicare, ad esempiostring-equal, integer-less-than, . . . ;

- la selezione dell’insieme di valori dalla richiesta su cui appli-

care la funzione, mediante le funzioni <AttributeDesignator> o<AttributeSelector>;

- un valore letterale per fare il confronto.

L’elemento AttributeDesignator permette di recuperare dalla richiesta un insie-me di valori secondo il nome e la categoria dell’attributo. Mentre AttributeSe-lector utilizza espressioni XPath [6], cioè espressioni per localizzare nodi all’in-terno di dati XML. Quest’ultima opzione è utilizzata quando nella richiesta sihanno informazioni sotto forma di dati XML.

Differenze con XACML 2.0

La sintassi dei target rappresenta una delle differenze principali tra XACML 2.0e 3.0. Nella versione 2.0 si aveva una suddivisione degli attributi in quattro ca-tegorie prefissate (subject, action, resource e environment), che comportava anchela suddivisione delle condizioni nel target in altrettanti blocchi distinti.

La nuova versione del target ha maggior espressività della versione prece-dente, riuscendo con un unico elemento a formulare condizioni più complesse.Infatti, la divisione rigida in categorie non permette di creare in un unico targetalcuni tipi di condizioni, anche abbastanza semplici, tra attributi di categoriediverse. Prendiamo per esempio la definizione della seguente politica:

Un dottore può scrivere un report medico oppure un infermiere può leggerlo

Se si usa la versione 2.0, per realizzare questa politica si devono creare duepolitiche o due regole diverse, per avere due differenti target, uno per il dottorel’altro per l’infermiere. Se si utilizza invece un unica politica, ad esempio quellanel Listato 3.2, si hanno dei comportamenti inaspettati.

Listato 3.2: Policy XACML 2.0<Target>



<SubjectMatch MatchId=" u r n : o a s i s : n am e s : t c : x a cm l : 1 . 0 : f u n c t i o n : s t r i n g −equa l ">

doc to r<Sub j e c tA t t r i b u t eD e s i g n a t o r

A t t r i b u t e I d=" u r n : o a s i s : n am e s : t c : x a cm l : 1 . 0 : s u b j e c t : s u b j e c t −r o l e "DataType=" h t t p : //www.w3 . org /2001/XMLSchema#s t r i n g " />

</SubjectMatch>

<SubjectMatch MatchId=" u r n : o a s i s : n am e s : t c : x a cm l : 1 . 0 : f u n c t i o n : s t r i n g −equa l ">

nu r s e

<Resou r ce s>

<Resource><ResourceMatch MatchId=" u r n : o a s i s : n am e s : t c : x a cm l : 1 . 0 : f u n c t i o n : s t r i n g −

equa l ">med i ca l r e c o r d<Re s ou r c eA t t r i b u t eDe s i g n a t o r

A t t r i b u t e I d=" u r n : o a s i s : n am e s : t c : x a cm l : 1 . 0 : r e s o u r c e : r e s o u r c e −i d "DataType=" h t t p : //www.w3 . org /2001/XMLSchema#s t r i n g " />

</ResourceMatch></Resource>

</Resou rce s><Act i on s>

<Act ion><ActionMatch MatchId=" u r n : o a s i s : n am e s : t c : x a cm l : 1 . 0 : f u n c t i o n : s t r i n g −

equa l ">read<Ac t i o nA t t r i b u t eD e s i g n a t o r

A t t r i b u t e I d=" u r n : o a s i s : n am e s : t c : x a cm l : 1 . 0 : a c t i o n : a c t i o n −i d "DataType=" h t t p : //www.w3 . org /2001/XMLSchema#s t r i n g " />

</ActionMatch></Act ion><Act ion>

<ActionMatch MatchId=" u r n : o a s i s : n am e s : t c : x a cm l : 1 . 0 : f u n c t i o n : s t r i n g −equa l ">

w r i t e<Ac t i o nA t t r i b u t eD e s i g n a t o r

A t t r i b u t e I d=" u r n : o a s i s : n am e s : t c : x a cm l : 1 . 0 : a c t i o n : a c t i o n −i d "DataType=" h t t p : //www.w3 . org /2001/XMLSchema#s t r i n g " />

</ActionMatch></Act ion>

</Ac t i on s></Target>

In questo caso infatti la situazione non desiderata di un’infermiera che scri-ve il report medico è permessa. Questo avviene perché la valutazione degliattributi delle categorie subject e action è eseguita in modo separato, senza colle-gare strettamente il ruolo all’azione che può eseguire. La soluzione è quella didividere in due politiche diverse le regole per i due ruoli.

Con la versione 3.0 invece è sufficiente usare un unico elemento targetper l’assenza della divisione netta tra le categorie, così come mostrato nelListato 3.3.

Listato 3.3: Policy XACML 3.0<Target><AnyOf>

<Al lO f><Match MatchId=" u r n : o a s i s : n am e s : t c : x a cm l : 1 . 0 : f u n c t i o n : s t r i n g −equa l ">

med i ca l r e c o r d<A t t r i b u t eD e s i g n a t o r MustBePresent=" f a l s e "

Category=" u r n : o a s i s : n am e s : t c : x a cm l : 3 . 0 : a t t r i b u t e −c a t e g o r y : r e s o u r c e "

A t t r i b u t e I d=" u r n : o a s i s : n am e s : t c : x a cm l : 3 . 0 : r e s o u r c e : r e s o u r c e −i d "DataType=" h t t p : //www.w3 . org /2001/XMLSchema#s t r i n g " />

</Match></A l lO f>

</AnyOf>

<AnyOf><Al lO f>

<Match MatchId=" u r n : o a s i s : n am e s : t c : x a cm l : 1 . 0 : f u n c t i o n : s t r i n g −equa l ">doc to r<A t t r i b u t eD e s i g n a t o r MustBePresent=" f a l s e "



</Match><Match MatchId=" u r n : o a s i s : n am e s : t c : x a cm l : 3 . 0 : f u n c t i o n : s t r i n g −equa l ">

read<A t t r i b u t eD e s i g n a t o r MustBePresent=" f a l s e "

Category=" u r n : o a s i s : n am e s : t c : x a cm l : 3 . 0 : a t t r i b u t e −c a t e g o r y : a c t i o n "A t t r i b u t e I d=" u r n : o a s i s : n am e s : t c : x a cm l : 3 . 0 : a c t i o n : a c t i o n −i d "DataType=" h t t p : //www.w3 . org /2001/XMLSchema#s t r i n g " />

</Match></A l lO f><Al lO f>

<Match MatchId=" u r n : o a s i s : n am e s : t c : x a cm l : 1 . 0 : f u n c t i o n : s t r i n g −equa l ">nu r s e<A t t r i b u t eD e s i g n a t o r MustBePresent=" f a l s e "



</Match><Match MatchId=" u r n : o a s i s : n am e s : t c : x a cm l : 1 . 0 : f u n c t i o n : s t r i n g −equa l ">

w r i t e<A t t r i b u t eD e s i g n a t o r MustBePresent=" f a l s e "

Category=" u r n : o a s i s : n am e s : t c : x a cm l : 3 . 0 : a t t r i b u t e −c a t e g o r y : a c t i o n "A t t r i b u t e I d=" u r n : o a s i s : n am e s : t c : x a cm l : 3 . 0 : a c t i o n : a c t i o n −i d "DataType=" h t t p : //www.w3 . org /2001/XMLSchema#s t r i n g " />

</Match></A l lO f>

</AnyOf></Target>

A differenza del caso precedente, adesso ruolo e azione sono inseriti nellostesso elemento, senza permettere comportamenti indesiderati. Nel dettaglio,si accettano soltanto coppie ruolo-azione che corrispondono alla definizionedella politica.

Confrontando la struttura dei due esempi, si vede che la differenza di espres-sività deriva dal fatto che nella nuova versione si possono raggruppare elementi<AllOf> tra loro anche se sono definiti su attributi diverse categorie.

3.1.4 Obbligazioni

L’introduzione degli elementi obligation e advice nasce in letteratura a inizio anninovanta [21], ma solo con l’attuale versione dello standard si ha una forma utiledi obligation e la presenza degli advice.

Le obbligazioni erano già presenti nella versione 2.0, ma non erano definiterispetto ad attributi del contesto o della richiesta, infatti contenevano valoriletterali generici, che non erano valutati dal PDP ma solo interpretati dal PEP

Listato 3.4: Esempio di Obbligazione<Ob l i g a t i o nE x p r e s s i o n s>

<Ob l i g a t i o nE x p r e s s i o n Ob l i g a t i o n I d="u r n : o a s i s : n am e s : t c : x a cm l : o b l i g a t i o n : em a i l "

F u l f i l l O n="Permit "><At t r i b u t eA s s i g nmen tExp r e s s i o n

A t t r i b u t e I d=" u r n : o a s i s : n am e s : t c : x a cm l : 3 . 0 : a t t r i b u t e : m a i l t o "><A t t r i b u t e S e l e c t o r

MustBePresent=" t r u e "Category=" u r n : o a s i s : n am e s : t c : x a cm l : 3 . 0 : a t t r i b u t e −c a t e g o r y : r e s o u r c e "Path="md: reco rd /md :pa t i e n t /md :pa t i en tCon tac t /md:emai l "DataType=" h t t p : //www.w3 . org /2001/XMLSchema#s t r i n g " />

</ At t r i b u t eA s s i g nmen tExp r e s s i o n><At t r i b u t eA s s i g nmen tExp r e s s i o n

A t t r i b u t e I d=" u r n : o a s i s : n am e s : t c : x a cm l : 3 . 0 : a t t r i b u t e : t e x t "><At t r i b u t eVa l u e

DataType=" h t t p : //www.w3 . org /2001/XMLSchema#s t r i n g ">Your med i ca l r e c o r d has been a c c e s s ed by :

</ A t t r i b u t eVa l u e></ At t r i b u t eA s s i g nmen tExp r e s s i o n><At t r i b u t eA s s i g nmen tExp r e s s i o n

A t t r i b u t e I d=" u r n : o a s i s : n am e s : t c : x a cm l : 3 . 0 : e x am p l e : a t t r i b u t e : t e x t "><At t r i b u t eD e s i g n a t o r

MustBePresent=" f a l s e "Category=" u r n : o a s i s : n am e s : t c : x a cm l : 3 . 0 : a t t r i b u t e −c a t e g o r y : s u b j e c t "A t t r i b u t e I d=" u r n : o a s i s : n am e s : t c : x a cm l : 3 . 0 : s u b j e c t : s u b j e c t −i d "DataType=" h t t p : //www.w3 . org /2001/XMLSchema#s t r i n g " />

</ At t r i b u t eA s s i g nmen tExp r e s s i o n></ Ob l i g a t i o nE x p r e s s i o n>

</ Ob l i g a t i o nE x p r e s s i o n s>

al momento dell’esecuzione dell’azione. Questa soluzione non modificava lastaticità delle politiche, a differenza di quella di XACML 3.o che andiamo adessoa descrivere.

Le obligation sono definite nelle politiche come azioni da eseguire dal PEP

su valori recuperati da attributi del contesto o della richiesta da parte del PDP.Per definire un obligation si specifica l’identificatore dell’azione e gli argomentida passare. Le modalità di recupero dei valori degli argomenti sono defini-te con espressioni sugli attributi. La struttura di una obligation è mostrata nelListato 3.4.

L’attributo ObligationId definisce l’azione che il PEP dovrà eseguire. Dato sitratta soltanto di una stringa, per non avere errori di gestione degli identifica-tori, ci deve essere un preaccordo tra chi scrive le politiche e l’implementazio-ne del PEP. L’attributo FulfillOn definisce per quale effetto l’obbligazione deveessere valutata, cioè il PDP valuta tutti e soli gli elementi obligation il cui attri-buto FulfillOn è uguale al risultato della valutazione dell’elemento rule, policyo policy set che contiene l’obligation. Le espressioni per gli attributi dell’azionesono definite in <AttributeAssignmentExpression> mediante nome e categoriadell’attributo.

Listato 3.5: Obbligazioni del Listato 3.4 restituite al PEP

<Ob l i g a t i o n s><Ob l i g a t i o n Ob l i g a t i o n I d=" u r n : o a s i s : n am e s : t c : x a cm l : o b l i g a t i o n : em a i l ">

<At t r i bu t eAs s i gnmen t DataType=" h t t p : //www.w3 . org /2001/XMLSchema#s t r i n g "A t t r i b u t e I d=" u r n : o a s i s : n am e s : t c : x a cm l : 3 . 0 : a t t r i b u t e : m a i l t o "><At t r i b u t eVa l u e DataType=" h t t p : //www.w3 . org /2001/XMLSchema#s t r i n g ">

homers@aol . com</ A t t r i b u t eVa l u e>

</At t r i bu t eAs s i gnmen t><At t r i bu t eAs s i gnmen t DataType=" h t t p : //www.w3 . org /2001/XMLSchema#s t r i n g "

A t t r i b u t e I d=" u r n : o a s i s : n am e s : t c : x a cm l : e x am p l e : a t t r i b u t e : t e x t "><At t r i b u t eVa l u e DataType=" h t t p : //www.w3 . org /2001/XMLSchema#s t r i n g ">

Your med i ca l r e c o r d has been a c c e s s ed by :</ A t t r i b u t eVa l u e>

</At t r i bu t eAs s i gnmen t ><At t r i bu t eAs s i g nmen t DataType=" h t t p : //www.w3 . org /2001/XMLSchema#s t r i n g "

A t t r i b u t e I d=" u r n : o a s i s : n am e s : t c : x a cm l : e x am p l e : a t t r i b u t e : t e x t "><At t r i b u t eVa l u e DataType=" h t t p : //www.w3 . org /2001/XMLSchema#s t r i n g ">

J u l i u s H ibbe r t</ A t t r i b u t eVa l u e>

</At t r i bu t eAs s i gnmen t></ Ob l i g a t i o n>

</ Ob l i g a t i o n s>

Le obligation, dopo che sono state valutate, sono restituite al PEP con l’elemen-to sintattico <Obligation>, contenuto nel più generale elemento <Obligations>.Ogni elemento <Obligation> è composto dall’identificatore dell’azione e daivalori degli argomenti, un esempio è quello mostrato nel Listato 3.5.

Le obligation condizionano particolarmente l’esito finale di una richiesta diautorizzazione. Per modellare, invece, situazioni in cui sono richieste azioni ac-cessorie o semplici informazioni aggiuntive, il cui mancato reperimento o ese-cuzione non provoca conseguenze sulla decisione, si utilizza l’elemento advice.La struttura sintattica è uguale a quella delle obligation con la sola differenzache FulfillOn è sostituito da AppliesTo, e sono restituiti al PEP con l’elementosintattico <AssociatedAdvice>.

3.1.5 Richieste e Risposte

La sintassi descritta fino a questo momento riguarda esclusivamente gli ele-menti valutabili dal PDP, a cui si aggiunge la definizione delle richieste, cioèl’elemento XML <Request>, e delle relative risposte, cioè <Response>. La sin-tassi degli elementi è definita in forma XML per semplificare l’esposizione deirequisiti funzionali del PDP, ma nell’implementazione si possono definire ancherichieste con sintassi diversa, come descritto in Sezione 2.2.1.

Una richiesta di autorizzazione è definita da attributi che specificano l’azioneche un certo soggetto vuole svolgere su una risorsa. Ogni attributo è identifi-

Listato 3.6: Esempio di richiesta autorizzativa<Request xmlns=" u r n : o a s i s : n am e s : t c : x a cm l : 3 . 0 : co r e : s chema :wd −17"

xm l n s : x s i=" h t t p : //www.w3 . org /2001/XMLSchema− i n s t a n c e "x s i : s c h emaLo c a t i o n=" u r n : o a s i s : n am e s : t c : x a cm l : 3 . 0 : co r e : s chema :wd −17"CombinedDec i s ion=" f a l s e " R e t u r nP o l i c y I d L i s t=" f a l s e "><A t t r i b u t e s

Category=" u r n : o a s i s : n am e s : t c : x a cm l : 1 . 0 : s u b j e c t −c a t e g o r y : a c c e s s−s u b j e c t ">

<A t t r i b u t e I n c l u d e I n R e s u l t=" f a l s e "A t t r i b u t e I d=" u r n : o a s i s : n am e s : t c : x a cm l : 3 . 0 : s u b j e c t : s u b j e c t −i d "><At t r i b u t eVa l u e DataType=" h t t p : //www.w3 . org /2001/XMLSchema#s t r i n g ">

J u l i u s H ibbe r t</ A t t r i b u t eVa l u e></ A t t r i b u t e><A t t r i b u t e I n c l u d e I n R e s u l t=" f a l s e "

A t t r i b u t e I d=" u r n : o a s i s : n am e s : t c : x a cm l : 3 . 0 : s u b j e c t : s u b j e c t −r o l e "><At t r i b u t eVa l u e DataType=" h t t p : //www.w3 . org /2001/XMLSchema#s t r i n g ">

doc to r</ A t t r i b u t eVa l u e></ A t t r i b u t e><A t t r i b u t e I n c l u d e I n R e s u l t=" f a l s e "

A t t r i b u t e I d=" u r n : o a s i s : n am e s : t c : x a cm l : 3 . 0 : s u b j e c t : d o c t o r −i d "><At t r i b u t eVa l u e DataType=" h t t p : //www.w3 . org /2001/XMLSchema#s t r i n g ">

jh1234</ A t t r i b u t eVa l u e></ A t t r i b u t e>

</ A t t r i b u t e s><A t t r i b u t e s Category=" u r n : o a s i s : n am e s : t c : x a cm l : 3 . 0 : a t t r i b u t e −

c a t e g o r y : r e s o u r c e "><A t t r i b u t e I n c l u d e I n R e s u l t=" f a l s e "

A t t r i b u t e I d=" u r n : o a s i s : n am e s : t c : x a cm l : 3 . 0 : r e s o u r c e : r e s o u r c e −i d "><At t r i b u t eVa l u e DataType=" h t t p : //www.w3 . org /2001/XMLSchema#anyURI">

med i ca l r e c o r d</ A t t r i b u t eVa l u e></ A t t r i b u t e>

</ A t t r i b u t e s><A t t r i b u t e s Category=" u r n : o a s i s : n am e s : t c : x a cm l : 3 . 0 : a t t r i b u t e −

c a t e g o r y : a c t i o n "><A t t r i b u t e I n c l u d e I n R e s u l t=" f a l s e "

A t t r i b u t e I d=" u r n : o a s i s : n am e s : t c : x a cm l : 3 . 0 : a c t i o n : a c t i o n −i d "><At t r i b u t eVa l u e DataType=" h t t p : //www.w3 . org /2001/XMLSchema#s t r i n g ">

read</ A t t r i b u t eVa l u e></ A t t r i b u t e>

</ A t t r i b u t e s></Request>

cato da un nome, una categoria e uno o più valori. Un esempio di richiesta èmostrato nel Listato 3.6.

Nella richiesta sono presenti anche dei parametri del processo di valuta-zione, come ad esempio <CombinedDecision> per l’esecuzione della decisionecombinata di richieste descritta in [23].

A ogni richiesta corrisponde un risultato, <Result>, che contiene la decisio-ne presa dal PDP e le eventuali obbligazioni che il PEP deve eseguire. Tutti irisultati prodotti compongono la risposta. Oltre al risultato ci possono ancheessere informazioni aggiuntive, come la descrizione di cause di errore riportatenell’attributo <Status>. Un esempio di risposta, con dei risultati al suo interno,è mostrata nel Listato 3.7.

Listato 3.7: Esempio di risposta<Response xmlns=" u r n : o a s i s : n am e s : t c : x a cm l : 3 . 0 : co r e : s chema :wd −17"

xm l n s : x s i=" h t t p : //www.w3 . org /2001/XMLSchema− i n s t a n c e "x s i : s c h emaLo c a t i o n=" u r n : o a s i s : n am e s : t c : x a cm l : 3 . 0 : co r e : s chema :wd −17"><Re su l t>

<Dec i s i o n>Permit</ Dec i s i o n><Sta tu s>

<StatusCode Value=" u r n : o a s i s : n am e s : t c : x a cm l : 1 . 0 : s t a t u s : o k " /></ Sta tu s><Ob l i g a t i o n s>

<Ob l i g a t i o n Ob l i g a t i o n I d="u r n : o a s i s : n am e s : t c : x a cm l : e x am p l e : o b l i g a t i o n : l o g ">

<At t r i bu t eAs s i gnmen t DataType=" h t t p : //www.w3 . org /2001/XMLSchema#s t r i n g "

A t t r i b u t e I d=" u r n : o a s i s : n am e s : t c : x a cm l : e x am p l e : a t t r i b u t e : t e x t "><At t r i b u t eVa l u e DataType=" h t t p : //www.w3 . org /2001/XMLSchema#s t r i n g

">J u l i u s H ibbe r t

</ A t t r i b u t eVa l u e></At t r i bu t eAs s i gnmen t><At t r i bu t eAs s i gnmen t DataType=" h t t p : //www.w3 . org /2001/XMLSchema#

s t r i n g "A t t r i b u t e I d=" u r n : o a s i s : n am e s : t c : x a cm l : e x am p l e : a t t r i b u t e : t e x t "><At t r i b u t eVa l u e DataType=" h t t p : //www.w3 . org /2001/XMLSchema#s t r i n g

">l og i n p r e s c r i p t i o n system

</ A t t r i b u t eVa l u e></At t r i bu t eAs s i gnmen t>

</ Ob l i g a t i o n></ Ob l i g a t i o n s>

</ Re su l t></Response>

3.1.6 Politiche del caso di studio

Il progetto epSOS propone una serie di politiche per l’applicazione delle re-gole di comunicazione delle informazioni sanitarie tra le varie nazioni, comeillustrato in Figura 2.3.

Le politiche valutate con attenzione tra quelle presenti in epSOS, sono quelleper i Patient Summary e le ePrescription. Le politiche sono molto simili tra loroe regolano le operazioni di lettura di una cartella clinica o di una prescrizioneelettronica. La decisione è presa in base al ruolo e ai permessi accordati al sog-getto che richiede le informazioni. Nel dettaglio, la cartella clinica può essereletta soltanto da un dottore, mentre le prescrizioni sia da un dottore che da unfarmacista. Seguendo le specifiche epSOS, i permessi sono definiti come stringhecon prefisso PRD e a cui seguono tre cifre, ad esempio PRD-004.

Il sistema definito da epSOS si avvale di gateway intermedi, gli NCP, che valu-tano le decisioni prese dalle politiche ed eseguono precise operazioni a secondadel valore di decisione. Se consideriamo però la situazione ristretta al solo si-stema di controllo degli accessi, un valido elemento di studio è la definizione

di alcune obbligazioni collegate alle politiche. Valutando i requisiti funzionalidi epSOS sono state definite delle obbligazioni per preservare la confidenzialitàe la sicurezza dei dati del paziente. Le obbligazioni definite sono:

- invio di una e-mail al paziente per segnalare un caso di tentato accessonon autorizzato alla cartella clinica o alle prescrizioni;

- registrazione in un file di log di tutti i soggetti che vengono autorizzatiall’accesso alla cartella clinica o alle prescrizioni.

Le obbligazioni si possono applicare ad entrambi i casi di studio presentatie sono coerenti con la finalità di epSOS di assicurare la confidenzialità dei datisanitari.

Le politiche definite nel progetto europeo sono scritte secondo la sintassi diXACML 2.0, visto abbiamo preso come versione di riferimento la 3.0, questepolitiche sono state trasformate nella nuova sintassi, assicurando la conformitàcon i requisiti per cui sono state definite.

La politica per la gestione della risorsa Patient Summary, riportata nel Lista-to 3.8, controlla nel target il ruolo del soggetto richiedente, lo scopo e il tipodi risorsa richiesta, e inoltre contiene due regole e le obbligazioni descritte inprecedenza. La prima regola, definita con effetto permit, controlla i permessidel soggetto e se è richiesta un’azione Read. La seconda invece restituisce sem-pre deny, visto che non ci sono né target né condizione. Utilizzando l’algoritmopermit-overrides è possibile combinare i valori di decisione.

Listato 3.8: Policy epSOS per Patient Summary<Po l i c y xmlns=" u r n : o a s i s : n am e s : t c : x a cm l : 3 . 0 : co r e : s chema :wd −17"

xm l n s : x s i=" h t t p : //www.w3 . org /2001/XMLSchema− i n s t a n c e "x s i : s c h emaLo c a t i o n=" u r n : o a s i s : n am e s : t c : x a cm l : 3 . 0 : co r e : s chema :wd −17h t t p : // docs . o a s i s−open . org / xacml /3 .0/ xacml−core−v3−schema−wd−17. xsd "P o l i c y I d="summary" Ve r s i on=" 1 .0 "Ru leCombin ingAlg Id=" u r n : o a s i s : n am e s : t c : x a cm l : 3 . 0 : r u l e −combining−

a l g o r i t hm : p e rm i t−o v e r r i d e s "MaxDelegat ionDepth="1"><Target>

<AnyOf><Al lO f>

<Match MatchId=" u r n : o a s i s : n am e s : t c : x a cm l : 1 . 0 : f u n c t i o n : s t r i n g −equa l ">

<At t r i b u t eVa l u e DataType=" h t t p : //www.w3 . org /2001/XMLSchema#s t r i n g">

TREATEMENT</ At t r i b u t eVa l u e><At t r i b u t eD e s i g n a t o r DataType=" h t t p : //www.w3 . org /2001/XMLSchema#

anyURI"MustBePresent=" f a l s e "Category=" u r n : o a s i s : n am e s : t c : x a cm l : 3 . 0 : a t t r i b u t e −

c a t e g o r y : s u b j e c t "A t t r i b u t e I d=" u r n : o a s i s : n am e s : t c : x a cm l : 1 . 0 : s u b j e c t : p u r p o s e o f u s e "

/></Match>

</A l lO f></AnyOf><AnyOf>

<Al lO f><Match MatchId=" u r n : o a s i s : n am e s : t c : x a cm l : 1 . 0 : f u n c t i o n : s t r i n g −equa l "

><At t r i b u t eVa l u e DataType=" h t t p : //www.w3 . org /2001/XMLSchema#s t r i n g

">med i ca l doc to r

</ A t t r i b u t eVa l u e><At t r i b u t eD e s i g n a t o r DataType=" h t t p : //www.w3 . org /2001/XMLSchema#


c a t e g o r y : s u b j e c t "A t t r i b u t e I d=" u r n : o a s i s : n am e s : t c : x a cm l : 1 . 0 : s u b j e c t : r o l e " />

</Match></A l lO f>

</AnyOf><AnyOf>

<Al lO f><Match MatchId=" u r n : o a s i s : n am e s : t c : x a cm l : 1 . 0 : f u n c t i o n : s t r i n g −equa l "

><At t r i b u t eVa l u e DataType=" h t t p : //www.w3 . org /2001/XMLSchema#s t r i n g

">34133−9

</ A t t r i b u t eVa l u e><At t r i b u t eD e s i g n a t o r DataType=" h t t p : //www.w3 . org /2001/XMLSchema#


c a t e g o r y : r e s o u r c e "A t t r i b u t e I d=" u r n : o a s i s : n am e s : t c : x a cm l : 1 . 0 : r e s o u r c e : r e s o u r c e −i d "

/></Match>

</A l lO f></AnyOf>

</Target><Rule Ru l e I d=" r u l e 1 " E f f e c t="Permit ">

<Target><AnyOf>

<Al lO f><Match MatchId=" u r n : o a s i s : n am e s : t c : x a cm l : 1 . 0 : f u n c t i o n : s t r i n g −

equa l "><At t r i b u t eVa l u e DataType=" h t t p : //www.w3 . org /2001/XMLSchema#

s t r i n g ">Read

</ A t t r i b u t eVa l u e><At t r i b u t eD e s i g n a t o r DataType=" h t t p : //www.w3 . org /2001/XMLSchema

#anyURI"MustBePresent=" f a l s e "Category=" u r n : o a s i s : n am e s : t c : x a cm l : 3 . 0 : a t t r i b u t e −

c a t e g o r y : a c t i o n "A t t r i b u t e I d=" u r n : o a s i s : n am e s : t c : x a cm l : 1 . 0 : a c t i o n : a c t i o n −i d " /

></Match>

</A l lO f></AnyOf>

</Target><Cond i t i on>

<Apply Func t i on I d=" u r n : o a s i s : n am e s : t c : x a cm l : 1 . 0 : f u n c t i o n : s t r i n g −

s ub s e t "><Apply Func t i on I d=" u r n : o a s i s : n am e s : t c : x a cm l : 1 . 0 : f u n c t i o n : s t r i n g −bag

"><At t r i b u t eVa l u e DataType=" h t t p : //www.w3 . org /2001/XMLSchema#s t r i n g

">PRD−003

</ A t t r i b u t eVa l u e><At t r i b u t eVa l u e DataType=" h t t p : //www.w3 . org /2001/XMLSchema#s t r i n g

">PRD−005


">PRD−010


">PRD−016

</ A t t r i b u t eVa l u e></Apply><At t r i b u t eD e s i g n a t o r DataType=" h t t p : //www.w3 . org /2001/XMLSchema#

anyURI"MustBePresent=" f a l s e "Category=" u r n : o a s i s : n am e s : t c : x a cm l : 3 . 0 : a t t r i b u t e −c a t e g o r y : s u b j e c t

"A t t r i b u t e I d=" u r n : o a s i s : n am e s : t c : x a cm l : 1 . 0 : s u b j e c t : h l 7 . p e rm i s s i o n "

/></Apply>

</ Cond i t i on></Rule><Rule Ru l e I d=" r u l e d e n y " E f f e c t="Deny"></Rule><Ob l i g a t i o nE x p r e s s i o n s>

<Ob l i g a t i o nE x p r e s s i o n F u l f i l l O n="Permit "Ob l i g a t i o n I d=" u r n : o a s i s : n am e s : t c : x a cm l : o b l i g a t i o n : l o g "><At t r i b u t eA s s i g nmen tExp r e s s i o n

A t t r i b u t e I d=" u r n : o a s i s : n am e s : t c : x a cm l : 3 . 0 : a t t r i b u t e : s u b j e c t "><At t r i b u t eVa l u e DataType=" h t t p : //www.w3 . org /2001/XMLSchema#s t r i n g ">

<At t r i b u t eD e s i g n a t o r DataType=" h t t p : //www.w3 . org /2001/XMLSchema#s t r i n g "

MustBePresent=" f a l s e "Category=" u r n : o a s i s : n am e s : t c : x a cm l : 1 . 0 : s u b j e c t −c a t e g o r y : s u b j e c t

"A t t r i b u t e I d=" u r n : o a s i s : n am e s : t c : x a cm l : 3 . 0 : s u b j e c t : d o c t o r −i d " />

</ A t t r i b u t eVa l u e></ At t r i b u t eA s s i g nmen tExp r e s s i o n><At t r i b u t eA s s i g nmen tExp r e s s i o n

A t t r i b u t e I d=" u r n : o a s i s : n am e s : t c : x a cm l : 3 . 0 : a t t r i b u t e : r e s o u r c e "><At t r i b u t eD e s i g n a t o r DataType=" h t t p : //www.w3 . org /2001/XMLSchema#

s t r i n g "MustBePresent=" f a l s e "Category=" u r n : o a s i s : n am e s : t c : x a cm l : 3 . 0 : a t t r i b u t e −

c a t e g o r y : r e s o u r c e "A t t r i b u t e I d=" u r n : o a s i s : n am e s : t c : x a cm l : 3 . 0 : r e s o u r c e : r e s o u r c e −i d " /

></ At t r i b u t eA s s i g nmen tExp r e s s i o n>

</ Ob l i g a t i o nE x p r e s s i o n><Ob l i g a t i o nE x p r e s s i o n F u l f i l l O n="Deny"

Ob l i g a t i o n I d=" u r n : o a s i s : n am e s : t c : x a cm l : o b l i g a t i o n : m a i l "><At t r i b u t eA s s i g nmen tExp r e s s i o n

A t t r i b u t e I d=" u r n : o a s i s : n am e s : t c : x a cm l : 3 . 0 : a t t r i b u t e : m a i l t o ">

<At t r i b u t eD e s i g n a t o r DataType=" h t t p : //www.w3 . org /2001/XMLSchema#s t r i n g "

MustBePresent=" f a l s e "Category=" u r n : o a s i s : n am e s : t c : x a cm l : 3 . 0 : a t t r i b u t e −

c a t e g o r y : r e s o u r c e "A t t r i b u t e I d=" u r n : o a s i s : n am e s : t x : x a cm l : 3 . 0 : r e s o u r c e : r e s o u c e −

i d : em a i l " /></ At t r i b u t eA s s i g nmen tExp r e s s i o n><At t r i b u t eA s s i g nmen tExp r e s s i o n

A t t r i b u t e I d=" u r n : o a s i s : n am e s : t c : x a cm l : 3 . 0 : a t t r i b u t e : t e x t "><At t r i b u t eVa l u e DataType=" h t t p : //www.w3 . org /2001/XMLSchema#s t r i n g ">

Your med i ca l r e c o r d has beenr e qu e s t e d by EpSOS s u b j e c t

</ A t t r i b u t eVa l u e></ At t r i b u t eA s s i g nmen tExp r e s s i o n>

</ Ob l i g a t i o nE x p r e s s i o n></ Ob l i g a t i o nE x p r e s s i o n s>

</ Po l i c y>

Una richiesta epSOS generata dal NCP contiene le informazioni della richiestapresentata nel Listato 3.9. Gli attributi della richiesta definiscono il ruolo delsoggetto richiedente, i suoi permessi e la tipologia di risorsa a cui vuole accede-re. Nella richiesta però non sono presenti tutti gli attributi necessari anche allavalutazione delle obbligazioni, in quel caso il PDP interroga il PIP e ne richiedeil recupero.

Listato 3.9: Request epSOS per la lettura del Patient Summary<Request xmlns=" u r n : o a s i s : n am e s : t c : x a cm l : 2 . 0 : c o n t e x t : s c h ema : o s "

xm l n s : x s i=" h t t p : //www.w3 . org /2001/XMLSchema− i n s t a n c e "x s i : s c h emaLo c a t i o n=" u r n : o a s i s : n am e s : t c : x a cm l : 2 . 0 : c o n t e x t : s c h ema : o s

acc e s s_con t r o l−xacml−2.0− contex t−schema−os . xsd ">

<A t t r i b u t e DataType=" h t t p : //www.w3 . org /2001/XMLSchema#s t r i n g "A t t r i b u t e I d=" u r n : o a s i s : n am e s : t c : x a cm l : 2 . 0 : s u b j e c t : r o l e "><At t r i b u t eVa l u e>

med i ca l doc to r</ A t t r i b u t eVa l u e>

</ A t t r i b u t e><A t t r i b u t e DataType=" h t t p : //www.w3 . org /2001/XMLSchema#s t r i n g "

A t t r i b u t e I d=" u r n : o a s i s : n am e s : t c : x s p a : 1 . 0 : s u b j e c t : p u r p o s e o f u s e "><At t r i b u t eVa l u e>

TREATMENT</ At t r i b u t eVa l u e>

</ A t t r i b u t e><A t t r i b u t e DataType=" h t t p : //www.w3 . org /2001/XMLSchema#s t r i n g "

A t t r i b u t e I d=" u r n : o a s i s : n am e s : t c : x s p a : 1 . 0 : s u b j e c t : h l 7 : p e r m i s s i o n "><At t r i b u t eVa l u e>PRD−003 </ A t t r i b u t eVa l u e><At t r i b u t eVa l u e>PRD−005 </ A t t r i b u t eVa l u e><At t r i b u t eVa l u e>PRD−010 </ A t t r i b u t eVa l u e><At t r i b u t eVa l u e>PRD−016 </ A t t r i b u t eVa l u e>

</ A t t r i b u t e><Resource>

<A t t r i b u t e DataType=" h t t p : //www.w3 . org /2001/XMLSchema#s t r i n g "A t t r i b u t e I d=" u r n : o a s i s : n am e s : t c : x a cm l : 1 . 0 : r e s o u r c e : r e s o u r c e −i d "><At t r i b u t eVa l u e> 34133−9 </ A t t r i b u t eVa l u e>

</ A t t r i b u t e>

3.2 semantica di xacml 35

</Resource><Act ion>

<A t t r i b u t e DataType=" h t t p : //www.w3 . org /2001/XMLSchema#s t r i n g "A t t r i b u t e I d=" u r n : o a s i s : n am e s : t c : x a cm l : 1 . 0 : a c t i o n : a c t i o n −i d "><At t r i b u t eVa l u e>Read</ A t t r i b u t eVa l u e>

</ A t t r i b u t e></Act ion><Envi ronment></Envi ronment>

</Request>

La politica per la gestione della prescrizione elettronica è simile alla prece-dente e non se ne riporta il codice XACML, sarà comunque descritta e utilizzatanei prossimi capitoli.

3.2 semantica di xacml

Lo standard comprende, oltre alla definizione sintattica degli elementi, ladescrizione in linguaggio naturale dei requisiti funzionali da soddisfarenell’implementazione del PDP e del PEP.

Il processo di valutazione svolto dal PDP definisce qual è la decisione presain base alle politiche disponibili e quali sono le eventuali azioni accessorie daeseguire. Il risultato del PDP, in generale, è una decisione con eventuali obbli-gazioni. Il PEP, sulla base della decisione ricevuta e all’esecuzione delle azioniaccessorie, applica l’esito finale.

All’interno del PDP è utilizzato l’insieme dei valori di decisione esteso,ma la decisione comunicata al PEP è riportata ai quattro valori descritti inSezione 2.2.2.

Se nel PDP si hanno più politiche o più insiemi di politiche, si gestisconocome se fossero all’interno di un unico elemento, cioè si calcola un’unica deci-sione finale in base all’algoritmo di combinazione indicato per il PDP. Andiamoadesso nel dettaglio della valutazione dei singoli elementi delle politiche, finoad arrivare alla semantica del PEP.

3.2.1 Target

I target sono l’elemento fondamentale per definire l’applicabilità di regole, po-litiche e insiemi di politiche alle richieste. La loro valutazione è eseguita sullabase degli attributi contenuti nella richiesta o nel contesto, visto che non si han-no differenze semantiche, se non il passaggio intermedio dal PIP. Per praticitàdi esposizione, si assume che tutti gli attributi siano presenti nella richiesta.

L’elemento base della valutazione dei target è la funzione di match. Le fun-zioni di match confrontano l’insieme dei valori recuperati dalla richiesta conil letterale specificato nell’elemento match. Si tratta di funzioni booleane che,in caso di errore di valutazione, restituiscono il valore indeterminate; i risultati

ottenibili sono quindi: true, false e indeterminate. Se l’operazione di recupero deivalori dovesse generare errori si ha indeterminate.

Negli elementi AttributeSelector e AttributeDesignator è presente inoltre an-che l’attributo MustBePresent, che permette di scegliere con un valore booleano,quale decisione prendere quando l’insieme dei valori recuperati dalla richiestaè vuoto. Quando è definito con valore true il valore restituito dalla funzionedi match è indeterminate. Quando l’attributo è false, che è il valore di default,il valore restituito dalla funzione è false. Nella nostra trattazione consideriamoquesto attributo sempre definito con valore false.

Quando le operazioni di recupero non generano problemi, i risultati gene-rati dalla valutazione della funzione, tra i valori recuperati e il letterale, sonoottenuti alle condizione riportate in Tabella 3.1.

true Almeno un valore selezionato dalla richiesta

soddisfa la funzione di match

indeterminate Almeno un valore nell’esecuzione della funzione

genera un errore

false Tutti i valori non soddisfano la funzione di match

Tabella 3.1: Semantica funzioni di match

La valutazione delle condizioni riportate in Tabella 3.1 deve essere eseguitaseguendo l’ordine dei casi, cioè, per esempio, al verificarsi del caso true il casoindeterminate è escluso anche se vi è un valore che genera errore.

Il risultato finale della valutazione del target è uno tra i valori: match, no-match o indeterminate. Questo risultato è costruito componendo i valori nellastruttura gerarchica <AnyOf>-<AllOf>-<Match>. Il valore match è ottenuto quan-do tutti gli <AnyOf> hanno valore match; il target assume il valore no-match sealmeno un elemento <AnyOf> ha valore no-match, altrimenti si ha indetermina-

te. I valori del target sono ottenuti quindi in base alle condizioni mostrate inTabella 3.2.

Valori <AnyOf> Valore target

Tutti match match

Almeno un no-match no-match

Altrimenti indeterminate

Tabella 3.2: Semantica Target

Procedendo nella struttura, si deve determinare il valore dell’elemento<AnyOf>. Questo assume il valore match se almeno un <AllOf> ha valore match,

Valori <AllOf> Valore <AnyOf>

Almeno un match match

Nessun match e almeno un indeterminate indeterminate

Tutti no-match no-match

Tabella 3.3: Semantica AnyOf

no-match se tutti sono tali e indeterminate se non vi è alcun match e almeno unindeterminate, come mostrato in Tabella 3.3.

Infine la semantica, riportata in Tabella 3.4, degli elementi <AllOf>. In questocaso si ha match se tutte le funzioni di match hanno risultato true, mentre se c’èalmeno un indeterminate si ottiene indeterminate; altrimenti si hanno tutti false equindi il risultato è no-match.

Valori <Match> Valore <AllOf>

Almeno un true match

Nessun false e almeno un indeterminate indeterminate

Almeno un false no-match

Tabella 3.4: Semantica AllOf

Sulla base dei risultati di tutte le funzione di match e delle tabelle soprapresentate è possibile calcolare il valore di match di tutto il target. Riassumendo,per il caso match si ha che:

il target è in match con una richiesta se tutti gli <AnyOf> sono inmatch; un <AnyOf> è in match se almeno un <AllOf> è in match; un<AllOf> è in match se tutte le funzioni <Match> sono valutate cometrue.

Le altre situazioni che portano ai risultati no-match e indeterminate del target,possono essere ottenute facilmente a partire dalle Tabelle 3.2, 3.3 e 3.4.

Nel caso in cui il target non contenga alcuna espressione di match, allora laregola, la politica o l’insieme di politiche che lo contiene è definito in match conogni richiesta.

3.2.2 Rule

La valutazione di una rule si basa sul target e sulla condizione, la cui espressio-ne, come nel caso del target, può assumere tre valori: true, false e indeterminate.Se il target è valutato no-match non importa continuare nella valutazione deglialtri elementi e la valutazione della rule restituisce not-applicable. Altrimenti, se


il target è in match e la condizione è true si restituisce l’effetto con cui è definitala rule, mentre in caso di condizione false si ha not-applicable. Per il caso indeter-

minate del target o della condizione si ottiene il corrispondente valore esteso aseconda dell’effetto definito nella rule. La semantica è riassunta in Tabella 3.5.

Target Valori Condition Valore Rule

match true Effetto

match false not-applicable

match indeterminate indeterminate-P se Effect è permit

indeterminate-D se Effect è deny

no-match - not-applicable

indeterminate - indeterminate-P se Effect è permit

indeterminate-D se Effect è deny

Tabella 3.5: Semantica Rule

3.2.3 Policy e Policy Set

Il valore di decisione di una policy o di un policy set è definito in relazione aglielementi interni, cioè il target, le obbligazioni e la chiamata dell’algoritmo dicombinazione.

Consideriamo le policy. Il primo elemento da valutare è il target che ne stabi-lisce l’applicabilità. In caso di match si procede con la valutazione delle regolesecondo l’algoritmo di combinazione, mentre in caso di no-match non c’è altraoperazione da eseguire e si restituisce not-applicable. Il caso indeterminate preve-de, a differenza delle versioni precedenti di XACML, la valutazione delle regolecontenute per associare il valore più corretto tra indeterminate-D, indeterminate-Po indeterminate-DP. La semantica per la policy è riportata in Tabella 3.6 e quellaper la gestione del caso indeterminate in Tabella 3.8.

La semantica dei policy set è analoga a quella definita per le politiche, con lasola differenza che gli algoritmi di combinazione non sono applicati su regolema su politiche; in Tabella 3.7 è riportata la semantica.

Il valore finale della valutazione di politiche o insiemi di politiche, trannenel caso no-match, dipende sempre dal valore dell’algoritmo di combinazione.L’utilizzo della sintassi estesa di indeterminate comporta un aggravio al proces-so di valutazione, dato che regole o politiche, a seconda dei casi, sono semprevalutate, ma al solo scopo di definire quale potrebbe essere la decisione poten-ziale, se non si avesse avuto un errore nel target. Il valore preciso di indetermi-

nate della politica o dell’insieme delle politiche è definito alla luce del valoredell’algoritmo di combinazione, come mostrato dalle condizioni in Tabella 3.8.


Target Valore Policy

match Definito dall’algoritmo

no-match not-applicable

indeterminate vedi Tabella 3.8

Tabella 3.6: Semantica Policy

Target Valore Policy Set

match Definito dall’algoritmo

no-match not-applicable

indeterminate vedi Tabella 3.8

Tabella 3.7: Semantica Policy Set

Questo tipo di approccio alla gestione dei valori indeterminate è stato intro-dotto nell’ultima versione di XACML, ma non ci convince il fatto che si debbanofare molte valutazioni aggiuntive per ottenere valori di decisione esclusivamen-te a utilizzo interno del PDP. Visto che, come detto in Sezione 2.2.2, il valorerestituito dal PDP può essere soltanto uno tra le quattro decisioni della versionebase e non della versione estesa. In caso di politiche molto complesse, questoprocedimento aggiuntivo potrebbe portare a consistenti incrementi dei tempi divalutazione. Inoltre, il caso not-applicable presente in Tabella 3.8 afferma che seil target è indeterminate e l’algoritmo restituisce not-applicable, allora il risultatofinale è not-applicable, fatto che contrasta nettamente con le versioni precedentidi XACML, dove si otteneva indeterminate. Non si vede un’applicazione praticadi questo caso, che anzi può portare a situazioni in cui non viene individuatoun errore nella valutazione del target. Per attenersi strettamente allo standard,si prende comunque come riferimento la Tabella 3.8 per la gestione dei valoriindeterminate, riservandoci però di criticare le modifiche attuate da OASIS.

Algoritmi di Combinazione

Gli algoritmi di combinazione permettono di creare un unico valore finale com-binando opportunamente i valori restituiti da regole, politiche o insiemi dipolitiche. Nello standard è riportata la definizione di alcuni algoritmi per lagestione delle situazioni più comuni, vi è poi la possibilità di implementareun algoritmo personalizzato a seconda delle esigenze. Tutti gli algoritmi nel-la nuova versione dello standard sono definiti secondo la sintassi estesa delledecisioni.

Gli algoritmi di combinazione presenti in XACML si applicano sia per la com-binazione di regole che di politiche e seguono lo stesso comportamento. La


Combining algorithm value PolicySet or Policy value

not-applicable not-applicable

permit indeterminate-P

deny indeterminate-D

indeterminate indeterminate-DP

indeterminate-DP indeterminate-DP

indeterminate-P indeterminate-P

indeterminate-D indeterminate-D

Tabella 3.8: Semantic extended indeterminate

descrizione degli algoritmi di combinazione applicati a politiche è la seguente:

- permit-overrides: se una politica tra quelle considerate è valutata permit

allora il risultato è permit, mentre se una decisione è indeterminate allorail risultato è scelto tra indeterminate-D, indeterminate-P e indeterminate-DP,a seconda della valutazione delle altre politiche. Altrimenti se c’è almenouna decisione deny si restituisce deny, oppure se si hanno tutte politichenon applicabili la decisione è not-applicable. In altre parole, se si ha unadecisione permit questa ha la precedenza sulle altre.

- deny-overrides: l’algoritmo ha un comportamento speculare al precedente,però con l’effetto deny che ha la precedenza sugli altri.

- ordered-permit-overrides, ordered-deny-overrides: il comportamento di questialgoritmi è identico, rispettivamente, ai due precedenti, con l’eccezioneche l’ordine di valutazione delle singole politiche deve rispettare quellodi definizione nell’insieme delle politiche che si sta valutando.

- �rst-applicable: le politiche sono valutate in ordine di definizione e ladecisione finale è data dalla valutazione della prima politica applicabi-le il cui risultato sia diverso da not-applicable. Altrimenti si restituiscenot-applicable.

- only-one-applicable: l’algoritmo si applica soltanto alle politiche o agli in-siemi di politiche e assicura che vi sia soltanto una e una sola politica ap-plicabile. A differenza degli altri casi, l’algoritmo controlla prima i targetdelle politiche senza valutarle per trovare quella applicabile. Il risultatofinale è dato dalla valutazione dell’unica politica applicabile. Nel caso visiamo più politiche applicabili il risultato è indeterminate, mentre se nonce ne è nessuna si ottiene not-applicable.

- permit-unless-deny: l’algoritmo restituisce soltanto i valori permit o deny,con la decisione deny che ha la priorità su tutte le altre. Perciò, se una

decisione è deny il risultato è deny, mentre in tutti gli altri casi, quindianche con decisione indeterminate o not-applicable, si ottiene permit.

- deny-unless-permit: l’algoritmo è simmetrico al precedente, ma con l’effettopermit che ha la precedenza sugli altri.

Tutti gli algoritmi sopra presentati, ad eccezione di only-one-applicable, so-no definiti in modo analogo per la combinazione delle regole presenti in unapolitica.

La valutazione degli algoritmi influisce anche sull’insieme di obbligazioni re-stituite, dato che non vi è la certezza che tutte le politiche o regole presenti sianovalutate. Prendiamo ad esempio l’algoritmo permit-overrides, se al momento del-la valutazione della seconda politica questa restituisce permit, la computazionetermina e le obbligazioni restituite sono solo quelle della politica valutata; even-tuali altre obbligazioni di politiche successive non sono restituite. Da questo, sievince che l’insieme di obbligazioni generato dalla valutazione non è determi-nistico. Questa considerazione trova conferma anche nello pseudo-codice deglialgoritmi riportato nello standard. A titolo di esempio si riporta nel Listato 3.10

quello per l’algoritmo permit-overrides.

Listato 3.10: Algoritmo di combinazione permit-overridesDec i s i o n pe rm i tOve r r i d e sComb in i ngA lgo r i t hm (Node [ ] c h i l d r e n ) {Boolean atLeastOneErrorD = f a l s e ;Boolean atLeas tOneEr ro rP = f a l s e ;Boolean atLeastOneErrorDP = f a l s e ;Boolean atLeastOneDeny = f a l s e ;

f o r ( i=0 ; i < l eng thOf ( c h i l d r e n ) ; i++ ) {Dec i s i o n d e c i s i o n = c h i l d r e n [ i ] . e v a l u a t e ( ) ;i f ( d e c i s i o n == Deny ) {

atLeastOneDeny = t r u e ;c on t i nu e ;

}i f ( d e c i s i o n == Permit ) {

r e t u r n Permit ;}i f ( d e c i s i o n == NotApp l i c ab l e ) {

con t i nu e ;}i f ( d e c i s i o n == Ind e t e rm i n a t e {D}) {

atLeastOneErrorD = t r u e ;c on t i nu e ;

}i f ( d e c i s i o n == Ind e t e rm i n a t e {P}) {

atLeas tOneEr ro rP = t r u e ;c on t i nu e ;

}i f ( d e c i s i o n == Ind e t e rm i n a t e {DP}) {

atLeastOneErrorDP = t r u e ;c on t i nu e ;

}}i f ( atLeastOneErrorDP ) {

r e t u r n I n d e t e rm i n a t e {DP} ;

}i f ( a tLeas tOneEr ro rP & & ( atLeastOneErrorD | | atLeastOneDeny ) ) {

r e t u r n I n d e t e rm i n a t e {DP} ;}i f ( a tLeas tOneEr ro rP ) {

r e t u r n I n d e t e rm i n a t e {P} ;}i f ( atLeastOneDeny ) {

r e t u r n Deny ;}i f ( a tLeastOneErrorD ) {

r e t u r n I n d e t e rm i n a t e {D} ;}r e t u r n No tApp l i c ab l e ;}

Gli algoritmi deny-unless-permit e permit-unless-deny sono stati aggiunti nell’ul-tima versione di XACML e solo gli unici a restituire soltanto i valori permit e deny;lo pseudo-codice di deny-unless-permit è riportato nel Listato 3.11.

Listato 3.11: Algoritmo di combinazione deny-unless-permit

Dec i s i o n denyUn le s sPe rmi tComb in ingA lgo r i thm (Node [ ] c h i l d r e n ) {f o r ( i=0 ; i < l eng thOf ( c h i l d r e n ) ; i++ ) {

i f ( c h i l d r e n [ i ] . e v a l u a t e ( ) == Permit ) {r e t u r n Permit ;

}}r e t u r n Deny ;

}

3.2.4 Obligation e Advice

La decisione, calcolata secondo la semantica sopra descritta, è completata conle obligation e gli advice, quando presenti.

Un obligation o un advice è applicabile, cioè da valutare e restituire al livellosuperiore, soltanto se l’attributo FulfillOn o AppliesTo concorda con la decisionedella valutazione dell’elemento in cui è contenuto; nel caso delle regole, corri-sponde all’effetto per cui sono definite. Le obbligazioni valutate sono passatedi livello in livello finché la loro applicabilità resta valida. Questo significa chese un’obbligazione, ad esempio restituita da una regola, è definita per l’effettopermit e la politica che contiene la regola è valutata con un effetto diverso, alloral’obbligazione è scartata. Se vediamo il processo di valutazione delle richiestecome un albero che rappresenta la struttura delle politiche, un’obbligazione ar-riva fino alla radice, cioè al livello esterno del PDP, soltanto se a ogni livellodell’albero il suo attributo di applicabilità è uguale a quello della valutazio-ne dell’elemento corrente. Quando ad un livello si riceve un’obbligazione giàvalutata se ne controlla solo l’applicabilità, senza effettuare ulteriori valutazioni.

La valutazione nel PDP delle obbligazioni applicabili consiste nel recuperarei valori degli attributi definiti nelle espressioni. Se tutti i valori sono recupera-

ti senza problemi si crea l’elemento <Obligation> definito nel Listato 3.5 e sicontinua con il processo di valutazione della richiesta. Se la valutazione di unaobligation genera una situazione di errore, allora tutta la valutazione dell’ele-mento che la contiene è indeterminate. Si noti che la valutazione di un obligationè eseguita soltanto quando è applicabile, quindi, quando FulfillOn non concordacon la decisione corrente la obligation non può causare un risultato indetermina-

te. Per gli advice, invece, una valutazione indeterminate non ha mai effetti sullavalutazione finale degli altri elementi.

3.2.5 Policy Enforcement Point

La semantica del PEP, nello standard, non è definita in tutti i dettagli, ma vienespecificato un principio base da seguire: il PEP non assegna la risorsa se nonriesce a comprendere ed eseguire con successo le obbligazioni presenti nellarisposta del PDP.

Il PEP dopo aver chiesto, tramite il context handler, una decisione autorizzativaal PDP, ne aspetta la risposta e valuta le obbligazioni secondo l’algoritmo in baseal quale è definito. Nello standard sono presenti tre algoritmi: base, permit-biasede deny-biased. L’algoritmo base prevede che:

- se la decisione è permit e le obbligazioni sono eseguite con successo allorasi garantisce l’accesso, altrimenti in caso di errori la decisione da attuareè lasciata alla scelta dell’implementazione;

- se la decisione è deny si nega l’accesso solo se le obligation non generanoerrori, altrimenti in caso di errori la decisione da attuare è lasciata allascelta dell’implementazione;

- se la decisione è indeterminate o not-applicable non vi è alcunfunzionamento predefinito.

Oltre alla versione base dell’algoritmo si ha anche l’algoritmo deny-biased chegarantisce l’accesso se la decisione è permit e le obligation sono eseguite consuccesso, mentre in tutti gli altri casi nega l’accesso. L’algoritmo permit-biasedopera in modo speculare al precedente.

Quest’ultimo algoritmo può sembrare non corretto, dato che permette l’ac-cesso in tutti casi tranne quando si ha la decisione deny, ma è utile per model-lizzare situazioni in cui non si deve assicurare tanto la sicurezza di una risorsa,quanto la sua più completa disponibilità. Se prendiamo ad esempio un servizioweb che fornisce a tutti, tranne che ai soggetti presenti in una black list, infor-mazioni non di particolare importanza, si può usare quest’ultimo algoritmoper non comunicare informazioni quando il soggetto richiedente è tra quelliesclusi. Mentre in caso di valutazione non corretta o indefinita, visto il tipo diinformazioni, si effettua ugualmente la comunicazione.

3.2.6 Valutazione delle politiche del caso di studio

La richiesta del Listato 3.9 può essere valutata secondo la politica del Listato 3.8.Per fare questa valutazione si utilizza il tool HERASAF. Questo tool è però defi-nito rispetto alla sintassi di XACML 2.0, quindi abbiamo convertito le politiche ela richiesta alla versione precedente dello standard. Per completare anche la va-lutazione delle obbligazioni, si aggiungono gli attributi con l’indirizzo di postaelettronica del paziente e l’identificativo del dottore alla richiesta. Il risultatodella valutazione della richiesta è:

Decision: PERMIT

Obligation:

FulfillOn: PERMIT -

Action: urn:oasis:names:tc:xacml:obligation:log -

Attributes: urn:oasis:names:tc:xacml:1.0:attribute:subject,

urn:oasis:names:tc:xacml:1.0:resource

Cambiando il ruolo oppure alcuni valori dall’elenco dei permessi nellarichiesta, la decisione diventa deny e si ha il seguente risultato

Decision: DENY

Obligation:

FulfillOn: DENY -

Action: urn:oasis:names:tc:xacml:obligation:mail -

Attributes: urn:oasis:names:tc:xacml:3.0:attribute:mailto,

urn:oasis:names:tc:xacml:1.0:attribute:text

3.3 multiple decision profile

Tra i vari documenti di specifica collegati allo standard XACML c’è il MultipleDecision Profile [23] per la valutazione combinata di più richieste. Una richiestamultipla è formata da singole altre richieste che saranno valutate separatamentee i loro risultati combinati in un’unica decisione finale.

La richiesta di una decisione combinata si sceglie con l’attributo<CombinedDecision> presente in <Request>. Le richieste individuali sono de-finite in un elemento <Request> come un unico insieme di attributi. Per indi-viduare ciascun insieme di attributi corrispondente alle varie richieste, si pos-sono utilizzare vari approcci: espressioni XPath o attributo Scope, se si utilizzaun contesto formato da risorse gerarchiche come ad esempio documenti XML,oppure un riferimento esplicito a categorie di attributi attraverso l’elemento<MultiRequest>.

Quando il context-handler riceve la richiesta, crea una nuovo elemento<Request> per ogni richiesta individuale presente e la invia al PDP per valu-tare la decisione individuale. Raccolte tutte le decisioni si valuta la decisione

3.3 multiple decision profile 45

combinata applicando la prima, seguendo l’ordine di esposizione, decisionevalida tra le seguenti:

- se ci sono obligation o altre informazioni restituite con qualche risultatoindividuale si restituisce indeterminate;

- se tutti i risultati individuali hanno la stessa decisione si restituisce ilvalore comune;

- altrimenti indeterminate.

La specifica è molto semplice e non sono necessarie modifiche significative al-la struttura delle componenti atte alla valutazione delle richieste, in quanto ilcompito può essere demandato al context-handler.

4U N L I N G U A G G I O F O R M A L E P E R I L C O N T R O L L O D E G L IA C C E S S I

La presentazione di sintassi e requisiti funzionali dello standard XACML, effet-tuata nei capitoli precedenti, evidenzia che la sintassi XML non è di agevolelettura e scrittura, e che non vi è una semantica formale che definisce il proces-so di valutazione delle richieste. Per sopperire a tali difficoltà in questo capitolopresentiamo una sintassi alternativa per il linguaggio delle politiche, sulla qua-le è possibile costruire una semantica formale dei livelli di valutazione del PDP

e del PEP.La definizione della semantica sulla sintassi alternativa è utile per formaliz-

zare nel dettaglio tutti i passaggi del processo di valutazione; con queste regoleè infatti possibile avere delle linee guida per la creazione di una libreria per ladefinizione del comportamento del PDP e del PEP. Dal lato formale, la semanticaoffre la possibilità di effettuare analisi su politiche e di verificare proprietà delcontrollo degli accessi.

Nella sezione successiva introduciamo la sintassi del linguaggio dellepolitiche e a seguire la definizione delle regole semantiche.

4.1 sintassi

La sintassi alternativa di XACML 3.0 definisce un linguaggio formale per rea-lizzare politiche di controllo degli accessi. Tale linguaggio è chiamato FormalAccess Control Policy Language (FACPL) (da leggere FackPol).

Lo sviluppo di questo linguaggio si basa sull’idea proposta in [14] per laversione 2.0 dello standard, rivista alla luce della nuova versione di XACML econ l’inserimento di ulteriori elementi funzionali.

Nel linguaggio è stato inserito il livello di valutazione del PEP e modificatasensibilmente la semantica per trattare le obbligazioni e le modifiche sui target.Per una completa formalizzazione dei passi di valutazione è definita anche lasintassi alternativa degli attributi delle richieste e degli elementi delle risposte;si identifica questa parte come la sintassi del contesto.

FACPL non vuole essere una riproposizione semplificata di tutti gli elementidello standard, ma un sottoinsieme consistente di elementi, facili da scrivere e

47

48 un linguaggio formale per il controllo degli accessi

comprendere, che però non compromettono il potere espressivo del linguaggio.A tal proposito, non sono stati introdotti costrutti per la definizione e la valuta-zione di espressioni XPath nella valutazione dei target, e riferimenti a funzionidefinite in <Variable> o a policy e policy set.

La sintassi di FACPL è riportata in Tabella 4.1 e si basa su una grammaticaBNF estesa. I simboli ’?’, ’*’ e ’+’, caratteristici delle espressioni regolari, hannoil seguente significato: ’?’ indica che l’elemento a cui si riferisce è opzionale, ’*’definisce una sequenza anche vuota di elementi, mentre ’+’ rappresenta unasequenza dove almeno un elemento è richiesto.

Nella sintassi si definisce una struttura, chiamata Policy Authorization Fra-mework (PAF), che è formata dal PEP e dal PDP. La definizione del PEP consistenell’indicare l’algoritmo di gestione delle obbligazioni, mentre per il PDP si hala definizione delle politiche di accesso e dall’algoritmo di combinazione da uti-lizzare per combinare i differenti elementi contenuti. La gestione delle politichenon è demandata al PAP, ma si assume che le politiche necessarie per fare lavalutazione delle richieste siano già state recuperate e quindi presenti nel PDP.Le modalità di recupero dal PAP non sono collegate alla definizione di FACPL.

Gli algoritmi disponibili sono quelli descritti nel Capitolo 3 e, come si vededalla sintassi, only-one-applicable è disponibile solo per gli insiemi di politiche. Sipuò comunque definire algoritmi di combinazione personalizzati da utilizzarenel processo di valutazione. Descriviamo adesso con più dettaglio la grammati-ca in Tabella 4.1. Si noti che per riferirci ad un non terminale, cioè una categoriasintattica, utilizzeremo il carattere italico.

Il non terminale Policies definisce le politiche, delimitate da parentesi ango-late 〈·〉, e gli insiemi di politiche, identificati invece dalle parentesi graffe {·}.La definizione riprende gli elementi fondamentali della sintassi XACML. Un in-sieme di politiche è definito da target, algoritmo di combinazione, lista dellepolitiche o degli insiemi di politiche contenuti, e obbligazioni. Le politiche so-no definite in modo analogo, con la differenza che si ha una lista di regole. Siale politiche che gli insiemi di politiche per essere correttamente definiti devonocontenere almeno una regola o una politica interna.

La definizione delle regole è formata da effetto, cioè permit o deny, target,condizione e obbligazioni. Per la definizione delle condizioni si utilizza un lin-guaggio delle espressioni ristretto, definito dalla grammatica in Appendice Anelle Tabelle A.2 e A.3. Si è scelto di utilizzare una grammatica specifica così dariprendere i nomi e gli argomenti delle principali funzioni definite in XACML.

Gli attributi delle richieste sono definiti come coppie nome-valore. I valorisono i letterali dei tipi di dato disponibili, mentre per la definizione dei nomi siutilizzano dei nomi strutturati, che rappresentano tutte le informazioni presentinell’elemento XML <Attribute>. Un nome strutturato è formato da una stringache indica la categoria dell’attributo, a cui segue, separata dal carattere ’/’, lastringa del nome dell’attributo.

4.1 sintassi 49

PAF ::= {PEP ; PDP} (Policy Authorization

Framework)

PEP ::= base | deny-biased (PEP alg.)

| permit-biased

PDP ::= {Palg ; Policies} (Retrieved policies)

Palg ::= only-one-applicable | Ralg (Policy-combining alg.)

Ralg ::= deny-overrides | permit-overrides (Rule-combining alg.)

| first-applicable

| ordered-deny-overrides

| ordered-permit-overrides

| deny-unless-permit

| permit-unless-deny | . . .

Policies ::= (Policies)

{Palg ; target : Targets? ;

policies :Policies+ ; obl :Obligations∗}(policy set)

| 〈Ralg ; target : Targets? ;

rules :Rules+ ; obl :Obligations∗〉(policy)

Targets ::= MatchId(value,name) (Targets)

| Targets ∨ Targets

| Targets ∧ Targets

MatchId ::= string-equal | integer-equal (Match functions)

| string-regexp-match

| integer-greater-than | . . .

Rules ::= (Effect ; target : Targets? ; (Rules)

condition : Expression ;

obl : Obligations∗ )

Effect ::= permit | deny (Effects)

Obligations ::= (Effect ; Type ; PepAction( Expression∗)) (Obligations And Advice)

Type ::= M | O (Mandatory or Optional)

Tabella 4.1: Sintassi delle politiche di FACPL

Le caratteristiche dei nomi strutturati permettono di utilizzarli anche per tra-durre in FACPL le operazioni di recupero dei valori degli attributi, sia quando so-no utilizzate espressioni XPath che l’identificatore dell’attributo. Nel dettaglio,quando è utilizzato l’identificatore si pone prima del delimitatore la categoria ea seguire l’identificatore, mentre nel caso di espressioni XPath, dopo la catego-ria dell’attributo, una sequenza di nomi, separati da punti, che corrispondonoagli elementi dell’espressione di ricerca. Se prendiamo ad esempio l’elementoAttributeDesignator del target definito nel Listato 3.1 riportato di seguito

<AttributeDesignator MustBePresent="false"

Category="urn:oasis:names:tc:xacml:3.0:attribute-category:subject"

AttributeId="urn:oasis:names:tc:xacml:3.0:subject:role"

DataType="http://www.w3.org/2001/XMLSchema#string" />

il nome strutturato corrispondente è subject/role. In modo analogo anche perl’espressione XPath definita nel seguente elemento

<AttributeSelector MustBePresent="false"

Category="urn:oasis:names:tc:xacml:3.0:attribute-category:resource"

Path="md:record/md:patient/md:patientDocID/text()"

DataType="http://www.w3.org/2001/XMLSchema#string" />

che corrisponde invece a resource/record.patient.parientDocID.In caso di attributi multi valore si definisce una sequenza di coppie

nome-valore con nomi tutti uguali. Per riferirsi al valore di un attributo sene indica il nome, completo di tutte le sue parti.

La definizione dei target non segue la struttura <AnyOf> - <AllOf> - <Match>presente in XACML, ma si basa su un’espressione booleana formata dalla con-giunzione o disgiunzione di funzioni di confronto sugli attributi. Le funzionidi match, definite dalla categoria sintattica MatchId, corrispondono all’elemen-to <Match> di XACML. Queste funzioni sono definite come triple: identificatoredella funzione, valore letterale e il nome strutturato di un attributo. L’elencocompleto degli identificatori disponibili per le funzioni di confronto è riportatoin Tabella A.1.

Gli ultimi elementi definiti nella sintassi sono le obligation e gli advice, cheavendo uguale struttura si identificano con la sola categoria sintattica Obliga-tions. Per distinguere tra gli elementi obligations e advice si usa l’attributo Type:M (Mandatory), che identifica le obligation, e O (Optional), che invece identificagli advice. Nelle Obligations, oltre al tipo, è definito l’identificatore dell’azioneda eseguire, con i relativi argomenti, e l’effetto Effect, cioè permit o deny, checorrisponde a FulfillOn o AppliesTo a seconda del tipo. Per indicare le azionieseguibili dalle Obligations si utilizza il termine PepAction che è l’insieme diazioni disponibili nel PEP che, come già detto, sono concordate tra chi scrive lepolitiche e chi implementa il PEP.

Per completare il framework di gestione del PDP e del PEP si ha la necessitàdi formalizzare la sintassi delle richieste e delle risposte, così da dettagliare

4.2 traduzione delle politiche del caso di studio 51

Context ::= request :{Attributes+}; (Contexts)

responsePDP{ResultsPDP+};response{ResultPEP+}

Attributes ::= (name,value) (Request attributes)

ResultPDP ::= ( id :value? ; Decision ; (Response results PDP)

status :value?; OblAndAdv∗)

ResultPEP ::= ( id :value? ; Decision ; (Response results PEP)

status :value?)

OblAndAdv ::= (Type ; PepAction( value∗)) (Obligation And Advice)

Decision ::= permit | deny (Decisions)

| not-applicable | indeterminate

Type ::= M | O (Mandatory or Optional)

Tabella 4.2: Sintassi delle richieste e delle risposte di FACPL

il risultato prodotto dal PDP e quello prodotto dal PEP. Questi elementi sonoriportati in Tabella 4.2.

Una richiesta è formata dagli attributi che descrivono l’azione che un sogget-to vuole eseguire su una risorsa. Così come descritto nel Captiolo 2, durante lavalutazione il PDP può richiedere attributi del contesto non presenti originaria-mente nella richiesta. Per semplicità, la gestione diretta del contesto in FACPL

non è definita. Si assume invece che tutti gli attributi necessari per la valutazio-ne della richiesta, quindi anche quelli appartenenti al contesto, siano presentinella richiesta stessa; questo tipo di richieste, per distinguerle dalle normalirichieste XACML, sono chiamate context-request.

La valutazione della context-request da parte del PDP genera un risultatoResultPDP che è composto dalla decisione presa e delle eventuali obbligazio-ni da eseguire nel PEP. Il PEP a sua volta restituisce ResultPEP, contenente sol-tanto la decisione finale da applicare. La categoria OblAndAdv, utilizzata inResultPDP, è uguale alla categoria Obligations presentata nella grammatica pre-cedente, con la sola differenza che gli argomenti dell’azione PepAction sonovalori, in quanto già recuperati dal PDP.

4.2 traduzione delle politiche del caso di studio

FACPL permette di scrivere le politiche in modo più conciso rispetto a XACML;prendiamo come esempio le politiche di epSOS introdotte nella Sezione 3.1.6.

La politica per la gestione della risorsa Patient Summary, seguendo la sintassidi XACML, si sviluppa su varie pagine, invece utilizzando FACPL si restringe allepoche righe riportate nel Listato 4.1. Il target, ad esempio, è definito soltantocon le funzioni di match, collegate tra loro da operatori logici, senza seguire lapesante struttura degli elementi XML.

In generale, il codice FACPL definisce in modo essenziale le politiche, senzaperò perdere di espressività rispetto alla sintassi XACML.

Listato 4.1: Politica FACPL per Patient Summary< permit−o v e r r i d e s ; t a r g e t :

s t r i n g −equa l ( "TREATEMENT" , s u b j e c t / pu r po s eo f u s e ) and s t r i n g −equa l ( "med i ca l doc to r " , s u b j e c t / r o l e ) and

s t r i n g −equa l ( "34133−9" , r e s o u r c e / r e s ou r c e−i d ); r u l e s :

( pe rm i t ; t a r g e t :s t r i n g −equa l ( "Read" , a c t i o n / ac t i on−i d ) ;

c o n d i t i o n :s t r i n g −s ub s e t ( s t r i n g −bag ( "PRD−003" , "PRD−005" , "PRD−010" , "PRD−016" ) ,

s u b j e c t / h l 7 . p e rm i s s i o n ) ;o b l : ; )

( deny ; t a r g e t : ; c o n d i t i o n : ; o b l : ; ) ;o b l :

( pe rm i t ; M; l o g ( s u b j e c t / doctor−id , r e s o u r c e / r e s ou r c e−i d ) )( deny ; M; ma i l ( r e s o u r c e / r e s ou r c e−i d . emai l , "Your med i ca l r e c o r d

has been r e qu e s t e d by EpSOS s u b j e c t " ) ) ;>

La richiesta d’accesso presentata nel Listato 3.9 è definita in FACPL come unasemplice sequenza di attributi, come mostrato nel Listato 4.2. L’utilizzo deinomi strutturati permette di gestire facilmente la categoria e l’identificatoredi ogni attributo. In accordo a quanto detto in precedenza, la richiesta FACPL

è una context-request, cioè contiene tutti gli attributi per la valutazione dellepolitiche. Perciò, in questo caso sono inseriti gli attributi email nella risorsa e idnel soggetto per la valutazione delle obbligazioni, che non erano presenti nellarichiesta originale.

Listato 4.2: Richiesta FACPL per Patient SummaryReque s t : { EpsosRequest

( s u b j e c t / pu rpo seo fu s e , "TREATEMENT" )( s u b j e c t / r o l e , "med i ca l doc to r " )( s u b j e c t / doc to r . id , " jh1234 " )( s u b j e c t / h l 7 . p e rm i s s i on , "PRD−003" )( s u b j e c t / h l 7 . p e rm i s s i on , "PRD−005" )( s u b j e c t / h l 7 . p e rm i s s i on , "PRD−010" )( s u b j e c t / h l 7 . p e rm i s s i on , "PRD−016" )( r e s o u r c e / r e s ou r c e−id , "34133−9" )( r e s o u r c e / r e s ou r c e−i d . emai l , "ma i l@gma i l . com" )( a c t i o n / ac t i on−id , "Read" )

}

4.3 semantica formale 53

Quando abbiamo presentato il caso di studio in Sezione 2.3 abbiamo descrittoanche il caso d’uso per le ePrescription. Per non introdurre troppo codice, nellaSezione 3.1.6 non è stata riportata la politica XACML. Utilizzando la sintassi diFACPL andiamo adesso a introdurla con il Listato 4.3.

Listato 4.3: Politica FACPL per ePrescription< permit−o v e r r i d e s ;

t a r g e t :s t r i n g −equa l ( "TREATEMENT" , s u b j e c t / pu rpo s e o f u s e ) and (

s t r i n g −equa l ( "med i ca l doc to r " , s u b j e c t / r o l e ) o r s t r i n g −equa l ( "pha rmach i s t " , s u b j e c t / r o l e )

) and s t r i n g −equa l ( "57829−4" , r e s o u r c e / r e s ou r c e−i d ) ;r u l e s :

( pe rm i t ; t a r g e t : s t r i n g −equa l ( "Read" , a c t i o n / ac t i on−i d ) ;c o n d i t i o n : s t r i n g −s ub s e t ( s t r i n g −bag ( "PRD−004" , "PRD−010" ) , s u b j e c t / h l 7 .

p e rm i s s i o n ) ;o b l : ; )( deny ; t a r g e t : ; c o n d i t i o n : ; o b l : ; ) ;

o b l : ( pe rm i t ; M ; l o g ( s u b j e c t / doctor−id , r e s o u r c e / r e s ou r c e−i d ) )( deny ; M; ma i l ( r e s o u r c e / r e s ou r c e−i d . emai l , "Your med i ca l r e c o r d has

been r e qu e s t e d by EpSOS s u b j e c t " ) ) ;>

La politica per le ePrescription è simile a quella precedente, si ha soltan-to una variazione dell’identificatore della risorsa, dei permessi necessari e deltarget, dove è considerato anche il ruolo del farmacista. Una richiesta valuta-ta positivamente per la politica presentata può essere ottenuta facilmente daquella presentata nel Listato 4.2, modificando l’identificatore della risorsa e ipermessi.

4.3 semantica formale

La sintassi presentata permette la definizione di una semantica formale delprocesso di valutazione. Le regole semantiche sono definite per i due livelli divalutazione rispetto a un insieme di context-request R, da cui si ottiene comerisultato finale una decision tuple (DT), che associa a ogni context-request la de-cisione corrispondente. La semantica definita per gli elementi valutati dal PDP

segue i requisiti funzionali di XACML, mentre la formalizzazione degli algoritmidel PEP è integrata nei casi non definiti (vedi Sezione 3.2.5 per i dettagli).

Per facilitare l’esposizione delle regole si assume che tutte le richieste sianodelle context-request, sebbene per agevolare la lettura si utilizzerà soltanto iltermine richiesta.

La semantica definisce una funzione di valutazione [[·]]R sul PAF la quale,dato un insieme R di richieste, restituisce una decision tuple. La tupla di insiemigenerata suddivide le richieste a seconda dell’effetto della valutazione associato,

definendo una partizione dell’insieme R iniziale. La formalizzazione della tuplaè nella seguente forma

DT = < permit : {< ri, Obi >}i∈Ip , deny : {< rj, Obj >}j∈Id ,

indeterminate : Ri, not-applicable : Rn >

Gli insiemi permit e deny sono formati da coppie della forma < r , Ob > dover è a una richiesta e Ob un insieme eventualmente vuoto formato dalle obbli-gazioni restituite con r. L’insieme Ob corrisponde agli elementi <Obligation> e<AssociatedAdvice> presenti nell’elemento XML result di XACML; in riferimen-to a FACPL si tratta invece della categoria sintattica OblAndAdv di Tabella 4.2.Per l’insieme permit le coppie sono scelte tra quelle la cui richiesta è valutatapermit, cioè i ∈ Ip, mentre per l’insieme deny tra quelle la cui richiesta è valutatadeny. Infine, gli elementi di indeterminate o not-applicable non contengono alcuninsieme di obbligazioni e sono quindi formati da soli insiemi di richieste r.

Assumendo che non si abbiano operazioni di traduzione sintattica o similinel PEP, la semantica del linguaggio consiste nell’eseguire la valutazione del-l’insieme di richieste R nel PDP e, ottenuta la tupla DT in risposta, nel valu-tare l’applicazione delle decisioni nel PEP. Formalizzando con una regola diinferenza si ottiene

[[PDP]]R = DT [[PEP]]DT = D[[{PEP; PDP}]]R = D

dove D è una tupla di insiemi con le decisioni da applicare per ogni richiesta,cioè della forma

D =< permit : Rp, deny : Rd, indeterminate : Ri, not-applicable : Rn >

Si definisce adesso la semantica del PDP, descrivendo prima le funzioni divalutazione associate ai singoli elementi sintattici, nel dettaglio target, obbliga-zioni, regole, politiche e insiemi di politiche, e poi gli algoritmi disponibili peril PEP. Le regole semantiche sono definite seguendo uno stile denotazionale.

4.3.1 Target

I target sono definiti come espressioni booleane di funzioni MatchId, mentre glioperatori logici or (∨) e and (∧) si devono definire sui tre valori di decisionedei target: match, no-match e indeterminate. Le tavole di verità dei due operatorisono riportate in Tabella 4.3.

Gli operatori si comportano con i valori match e no-match come sui classicivalori vero e falso, mentre per indeterminate l’operatore ∨ applica la priorità amatch, mentre ∧ a no-match.

∨ match no-match indeterminate

match match match match

no-match match no-match indeterminate

indeterminate match indeterminate indeterminate

∧ match no-match indeterminate

match match no-match indeterminate

no-match no-match no-match no-match

indeterminate indeterminate no-match indeterminate

Tabella 4.3: Operatori logici dei Target

La definizione delle tavole di verità precedenti permette di confrontare lasintassi dei target di FACPL con quella di XACML. Date le regole semantiche defi-nite dallo standard, presentate nella Sezione 3.2.1, si può presentare la strutturadell’elemento target <AnyOf> - <AllOf> - <Match> come segue

<AnyOf>∧ <AnyOf>∧ . . . ∧ <AnyOf>

dove ogni <AnyOf> è della forma

<AllOf>∨ <AllOf>∨ . . . ∨ <AllOf>

ed infine ogni <AllOf> è della forma

<Match>∧ <Match>∧ . . . ∧ <Match>

Possiamo quindi concludere che ogni target espresso in XACML è rappresenta-bile con la nostra sintassi alternativa, e ogni target descritto con i connettorilogici sopra presentati si può riscrivere nella struttura XACML. Per quest’ultimocaso si deve notare che può essere necessario applicare la proprietà distributivadi ∧ rispetto a ∨ e viceversa, per ottenere una formula distribuita sui tre livellirichiesti.

Per la valutazione dei target si definisce la funzione [[·]]R che dato un target eun insieme di richieste R restituisce una tupla della forma

(match : Rm; no-match : Rn; indeterminate : Ri)

dove Rm, Rn, Ri sono insiemi di richieste suddivisi in base al risultato dellavalutazione del target. L’obiettivo della funzione [[·]]R è quello di creare unapartizione di R nella tupla precedente.

La definizione della semantica dei target si basa su tre regole: una per lavalutazione delle funzioni MatchId e le restanti due per la composizione difunzioni mediante gli operatori; di seguito presentiamo la regola per MatchId.


[[MatchId(value,name)]]R =

(match : {r ∈ R | ∃ (name,value′) ∈ r :

MatchId(value,value′) = true}

no-match : {r ∈ R | ∀ (name,value′) ∈ r :

MatchId(value,value′) = false}indeterminate : {r ∈ R | ∃ (name,value′) ∈ r :

MatchId(value,value′) = indeterminate

∧ 6∃ (name,value′) ∈ r :

MatchId(value,value′) = true} )

La regola per le funzioni di confronto MatchId, in accordo a XACML, afferma cheuna richiesta è nell’insieme:

- match, se esiste un attributo della richiesta che ha un valore per il qualela funzione restituisce un risultato positivo;

- indeterminate, se esiste un attributo della richiesta per il quale si ottieneun errore di valutazione;

- no-match, se tutti gli attributi generano risultati negativi della funzioneoppure non è stato recuperato nessun valore.

Il verificarsi della prima condizione preclude la possibilità di avere indetermi-

nate, anche quando il predicato di indeterminate è verificato. Inoltre, si assumeche l’attributo MustBePresent, introdotto nella Sezione 3.2.1, abbia valore false eche l’insieme vuoto sia trattato nel caso no-match. La soluzione alternativa nonavrebbe comunque comportato variazioni significative.

Per formulare le regole degli operatori ∨ e ∧, si utilizza l’operatore di pro-iezione ↓d sulle tuple risultato di [[·]]R. Tale operatore restituisce l’insieme dirichieste associate alla decisione d: match, no-match e indeterminate. Le regoleper i due operatori logici sono le seguenti.

[[Targets1 ∨ Targets2]]R =

(match : [[Targets1]]R ↓match ∪ [[Targets2]]R ↓match;

no-match : [[Targets1]]R ↓no-match ∩ [[Targets2]]R ↓no-match;

indeterminate : ([[Targets1]]R ↓indeterminate \ [[Targets2]]R ↓match)

∪ ([[Targets2]]R ↓indeterminate \ [[Targets1]]R ↓match) )


[[Targets1 ∧ Targets2]]R =

(match : [[Targets1]]R ↓match ∩ [[Targets2]]R ↓match;

no-match : [[Targets1]]R ↓no-match ∪ [[Targets2]]R ↓no-match;

indeterminate : ([[Targets1]]R ↓indeterminate \ [[Targets2]]R ↓no-match)

∪ ([[Targets2]]R ↓indeterminate \ [[Targets1]]R ↓no-match) )

Come si può vedere dalla definizione delle regole esse ripropongono sottoforma di semantica le tavole di verità presentate a inizio sezione.

4.3.2 Obbligazioni

Nel PDP la valutazione delle obbligazioni è un passaggio di particolare rilevan-za. Dato che il livello di valutazione delle obbligazioni che stiamo considerandoè quello del PDP, il compito da eseguire è quindi quello di recuperare i valoridegli argomenti dell’azione da restituire.

A questo scopo è definita la funzione (|Obligationseffect|)r, che partiziona leobbligazioni in quelle valutate correttamente e quelle in cui si sono verificatidegli errori. Il risultato si può presentare come la seguente tupla

(success : Obs ; unsuccess : Obu)

La funzione (| · |)r è definita per un insieme di obbligazioni, senza far differen-za se sono definite in regole, politiche o insiemi di politiche, e rispetto a unarichiesta r; il termine effect sarà sostituito da permit o deny a seconda di qualiobbligazioni ci necessitano. La funzione è così definita:

(|Obligationseffect|)r =

( success : {o ∈ Obligationseffect | o · r = true}unsuccess : {o ∈ Obligationseffect | Type(o) = M

∧ o · r = false})

La notazione o · r significa che si applica la richiesta r all’obbligazione o,cioè si recuperano i valori degli attributi indicati: in caso di errore si ottienefalse, altrimenti in caso di successo true. La funzione non è definita sull’interoinsieme delle obbligazioni, ma solo su quelle definite per un effetto, utilizzatocon la notazione a pedice per fare la proiezione sull’insieme.

Nell’insieme delle obbligazioni si hanno sia advice che obligation. Quandosi verifica un errore nel recupero degli attributi, se si ha una obligation, cioèType(o) = M, si aggiunge all’insieme unsuccess, altrimenti nel caso di advice siignora. Se si assume che la richiesta sia una context-request, definita in Sezio-ne 4.1, le cause di insuccesso nella valutazione delle obbligazioni sono dovutea errori prettamente sintattici nelle espressioni dei parametri dell’azione.

[[ (permit ; target :{ Targets }; condition :{expression} ; obl :{Obligations}) ]]R =

( permit : {< r, Ob > |r ∈ {r′ ∈ [[Targets]]R ↓match | expression · r′ = true

∧(|Obligationspermit|)r′ ↓unsuccess= ∅}∧Ob = (|Obligationspermit|)r ↓success}

deny : ∅ ;

not-applicable : {r ∈ [[Targets]]R ↓match | expression · r = false}∪ [[Targets]]R ↓no-match

indeterminate : {r ∈ [[Targets]]R ↓match | expression · r = indeterminate}∪ {r ∈ [[Targets]]R ↓match | expression · r = true ∧

(|Obligationspermit|)r ↓unsucess 6= ∅}∪ [[Targets]]R ↓indeterminate )

Tabella 4.4: Semantica Rule per effetto permit

Come per la gestione dei target, nel seguito si utilizza l’operatore di proie-zione ↓v, con v definito come success e unsuccess, per ottenere il corrispettivoinsieme di obbligazioni restituito dalla funzione di valutazione.

4.3.3 Regole, Politiche e Insiemi di Politiche

Definite le regole semantiche per il target e per le obbligazioni, è possibile for-malizzare quelle degli elementi primari della sintassi. Si definisce una funzione[[·]]R che restituisce come risultato la DT descritta in precedenza.

Rule

La semantica associata alle rule è formata da due regole distinte, quella per lerule definite con effetto permit e quelle definite per deny. Si utilizza questa solu-zione per poter conoscere a priori l’eventuale effetto restituito e semplificare ladefinizione della regola. La regola per il caso permit è riportata in Tabella 4.4.

La valutazione dell’insieme deny, per il caso permit, è vuoto in quanto la ru-le è esplicitamente definita per l’effetto permit. Nell’insieme permit si hanno lecoppie < r, Ob >, cioè tutte le richieste valutate correttamente e le rispettiveobbligazioni collegate. Le richieste r presenti sono tutte quelle per cui la ruleè risultata applicabile secondo la funzione di valutazione del target, e la valu-tazione della condizione rispetto alla richiesta, expression · r′, ha avuto risultato

[[ (deny ; target :{ Targets }; condition :{expression} ; obl :{Obligations}) ]]R =

( permit : ∅ ;

deny : {< r, Ob > |r ∈ {r′ ∈ [[Targets]]R ↓match | expression · r′ = true

∧(|Obligationsdeny|)r′ ↓unsuccess= ∅}∧Ob = (|Obligationsdeny|)r ↓success}

not-applicable : {r ∈ [[Targets]]R ↓match | expression · r = false}∪ [[Targets]]R ↓no-match

indeterminate : {r ∈ [[Targets]]R ↓match | expression · r = indeterminate}∪ {r ∈ [[Targets]]R ↓match | expression · r = true ∧

(|Obligationsdeny|)r ↓unsucess 6= ∅}∪ [[Targets]]R ↓indeterminate )

Tabella 4.5: Semantica Rule per effetto deny

true. Gli elementi dell’insieme Ob della coppia, sono le obbligazioni, definiteper l’effetto permit, valutate con successo per la richiesta r. Il predicato

(|Obligationspermit|)r′ ↓unsuccess= ∅

presente nella condizione di r, assicura che tutte le eventuali obbligazioni sia-no state valutate correttamente; altrimenti in caso di errori la richiesta non èinserita in permit, ma nell’insieme indeterminate.

Il caso not-applicable è di facile lettura in quanto riprende le due condizioniindicate in Sezione 3.2.2: rule applicabile ma condizione falsa o rule non appli-cabile. Infine, l’insieme indeterminate è composto dalle richieste r per le quali siè avuta una valutazione indeterminate della condizione o del target e quelle percui la valutazione delle obbligazioni non è andata a buon fine.

La regola semantica per il caso deny è definita in modo speculare a quellasopra descritta ed è mostrata in Tabella 4.5. Le valutazioni fatte per il casopermit sono valide anche per questo caso.

Analizzando la struttura delle regole è possibile vedere che si crea effetti-vamente nella DT una partizione delle richieste. I predicati sui target e sullecondizioni sono complementari tra i vari casi e, se una richiesta è indeterminate

a causa di una obbligazione, la richiesta deve essere stata in match con il target,fatto che esclude che la richiesta possa essere anche nell’insieme not-applicable.

Policy e Policy Set

Le regole per policy e policy set utilizzano sempre il concetto di coppia < r, Ob >,ma, a differenza del caso delle rule, si deve gestire anche la DT ricevuta dallavalutazione dei livelli inferiori. Nella gestione delle obbligazioni si deve control-lare, sia per quelle ricevute che per quelle correnti, per quale effetto sono defi-nite e se questo è uguale alla decisione presa all’attuale livello di valutazione,altrimenti le obbligazioni devono essere scartate.

Per definire le regole delle politiche e degli insiemi di politiche si deve forma-lizzare l’invocazione dell’algoritmo di combinazione sugli elementi interni. Glialgoritmi per le politiche si identificano con Palg, mentre per le regole con Ralg,come definito in Tabella 4.1. La chiamata dell’algoritmo su regole o politicherispetto a un insieme di richieste è indicata così come mostrato di seguito

Ralg(Rules)Rm Palg(Policies)r

A seconda dei casi, l’invocazione dell’algoritmo può essere effettuato su tuttele richieste (R), su una partizione delle stesse rispetto al target (Rm, Rn, Ri - vediSezione 4.3.1) o soltanto su una singola richiesta (r).

La chiamata degli algoritmi di combinazione restituisce una DT che,considerando un generico insieme di richieste R, si può così rappresentare

Palg(Policies)R =

( permit : {< r, Ob > | r ∈ R ∧ Palg(Policies, r) = permit

Ob = Palg(|Obligationspermit|)r}deny : {< r, Ob > | r ∈ R ∧ Palg(Policies, r) = deny

Ob = Palg(|Obligationsdeny|)r}not-applicable : {r | Palg(Policies, r) = not-applicable}indeterminate : {r | Palg(Policies, r) = indeterminate} )

dove Palg(Policies, r) rappresenta l’esecuzione dell’algoritmo su una richiestar. Per i casi permit e deny, l’insieme di obbligazioni delle politiche è rappresen-tato da Palg(|Obligationseffect|)r. Si utilizza quest’ultima funzione, che dipendeanche dall’algoritmo di combinazione, per sottolineare il fatto che l’insiemedi obbligazioni restituito da una politica non è deterministico, ma dipendedall’esecuzione dell’algoritmo.

Sull’applicazione degli algoritmi si definisce anche l’operatore di proiezione↓v, dove v può essere una tra i quattro effetti presenti in DT. Per comodità dinotazione si utilizzerà la seguente forma

r ∈ Ralg(Rules) ↓permit

anche se si ottengono delle coppie < r, Ob > dall’insieme permit. Questo perevitare notazioni più complesse del tipo

r |< r, Ob >∈ Ralg(Rules) ↓permit

[[ 〈Ralg ; target : Targets ; rules :Rules ; obl :Obligations〉 ]]R =

( permit : {< r, Ob > |r ∈ {r′ ∈ [[Targets]]R ↓match| r′ ∈ Ralg(Rules)Rm ↓permit

∧(|Obligationspermit|)r′ ↓unsuccess= ∅}∧Ob = Ralg(Rules)r ↓permit,obl

∪ (|Obligationspermit|)r ↓success}deny : {< r, Ob > |

r ∈ {r′ ∈ [[Targets]]R ↓match| r′ ∈ Ralg(Rules)Rm ↓deny

∧(|Obligationsdeny|)r′ ↓unsuccess= ∅}∧Ob = Ralg(Rules)r ↓deny,obl

∪ (|Obligationsdeny|)r ↓success}not-applicable : [[Targets]]R ↓no-match

∪Ralg(Rules)Rm ↓not-applicable

∪Ralg(Rules)Ri ↓not-applicable

indeterminate : Ralg(Rules)Rm ↓indeterminate

∪Ralg(Rules)Ri ↓permit

∪Ralg(Rules)Ri ↓deny

∪Ralg(Rules)Ri ↓indeterminate

∪ {r ∈ [[Targets]]R ↓match| r ∈ Ralg(Rules)r ↓permit

∧(|Obligationspermit|)r ↓unsuccess 6= ∅}∪ {r ∈ [[Targets]]R ↓match| r ∈ Ralg(Rules)r ↓deny

∧(|Obligationsdeny|)r ↓unsuccess 6= ∅})

Tabella 4.6: Semantica delle Policy

La stessa considerazione è valida anche per l’insieme deny. Per recuperare in-vece l’insieme di obbligazioni Ob di una richiesta r dalla coppia < r , Ob >presente nella partizione permit si utilizza l’operatore di proiezione ↓permit,obl ;↓deny,obl ha analogo significato.

Definite le funzioni e gli operatori precedenti possiamo passare alle regole dipolicy e policy set, gli elementi principali su cui si basa la valutazione del PDP.La regola semantica per le politiche è riportata in Tabella 4.6.

La regola per le politiche è definita rispetto alle quattro decisioni presen-ti nella tupla DT. Le condizioni per l’insieme permit e deny sono uguali nellastruttura, con la sola differenza che cambia l’effetto della proiezione sul risulta-to dell’algoritmo Ralg(Rules)Rm , e l’effetto per cui sono definite le obbligazionidell’insieme Ob. In dettaglio, le richieste r di questi due insiemi sono tutte


le richieste applicabili, quindi appartenenti alla proiezione per il valore match

sulla funzione di valutazione del target, e che hanno generato una decisionepermit o deny, a seconda dell’insieme considerato, nella combinazione delle re-gole. Gli elementi dell’insieme Ob sono riferiti alla richiesta r, e quindi devonoappartenere alle obbligazioni restituite dall’algoritmo di combinazione, a talscopo si utilizzano gli operatori di proiezione ↓permit,obl e ↓deny,obl . Le obbliga-zioni, inoltre, possono anche essere quelle definite nella politica corrente, chesono state valutate correttamente. Come nel caso delle rule, per evitare incon-sistenze di richieste presenti allo stesso momento in permit e indeterminate, siaggiunge il predicato per il controllo dell’insieme unsuccess della valutazionedelle obbligazioni della politica.

Il caso not-applicable è definito secondo i tre casi riportati nella semantica dellaSezione 3.2.3. I casi più immediati sono quando si ha una richiesta non appli-cabile oppure l’algoritmo di combinazione calcola una decisione not-applicable.L’insieme

Ralg(Rules)Ri ↓not-applicable

modella invece la nuova gestione, introdotta in XACML3.0, delle richieste per cuiil target è valutato indeterminate. Si ha che per le richieste dell’insieme Ri si ap-plica l’algoritmo di combinazione e se questo valuta richieste not-applicable, al-lora appartengono a questo insieme. Questa condizione è stata inserita per alli-nearsi all’ultima versione di XACML, anche se, come illustrato nella Sezione 3.2.3,dubitiamo dell’efficacia di questo approccio e delle performance ottenibili.

L’ultimo caso rimasto è indeterminate, che comprende tutte le richieste che ge-nerano indeterminate come decisione dell’applicazione dell’algoritmo di combi-nazione. Questo può avvenire per valutazioni indeterminate di richieste in match,descritto come segue

Ralg(Rules)Rm ↓indeterminate

oppure per richieste il cui target è indeterminate (Ri), ma valutate dall’algorit-mo di combinazione diversamente da not-applicable. Oltre ai precedenti casi,una richiesta può essere valutata indeterminate anche quando la funzione divalutazione delle obbligazioni inserisce elementi nell’insieme unsuccess.

La regola per i policy set è definita in Tabella 4.7 ed è simile a quella per lepolitiche, con la sola differenza che si applicano algoritmi di combinazione supolitiche o insiemi di politiche.

4.3.4 Policy Enforcement Point

Il compito del PEP è quello di applicare la decisione presa dal PDP, condizionataall’eventuale esecuzione delle obbligazioni. Le regole semantiche che si posso-no definire per il PEP sono riferite ai possibili algoritmi che può eseguire. Adifferenza del PDP la decisione del PEP non è presa sulla base delle richieste R

[[ {Palg ; target : Targets ; policies :Policies ; obl :Obligations} ]]R =

( permit : {< r, Ob > |r ∈ {r′ ∈ [[Targets]]R ↓match| r′ ∈ Palg(Policies)Rm ↓permit

∧(|Obligationspermit|)r′ ↓unsuccess= ∅}∧Ob = Palg(Policies)r ↓permit,obl

∪ (|Obligationspermit|)r ↓success}deny : {< r, Ob > |

r ∈ {r′ ∈ [[Targets]]R ↓match| r′ ∈ Palg(Policies)Rm ↓deny

∧(|Obligationsdeny|)r′ ↓unsuccess= ∅}∧Ob = Palg(Policies)r ↓deny,obl

∪ (|Obligationsdeny|)r ↓success}not-applicable : [[Targets]]R ↓no-match

∪Palg(Policies)Rm ↓not-applicable

∪Palg(Policies)Ri ↓not-applicable

indeterminate : Palg(Policies)Rm ↓indeterminate

∪Palg(Policies)Ri ↓permit

∪Palg(Policies)Ri ↓deny

∪Palg(Policies)Ri ↓indeterminate

∪ {r ∈ [[Targets]]R ↓match| r ∈ Palg(Policies)r ↓permit

∧(|Obligationspermit|)r ↓unsuccess 6= ∅}∪ {r ∈ [[Targets]]R ↓match| r ∈ Palg(Policies)r ↓deny

∧(|Obligationsdeny|)r ↓unsuccess 6= ∅})

Tabella 4.7: Semantica dei Policy Set

ricevute, ma sulla DT ricevuta dal PDP. Per le richieste del caso indeterminate onot-applicable il PEP non esegue operazioni significative, mentre se le richiestein permit e deny hanno associato un insieme Ob non vuoto, allora tutte le azioniivi contenute devono essere eseguite.

Lo standard non definisce completamente tutti i comportamenti possibilidel PEP negli algoritmi proposti; per formalizzare la funzione semantica [[·]]DT

definiamo i casi mancanti come segue:

- Nel caso di decisione permit del PDP e valutazione unsuccess delle obliga-tion (non degli advice che possono essere ignorati in caso di fallimento) ladecisione finale del PEP è indeterminate.

- Nel caso di decisione deny del PDP e valutazione unsuccess delle obligation(non degli advice) la decisione finale del PEP è indeterminate.

Nel caso di unsuccess di un’obbligazione si è preferito indeterminate a not-applicable visto che quest’ultimo rappresenta una situazione in cui non sonodisponibili regole, politiche o insiemi di politiche applicabili alla richiesta, equindi non raffigura correttamente la situazione in questione.

La semantica del PEP è definita specificando le regole da seguire per applica-re i tre algoritmi riportati in Tabella 4.1. Gli algoritmi ricevono la DT risultatodel PDP, eseguono le azioni delle obbligazioni presenti e, valutando le esecuzio-ni, applicano la decisione finale. Le obbligazioni ricevute contengono il tipo el’azione con i relativi argomenti; ogni obbligazione è cioè della forma

(Type , PepAction( value∗)) Type ::= M|O

così come riportato in Tabella 4.2. Sulla base di questa struttura si definisce lafunzione (| · |)PEP per valutare un insieme di obbligazioni Ob e partizionarle traquelle eseguite con successo e quelle che hanno generato errori. La definizionedella funzione è la seguente

(|Ob|)PEP =

(success : {o ∈ Ob | PepAction( value∗) = true},unsuccess : {o ∈ Ob | PepAction( value∗) = false})

Il valore true rappresenta una valutazione eseguita con successo, false altrimen-ti. Sulla tupla risultato della funzione si definisce l’operatore di proiezione ↓v

rispetto a success e unsuccess.Data la precedente funzione è possibile definire le regole semantiche per gli

algoritmi. La regola per l’algoritmo base è la seguente

[[ base ]]DT =

( permit : {r |< r, Ob >∈ DT ↓permit ∧ (|Ob|)PEP ↓unsuccess= ∅}deny : {r |< r, Ob >∈ DT ↓deny ∧ (|Ob|)PEP ↓unsuccess= ∅}not-applicable : {r | r ∈ DT ↓not-applicable}indeterminate : {r | r ∈ DT ↓indeterminate}

∪{r |< r, Ob >∈ DT ↓deny ∧ (|ObM|)PEP ↓unsuccess 6= ∅}∪{r |< r, Ob >∈ DT ↓permit ∧ (|ObM|)PEP ↓unsuccess 6= ∅}

)

La decisione applicata è permit o deny soltanto se la valutazione di tutte leobbligazioni ha successo, altrimenti in caso di errore si ottiene una decisione

indeterminate, se si tratta di obligation. Per le richieste presenti nell’insieme inde-

terminate e not-applicable non si deve eseguire nessuna valutazione, applicandodirettamente la decisione.

Gli altri algoritmi definiti per il PEP, cioè permit-biased e deny-biased, applicanosoltanto le decisioni permit o deny. Per il caso permit-biased si ha la seguenteregola

[[ permit− biased ]]DT =

( permit : {r |< r, Ob > ∈ DT ↓permit}∪{r |< r, Ob > ∈ DT ↓deny ∧ (|Ob|)PEP ↓unsuccess 6= ∅}∪{r | r ∈ DT ↓not-applicable} ∪ {r | r ∈ DT ↓indeterminate};

deny : {r |< r, Ob > ∈ DT ↓deny ∧ (|Ob|)PEP ↓unsuccess= ∅};not-applicable : ∅

indeterminate : ∅ )

La decisione finale è deny soltanto per le richieste valutate deny e la cui ese-cuzione delle obbligazioni è andata a buon fine, in tutti gli altri casi, ancheper richieste valutate come indeterminate o not-applicable, si applica la decisionepermit. La regola collegata al caso deny-biased è reciproca alla precedente ed èdefinita come segue

[[ deny− biased ]]DT =

( permit : {r |< r, Ob > ∈ DT ↓permit ∧ (|Ob|)PEP ↓unsuccess= ∅};deny : {r |< r, Ob > ∈ DT ↓deny}

∪{r |< r, Ob > ∈ DT ↓permit ∧ (|Ob|)PEP ↓unsuccess 6= ∅}∪{r | r ∈ DT ↓not-applicable} ∪ {r | r ∈ DT ↓indeterminate};

not-applicable : ∅

indeterminate : ∅ )

La definizione delle regole per il PEP può variare in base al contesto di ap-plicazione. Una possibile soluzione, per modificare il comportamento in casiparticolari, è quella di categorizzare le obligation, così da definire una funzionedi valutazione (|o|)PEP specializzata per le varie categorie, evitando di modifica-re le regole per gli algoritmi. Alcuni esempi di categorizzazione sono riportatinel paragrafo successivo.

Categorie di obbligazioni

La definizione di categorie per le obligation è un argomento che non è trattato al-l’interno dello standard XACML, dato che un’eccessiva specializzazione avrebbefatto venir meno la caratteristica della generalità tipica dell’approccio di XACML.


Creare delle classi di azioni per specializzare il comportamento del PEP è unadecisione lecita che si può fare in fase di ingegnerizzazione dello standard, permeglio attenersi ai requisiti dell’applicazione.

Una classificazione delle azioni potrebbe essere fatta in base all’intervallotemporale entro il quale devono essere eseguite:

- Atomiche: l’applicazione della decisione e l’obbligazione devono essereeseguite insieme o entro vincoli temporali molto stringenti, ad esempioun’operazione di scrittura sicura su un file di log;

- Sequenziali: in presenza di più coppie decisione-azione, si valutano lecoppie in modo sequenziale, applicando prima la decisione presa e poi siesegue l’obbligazione, ad esempio un log non fault-tolerant;

- Asincrone: se entro un certo intervallo di tempo l’esecuzione dell’obbliga-zione non genera errori allora la si considera andata a buon fine anche senon si è ricevuta alcuna conferma, ad esempio azioni per cancellare datitemporanei di una sessione;

- Data-processing: l’obbligazione deve eseguire delle operazioni sulle in-formazioni necessarie per applicare la decisione presa, ad esempio lachiamata di un servizio di criptografia per l’invio dei messaggi.

Sulla base di queste categorie si può modificare la definizione della funzionedi valutazione delle azioni.

Applicare queste considerazioni direttamente alla funzione (|o|)PEP non èuna soluzione facile, in quanto si necessita di strutture semantiche che possa-no gestire il tempo, ad esempio timeout per la valutazione dei tempi di ese-cuzione. Rappresenta comunque un’alternativa perseguibile rispetto alla solasuddivisione tra obligation e advice presente in XACML.

Definire una semantica per le categorie potrebbe essere un interessan-te sviluppo futuro, in collegamento a una specifica più dettagliata delcomportamento del PEP.

4.4 valutazione formale delle richieste del caso di studio

Le regole semantiche definite possono essere utilizzate per eseguire unavalutazione formale di un generico insieme di richieste.

Consideriamo ora uno specifico insieme R composto dalle seguenti richieste:

- r1 : una richiesta valutata permit per la politica di gestione delle cartellecliniche (riportata nel Listato B.1);

- r2 : una richiesta valutata permit per la politica di gestione delleprescrizioni (riportata nel Listato B.2);

4.4 valutazione formale delle richieste del caso di studio 67

- r3 : uguale alla richiesta r2 ma definita per l’operazione delete (riportatanel Listato B.3);

- r4 : uguale alla richiesta r1 senza l’attributo doctor.id necessario allavalutazione dell’ obbligazione (riportata nel Listato B.4).

Per la valutazione si assume che l’elemento PDP di Tabella 4.1 sia definitosulle due politiche di Sezione 4.2 e applichi l’algoritmo permit-overrides.

Si applica la funzione [[PDP]]R. Si calcola prima le DT associate alle due poli-tiche presenti nel PDP. Il risultato della valutazione della politica per il PatientSummary è il seguente

(permit : {< r1, {log(docID, resId)} >}

deny : ∅

not-applicable : r2, r3

indeterminate : r4)

Nell’insieme permit si ha la richiesta r1, segue dal fatto che era definita espres-samente per il caso del Patient Summary, con in allegato l’obbligazione perla registrazione sul log. Le richieste r2 e r3 sono valutate come not-applicable,in quanto dalla valutazione del target della politica risultano non applicabili.Infine, la richiesta r4 è valutata indeterminate perché l’obbligazione per effet-tuare l’operazione di log non può essere valutata dal PDP per l’assenza del-l’attributo doctor.id. La valutazione errata dell’obbligazione ha effetto sullapolitica in quanto l’elemento EvaluateOn è definito per permit, che corrispondealla decisione della politica.

Se invece applichiamo la politica per la risorsa ePrescription si ottiene

(permit : {< r2, {log(docID, resId)} >}

deny : {< r3, {mail(patientMail, text)} >}

not-applicable : r1, r4

indeterminate : ∅)

In questo caso, come da definizione dell’insieme R, le richieste r1 e r2 si scam-biano tra loro rispetto al caso precedente. Nell’insieme deny si ha invece larichiesta r3, dato che rispetta il target della politica, ma non è applicabile allaprima regola, mentre la seconda, che ha target vuoto ed è applicabile quindi atutte le richieste, associa il valore deny. Applicando l’algoritmo permit-overridessi ottiene il valore deny finale. La richiesta r4, invece, non si trova nell’insieme in-

determinate in quanto la richiesta non è applicabile alla politica e la valutazionedell’obbligazione che generava l’errore non è eseguita.

Vista la valutazione dell’insieme R per le singole politiche presenti nel PDP, sipuò calcolare, applicando l’algoritmo permit-overrides, la DT restituita dal PDP

come segue

(permit : {< r1, {log(docID, resId)} >< r2, {log(docID, resId)} >}

deny : {< r3, {mail(patientMail, text)} >}

not-applicable : ∅

indeterminate : r4)

Le richieste r1 e r2 sono entrambe nel caso permit dato che entrambe han-no ricevuto una valutazione permit da una politica, l’effetto che nell’algoritmopermit-overrides ha la priorità sugli altri. La richiesta r3 è logicamente inseritanell’insieme deny, visto che è stata valutata in entrambi casi con questo valore,mentre la richiesta r4 è inserita nell’insieme indeterminate, come risultato di unacombinazione con l’effetto not-applicable.

Con questo piccolo esempio si è potuto vedere l’utilità di una funzione divalutazione semantica, che permette di valutare precisamente i singoli passag-gi del processo autorizzativo, identificando anche i casi particolari come adesempio quello della gestione delle obbligazioni.

5A M B I E N T E D I VA L U TA Z I O N E E S T R U M E N T I D I S V I L U P P O

FACPL permette di sviluppare politiche più leggibili e semplici da scrivere ri-spetto a XACML. Un linguaggio per scrivere politiche di controllo degli accessiperò non può essere applicato a casi reali soltanto facendo uso della sintassi edelle regole semantiche, è necessario creare un’architettura di valutazione perle richieste e gli strumenti di supporto allo sviluppo, così da facilitare il compitodegli utenti.

FACPL è specializzato entro un ambito ben preciso, lo possiamo quindi defini-re un Domain Specific Language (DSL), cioè un insieme di costrutti per model-lare problemi di un ristretto dominio applicativo. Le tecnologie per svilupparelinguaggi sono molteplici, ma la caratteristica necessaria per chi utilizza un DSL

è un ambiente di lavoro con editor di testo, compilazione e navigazione tra icontenuti, cioè un Integrated Development Environment (IDE). Lo strumentoopen-source più utilizzato in quest’area è Eclipse [18], che è preferibile ad altrianche per l’integrazione con Xtext [29], un framework di sviluppo per DSL.

Utilizzando Xtext e il linguaggio Java è stato possibile creare un ambientedi sviluppo all’interno di Eclipse e una libreria per la valutazione delle richie-ste. Tutto il codice prodotto è disponibile sul sito riportato in [13]. Andiamoadesso a presentare l’architettura di valutazione e, dopo una descrizione deglistrumenti presenti nel framework Xtext, l’ambiente di sviluppo su Eclipse.

5.1 ambiente di valutazione

La valutazione delle richieste è realizzata mediante un insieme di classi Javache modellano le componenti del Policy Authorization Framework, il contesto e ilivelli di valutazione del PDP e del PEP.

Nella progettazione delle classi si è cercato di fattorizzare il più possibile ilcodice e le componenti comuni, sulla base della struttura degli elementi definitanel Capitolo 3. Nel dettaglio, si ha un gruppo di classi per la definizione diregole, politiche e insiemi di politiche, che a loro volta fanno riferimento alleclassi per la definizione di target, condizioni e obbligazioni, e un gruppo per ladefinizione del contesto, con le classi per la modellazione delle richieste e deirisultati dei livelli di valutazione.

69

70 ambiente di valutazione e strumenti di sviluppo

Per la valutazione dell’applicabilità, nei target e nelle condizioni, è statocreato un sotto-insieme consistente delle funzioni di confronto presenti inXACML.

Per ogni gruppo di componenti sono state definite delle interfacce per laspecifica dei metodi necessari alla valutazione delle richieste. Negli elementivalutabili dal PDP cioè regole, politiche e insiemi di politiche, vi è la definizio-ne del metodo evaluate, che data una richiesta restituisce il valore di decisione diquell’elemento. Gli elementi interni, cioè target, obbligazioni e condizioni, han-no anche loro un metodo specifico per la valutazione. Invece, per gli algoritmidi combinazione il metodo è definito rispetto a una lista di elementi valutabili,la richiesta e un parametro booleano, di cui parleremo nel prosieguo.

I livelli di valutazione del PDP e del PEP sono definiti mediante classi statiche.La valutazione di una richiesta può essere fatta richiamando opportuni metodidi tali classi. Per il PEP, inoltre, sono state definite una serie di azioni standardche può eseguire al momento dell’applicazione della decisione.

Le tecniche utilizzate per la progettazione della libreria la rendono estendi-bile con nuove funzioni, nuovi algoritmi o nuove azioni per il PEP. Andiamoadesso nel dettaglio delle singole componenti implementate.

Gli elementi valutabili sono raggruppati in un unica classe astratta chiamataPAFEvalElement. Visto che nel PDP, come elementi di aggregazione più esterni, sipossono avere soltanto politiche o insiemi di politiche, la classe PAFEvalElementè specializzata nella classe per le regole e nella classe PAFElement, che raccogliepolitiche e insiemi di politiche. Questa scelta è stata fatta per poter definire ilprocesso di valutazione delle richieste su liste di elementi di tipo PAFElement.

Per facilitare la scrittura delle politiche si è associato un identificatore a ognielemento, così da poter utilizzare anche i riferimenti a politiche. Il diagrammadelle classi UML riportato in Figura 5.1 mostra la modellazione degli elementivalutabili dal PDP. Per problemi di leggibilità della figura non sono state ripor-tate le classi Policy e PolicySet, dove comunque si ha solo la specifica del metodoevaluate e la lista delle componenti contenute.

Le componenti target, obbligazioni e identificatore, comuni a ogni elementosono fattorizzate nella classe PAFEvalElement. Nella classe per le regole si hainvece l’effetto e la condizione, mentre per politiche e insiemi di politiche sihanno il riferimento alla classe dell’algoritmo di combinazione e alla lista deglielementi interni.

Il metodo evaluate è definito per ogni elemento, e sarà richiamato dal PDP almomento della valutazione di una richiesta.

Dal diagramma in Figura 5.1 si nota anche che il metodo per il calcolo delvalore del target, cioè il getTargetDecision, è pubblico. Questo è necessario pergli algoritmi di combinazione che prima valutano l’applicabilità e poi eseguonola valutazione autorizzativa, ad esempio only-one-applicable.

5.1 ambiente di valutazione 71

Figura 5.1: Modellazione degli elementi valutabili dal PDP

La modellazione si avvale di interfacce e classi astratte; ciò implica che perpoter definire una regola, una politica o un insieme di politiche si deve esten-dere la corrispondente classe, creandone una propria. Questa soluzione è stataadottata per facilitare la generazione automatica del codice da FACPL. La clas-se che effettivamente definisce una politica non ridefinisce nessun metodo, mainserisce nel costruttore le componenti interne utilizzando i metodi addTarget,addObligation e simili.

Gli algoritmi di combinazione sono le componenti che gestiscono la valu-tazione di politiche e insiemi di politiche. La loro implementazione estendel’interfaccia EvaluableAlgorithm, che definisce il metodo evaluate da invocare periniziare la valutazione di una richiesta. La chiamata del metodo è su una lista diEvaluableElement e la decisione restituita è modellata con la classe DecisionResult,utilizzata nei livelli di valutazione superiori.

Ogni algoritmo descritto in XACML è stato implementato nella corrispondente


Figura 5.2: Modellazione algoritmi di combinazione

classe, ma si può creare un proprio algoritmo semplicemente implementandol’interfaccia EvaluableAlgorithm. Questo algoritmo può poi essere utilizzato nellavalutazione di una politica o di un insieme di politiche senza dover applicaremodifiche alla libreria. Il diagramma delle classi di due algoritmi implementatiè riportato in Figura 5.2.

Le classi per le componenti del target e della condizione non sono definitecome classi astratte e sono utilizzate per la definizione delle componenti internedelle politiche.

Nella classe TargetExpression si modella una singola espressione del target e ilconnettore logico che eventualmente la collega alla successiva. La valutazionedell’espressione è richiamata utilizzando il metodo evaluateTarget implementatoin questa classe. Il digramma delle classi è riportato in Figura 5.3.

La definizione delle condizioni utilizza due classi: ConditionExpression perla definizione del tipo a cui fa riferimento la classe Rule e ExpressionItem perla modellazione delle singole funzioni definite. A differenza del target, nellacondizione non si hanno i connettori logici, ma si possono avere condizioniannidate una nell’altra. Questa situazione è modellata facendo uso della classeExpressionItem.

Al momento della valutazione, richiamando il metodo evaluateCondition sivalutano tutte le singole espressioni definite utilizzando il metodo getValue, finoad applicare la funzione riportata nella classe ConditionExpression. Il diagrammadelle classi è riportato in Figura 5.4.

Per la definizione delle ultime componenti sopra descritte si utilizzano lefunzioni disponibili nella libreria. Le funzioni si suddividono in quelle che re-stituiscono un valore booleano e quelle che invece restituiscono un tipo Object.


Figura 5.3: Modellazione dei target

Nel target e nella classe esterna delle condizioni, cioè ConditionExpression, sidevono utilizzare le funzioni booleane.

Le funzioni sono definite su una lista di valori di tipo Object. Il controllosul numero e sul tipo degli argomenti ricevuti spetta all’implementazione dellafunzione. Inoltre, quando un argomento della funzione è un attributo multivalore, dato che dalla richiesta si riceve un oggetto di tipo Bag, si deve trattarel’argomento in modo adeguato.

L’ultima componente interna da modellare è l’obbligazione, la quale contienel’identificatore dell’azione da eseguire nel PEP, l’effetto di definizione e la listadegli argomenti per eseguire l’azione. La classe utilizzata è ObligationExpression,ma per restituire l’obbligazione dopo la valutazione da parte del PDP si utilizzala classe ObligationValue, che contiene gli argomenti trasformati in valori.

La richiesta autorizzativa da valutare è definita nella firma del metodo evalua-te con il tipo ContextRequest. Questa classe comprende l’insieme di attributi chedefiniscono la richiesta e lo stub mediante il quale collegarsi al contesto. Conquest’ultimo elemento si modella il ruolo del PIP definito nel Capitolo 2.

La richiesta e il contesto sono stati raccolti in un unica classe, così da rendereindifferente da dove avviene il recupero degli attributi. Nel dettaglio, quandosi ha una valutazione di target o condizioni, si recupera il valore di un attribu-to invocando il metodo getContextRequestValues, se l’attributo è presente nellarichiesta se ne ritorna il valore, altrimenti si controlla nel contesto. Nel caso incui anche la ricerca nel contesto non abbia buon esito, allora è lanciata un’ec-


Figura 5.4: Modellazione delle condizioni

cezione Missing Attribute e quella componente è valutata come false. Questasituazione corrisponde al valore di default dell’attributo MustBePresent definitoin Sezione 3.2.1.

Gli attributi che definiscono la richiesta sono formati da coppie nome-valore,di cui nel nome si riporta categoria e identificatore completo dell’attributo. Incaso di attributi multi valore, si definisce un unico attributo che ha come valoreun tipo Bag, cioè una classe utilizzata per raccogliere tutti i valori. Si utilizzaquesta classe così da identificare quando si tratta di attributi multi valore nellefunzioni per il target e per le condizioni.

Nel contesto, come elemento di default, è definito l’attributo tempo a cuisi può far riferimento con il nome strutturato environment/time. La strutturadella classe ContextRequest è riportata in Figura 5.5.

La modellazione delle componenti, definite dalla sintassi del contesto pre-sentata nel Capitolo 4 si completa con la definizione del tipo per il risultatodel PDP e del PEP. Il risultato del PDP è formato dalla decisione e della lista diobbligazioni collegate, mentre il PEP restituisce soltanto la decisione finale daapplicare.

La valutazione delle richieste nel PDP utilizza la sintassi estesa dei valori didecisione e ogni algoritmo di combinazione presente è definito seguendo questivalori. Come definito nello standard XACML, al momento della restituzione delvalore all’esterno del PDP si riporta però la decisione ai quattro valori classici(permit, deny, not-applicable e indeterminate).

Quando si rilevano delle valutazioni indeterminate nel target di una politica odi un insieme di politiche, si può scegliere se applicare la semantica descritta


Figura 5.5: Modellazione Context-Request

nella Sezione 3.2.3 oppure restituire subito il valore indeterminate. Questa sceltasi può effettuare con l’argomento booleano presente nel metodo evalRequest, cheè poi passato come argomento anche ai metodi evaluate di politiche e insiemidi politiche. Il parametro è stato inserito in quanto, come già detto nel Capito-lo 3, benché non siamo d’accordo, questo tipo di valutazione è stata comunqueimplementata per attenersi all’ultima versione dello standard.

Nell’implementazione del PDP è anche presente il metodo combineDecision, ne-cessario per combinare insieme le decisioni di più richieste, così come definitoin Sezione 3.3. Il processo di valutazione delle richieste è inoltre documentatocon tutti i valori di decisione delle singole componenti con un file di log. Laclasse che implementa il PDP è descritta in Figura 5.6.

Il livello di valutazione del PEP è realizzato in modo analogo al PDP, definen-do il metodo doEnforcement che esegue le azioni delle obbligazioni e restituiscela decisione finale. Il comportamento del metodo varia in base all’algoritmoper cui è definito il PEP. Le azioni da poter eseguire nel PEP possono essere in-crementate facilmente, offrendo quindi anche la possibilità di categorizzare leobbligazioni, come indicato in Sezione 4.3.4. La definizione della classe del PEP

è riportata in Figura 5.6.


Figura 5.6: Modellazione PDP e PEP

5.1.1 Test di conformità

La libreria di valutazione di FACPL implementa la semantica definita per XACML.Viste le molte componenti che intervengono nel calcolo della decisione finalesi è scelto di creare una suite di test per le funzionalità disponibili. I test sonostati creati avvalendosi di JUnit [4] e l’elenco completo dei test, con il rispettivocodice per eseguirli, sono riportati nel sito web relativo a FACPL [13].

L’attenzione dei test è rivolta in particolar modo alla gestione dei casi par-ticolari della valutazione del target, degli algoritmi di combinazione e delleobbligazioni. Ad esempio, la decisione restituita quando il target o la condi-zione sono vuoti oppure quali obbligazioni sono valutate. Per le obbligazioni,inoltre, ci si concentra anche sul test di come esse risalgono l’albero di valuta-zione delle politiche, assicurandosi che quelle restituite al livello di valutazionesuperiore, siano soltanto quelle dove l’attributo di applicabilità concorda con ladecisione del livello corrente.

5.2 strumenti di sviluppo

Per creare un supporto allo sviluppo delle politiche FACPL, in particolare sup-porto sintattico e controlli semantici sugli elementi, è stato sviluppato unplugin di Eclipse. Si è scelto questo strumento visto il suo utilizzo diffusoe le sue caratteristiche che ne permettono una facile integrazione con nuovicomponenti.

5.2 strumenti di sviluppo 77

La creazione di questo ambiente di sviluppo si è basata sul frameworkXtext [29], che offre molti strumenti per implementare un linguaggio. Nel det-taglio, dalla grammatica di definizione del linguaggio si crea automaticamenteuna libreria di classi Java per la modellazione delle varie categorie sintattiche.Sulla base di queste classi si crea un editor per il linguaggio integrato in Eclipse,si definiscono controlli semantici e un traduttore di codice per poter valutarerichieste sulle politiche definite.

Per meglio comprendere le funzionalità implementate andiamo a presentaregli strumenti di Xtext e a seguire i dettagli del plugin per FACPL.

5.2.1 Introduzione al framework Xtext

Xtext è uno strumento, sviluppato da Itemis [2], per la creazione di linguaggi diprogrammazione. A partire da un grammatica è possibile generare il parser dellinguaggio, il modello per la definizione dell’albero sintattico astratto e variealtre componenti per il supporto allo sviluppo.

La grammatica utilizzata per definire il linguaggio segue la struttura di unagrammatica ad attributi, con in aggiunta funzionalità particolari per semplifica-re la definizione delle categorie sintattiche. In particolare, è possibile utilizzareun insieme di tipi primitivi e assegnare ad un attributo della grammatica unriferimento a un’altra categoria sintattica, cioè si dichiara che in quell’attributovi possono essere soltanto gli identificatori delle istanze degli elementi dellacategoria indicata.

A partire dalla definizione della grammatica, utilizzando le funzionalità delModeling Workflow Engine (MWE), si generano tutte le componenti necessarieper supportare il linguaggio. Con MWE è possibile trasformare il modello de-finito dalla grammatica in un Eclipse Modeling Framework Core (EMF Core oEcore) [19].

Il modello Ecore definisce le caratteristiche dell’albero sintattico astratto, tra-mite il quale si genera l’insieme delle classi Java che lo implementano e il par-ser ANTLR del linguaggio. Sulla base del modello viene creato anche un plu-gin integrato in Eclipse, con un editor di testo specializzato per la sintassi dellinguaggio definito. L’editor generato offre agli utenti il controllo sintattico el’autocompletamento del codice.

La definizione dell’albero sintattico basata su classi, permette di definire con-trolli semantici, quali il controllo degli identificatori o il numero di argomentidi invocazione di una funzione, con semplici metodi Java. Questi controlli sonoapplicati nell’editor durante la scrittura del codice, supportando nello sviluppol’utente.

Collegata alla definizione dei controlli si ha anche la definizione dell’ambi-to di visibilità di una componente del linguaggio, ad esempio una variabile.Per default la visibilità di una dichiarazione è tutto il file dove è stata definita,


ma è possibile personalizzare queste regole a proprio piacimento, ad esempioassociando la visibilità in base ai blocchi di comandi presenti nel codice. Utiliz-zando i comandi di import, inoltre, si può creare una visibilità globale tra filediversi.

Tutte le componenti create sono assemblate tra loro utilizzando Google Gui-ce [9], che gestisce in modo automatico la risoluzione dei riferimenti alle singolecomponenti. Questo permette di specializzare il comportamento dei componen-ti e utilizzare le modifiche apportate senza dover modificare alcun riferimentoall’interno delle classi del plugin.

Sulla base delle caratteristiche del modello Ecore si può creare, utilizzando illinguaggio Xtend2 [28], un generatore di codice per il linguaggio. In particolare,associando a ogni categoria sintattica della grammatica la relativa regola ditraduzione, si può tradurre automaticamente il codice presente nell’editor disviluppo in un altro linguaggio. La definizione delle regole di traduzione èsemplificata dalla sintassi di Xtend2, che è poi automaticamente tradotta incodice Java, quello che effettivamente esegue la traduzione.

Nella definizione del plugin si possono inoltre inserire funzionalità aggiun-tive, come menù contestuali o altri aspetti grafici, utilizzando le tecniche disviluppo dei contenuti aggiuntivi di Eclipse.

5.2.2 Plugin per Eclipse

Il plugin sviluppato con Xtext per il supporto a FACPL si basa sulla gramma-tica definita nel Capitolo 4, con l’aggiunta di alcuni elementi per facilitare losviluppo. La grammatica comprende la sintassi del PAF, del contesto e una se-zione per la definizione di alcuni parametri per il processo di valutazione dellerichieste e per la generazione del codice.

Nella grammatica, regole, politiche e insiemi di politiche hanno associatoanche un identificatore, che si può utilizzare, nel caso di politiche o insiemi dipolitiche, con la parola chiave include per far riferimento a tale oggetto.

La struttura dei vari elementi rispecchia la sintassi di FACPL e la definizionedelle classi della libreria di valutazione prima presentata. Per facilitare l’orga-nizzazione del codice, si permette la suddivisione delle varie parti in più file,a cui è possibile far riferimento utilizzando il comando import, seguito dal no-me del file. Inserendo questo comando in un file, si possono utilizzare nel filecorrente le politiche e le richieste definite nel file importato.

Nella parte di contesto si ha la definizione delle richieste, che sono formateda un identificatore e un insieme di attributi. Nel caso di attributi multi valore,per facilitare la scrittura, si associa a un singolo nome una lista di valori, senzaripetere il nome dell’attributo per ogni valore.

Nella parte di definizione dei parametri del processo di valutazione è possibi-le indicare quale algoritmo deve seguire l’applicazione della decisione nel PEP,

5.3 applicazione al caso di studio 79

quali richieste valutare, se applicarvi una decisione combinata e quale approc-cio deve essere utilizzato per la gestione del caso indeterminate. Si ha inoltreun ulteriore parametro che serve per indicare il pacchetto dove deve essereposizionato il codice Java generato dalle politiche.

La definizione del comando import permette una facile suddivisione delladefinizione delle componenti del linguaggio, ma si possono creare conflitti dinomi tra politiche o altri componenti definiti in file diversi. Per evitare questeinconsistenze, sono stati definiti una serie di controlli tra i nomi degli elementipresenti nei vari file.

Nella grammatica sono inoltre presenti tutte le funzioni definite in Ap-pendice A e si possono utilizzare per la definizione dei target e dellecondizioni.

Una delle funzioni più importanti di Xtext è la possibilità di definire ungeneratore di codice Xtend2 sulla base della struttura sintattica del linguaggio.Nel plugin si utilizza questa caratteristica per tradurre le politiche e tutte le altrecomponenti in classi Java, pronte per essere valutate. Nelle classi generate, ognielemento che compone una regole, politica o insieme di politiche è inserito nellecorrispondenti classi facendo uso dei metodi addTarget e simili. La generazionedel codice predispone inoltre anche le classi per la definizione dello stub delcontesto, cioè un PIP esterno, delle azioni aggiuntive del PEP e degli algoritmidi combinazione personalizzati.

Oltre alla generazione di codice Java, dalle politiche FACPL è possibile gene-rare automaticamente anche il codice XML delle stesse in accordo alla versione3.0 dello standard XACML. Questa operazione associa a ogni elemento del lin-guaggio l’elemento XML corrispondente e gli attributi che lo definiscono. Gliidentificatori sono tradotti secondo le specifiche dello standard e i target sonoriorganizzati per rispettare la struttura descritta nel Capitolo 3.

Nella definizione del plugin, per il supporto nell’utilizzo delle funzionalitàsopra presentate si ha anche la parte di definizione di vari aspetti grafici.

5.3 applicazione al caso di studio

Dopo aver presentato l’ambiente di valutazione e gli strumenti di sviluppo di-sponibili per FACPL, utilizziamo il caso di studio epSOS per definire un manualed’uso del plugin, specificando quali comandi utilizzare per usufruire di tutte lefunzionalità disponibili.

La libreria di valutazione è rilasciata con un file jar sul sito [13] ed è compa-tibile con la versione Java 1.6 o superiore. Per l’installazione del plugin Eclipseè necessario aggiungerlo come componente aggiuntivo dall’apposito menù del-l’applicativo. L’indirizzo da dove scaricare il plugin è riportato nelle istruzionidi installazione sul sito [13]. Al momento dell’installazione del plugin è neces-


Figura 5.7: Procedura guidata per la creazione di un file FACPL

sario selezionare tutte le dipendenze dai componenti Xtext, altrimenti non sipossono utilizzare le funzionalità prima descritte. Completata l’installazione èquindi possibile utilizzare l’ambiente di lavoro per FACPL.

Le funzionalità descritte nella Sezione 5.2.2 sono disponibili soltanto per l’edi-tor dei file di tipo FACPL. Un file è considerato da Eclipse di tipo FACPL quandoè definito con l’estensione ’.flp’.

Per utilizzare in un unico progetto anche la libreria di valutazione delle richie-ste, creiamo un progetto Java e dal menù aggiungiamo un file FACPL, creandoun file generico con estensione ’.flp’. Al momento della creazione del file èrichiesto se associare quel file alla tipologia di progetto Xtext, cioè Eclipse hariconosciuto l’estensione del file e vuol sapere se deve rendere disponibili lefunzionalità del nostro plugin; ovviamente acconsentiamo.

La creazione di un nuovo file può essere effettuata anche attraverso un’appo-sita procedura di creazione guidata, disponibile sotto la categoria FACPL tra ivari tipi di file del menù New File. La procedura permette di definire il nomedel file, dove collocarlo e se inserire un modello delle varie parti della sintassi.La schermata da utilizzare è quella visualizzata in Figura 5.7

L’ambiente di sviluppo creato offre il supporto anche durante la scrittura del-le politiche, fornendo mediante l’autocompletamento indicazioni sulla sintassicorretta degli elementi. Questo comando si può richiamare durante la scritturautilizzando la combinazione di tasti Ctrl + Space. I consigli offerti spaziano dalleparole chiave per la definizione delle politiche, alla struttura dei tipi di dato.

I tipi di dato definiti nella grammatica di FACPL seguono una sintassi benprecisa, che possiamo così descrivere:

- gli interi e i reali sono rappresentati senza alcun simbolo che preceda ilnumero e il separatore dei decimali, nel caso dei reali, è il punto;


- i booleani sono definiti inserendo le parole chiave true o false;

- le stringhe sono definite racchiudendo la sequenza di caratteri travirgolette;

- i valori data-ora sono preceduti da un cancelletto ed espressi secondo laforma yyyy/MM/dd-HH:mm:ss, dove le lettere hanno il significato tipico deiformati delle date;

- i nomi strutturati sono formati da due sequenze di stringhe separate traloro dal segno ’/’ e le stringhe non sono racchiuse tra virgolette.

Per i nomi strutturati, inoltre, è sempre disponibile anche il riferimentoall’attributo environment/time che indica la data e l’ora.

L’autocompletamento oltre a fornire un aiuto per le parole chiave della sin-tassi e la struttura dei tipi di dato, riporta anche l’elenco delle dichiarazionipresenti, quindi dei riferimenti a politiche o richieste che si possono utilizza-re. Per includere una politica in un insieme di politiche si inserisce la parolachiave include seguita dal nome, mentre le richieste sono inserite nell’appositoparametro di valutazione. Se si vuole utilizzare dichiarazioni esterne al file sideve utilizzare il comando import. Se ad esempio le richieste definite in Appen-dice B devono essere utilizzate in un file si deve importare il file dove sonodefinite.

L’elenco delle richieste da valutare è solo uno dei valori presenti nella sezionedei parametri del codice FACPL. I parametri utilizzati per la valutazione dellepolitiche epSOS sono i seguenti:

PEPAlg base ;

Combined Decision = false;

Extended Indeterminate = false;

Generated Package = "epsos";

Eval Request req1 , req2, req3, req4

I parametri sopra definiti hanno il seguente significato:

- PEPAlg: seleziona quale tra gli algoritmi base, deny-biased e permit-biaseddeve essere utilizzato per applicare la decisione;

- Combined Decision: determina se si deve combinare la decisione dellerichieste da valutare, seguendo quanto definito nella Sezione 3.3;

- Extended Indeterminate: seleziona quale versione della gestione dei valo-ri indeterminate, vedi Sezione 5.1, deve essere utilizzata per la valutazionedelle richieste;

- Generated Package: definisce il pacchetto dove devono essere inserite leclassi Java generate dal codice FACPL;


Figura 5.8: Colorazione e formattazione del codice FACPL

- Eval Request: definisce l’insieme delle richieste che devono essere valu-tate, ci possono anche essere identificatori di richieste importati da altrifile.

Nell’esempio prima riportato si ha quindi che l’applicazione della decisione èfatta seguendo l’algoritmo base del PEP, mentre per la valutazione delle quattrorichieste nel PDP non si richiede né una decisione combinata né la valutazioneapprofondita dei valori indeterminate.

Dopo che le politiche epSOS sono definite nell’editor, è possibile analizzarela struttura delle varie componenti utilizzando varie funzionalità grafiche disupporto.

Gli elementi sintattici del codice, per essere individuati più facilmente, sonoevidenziati con tonalità di colore diverse. Nel dettaglio, si è associato ad alcunecategorie sintattiche, ad esempio identificatori, effetti e funzioni, una regola dicolorazione e formattazione del carattere diversa. Questa operazione è svolta inmodo automatico dall’editor.

Per visualizzare invece la struttura gerarchica di regole, politiche, insiemi dipolitiche e dei vari componenti interni, si è definito l’outline del documento e uncomando di formattazione automatica del codice. Il comando di formattazioneè richiamato dalla combinazione di tasti Ctrl + Shfit + F o in alternativa dallavoce Format nel menù del tasto destro, e imposta la spaziatura e l’indentazionedel codice. La colorazione automatica e la formattazione standard delle politi-che si può vedere in Figura 5.8. Sempre nella stessa figura è possibile vedere,sulla parte destra, l’outline del documento.


Definito il codice, è possibile adesso generare le classi Java per la valutazionedelle richieste. Il comando di generazione del codice può essere selezionatodal menù del tasto destro, ottenuto cliccando sull’editor o direttamente sul file,oppure dal menù FACPL che compare sulla barra dei menù quando l’editor èattivo.

La generazione del codice crea tutti i file Java necessari per la valutazionedelle richieste e la personalizzazione di algoritmi, azioni e contesto. Da un fileFACPL completo, cioè formato da tutte le componenti sintattiche prima citate,sono create:

- una classe per ogni richiesta e una classe di stub per la definizione di uneventuale contesto;

- una classe per ogni politica o insieme di politiche;

- una classe per la definizione del PDP, cioè il riferimento agli elementi chelo compongono e all’algoritmo di combinazione da applicare;

- una classe per l’inizializzazione delle azioni del PEP e del suo algorit-mo e un’altra classe per la definizione di eventuali azioni aggiuntivedisponibili;

- una classe Main che gestisce le chiamate del PDP e del PEP.

Se nelle politiche è scelto l’algoritmo di combinazione personalizzato, allo-ra si deve implementare la classe aggiuntiva che si crea dalla generazionedel codice. Mentre, per la definizione del contesto si deve utilizzare la classeContextStub, dove è già disponibile l’attributo che restituisce la data e l’ora. Seinvece si vuole aggiungere delle azioni eseguibili dal PEP, oltre alla mail e allog, si deve aggiungere nella classe PEPAction l’identificatore dell’azione da uti-lizzare per la definizione delle obbligazioni e il riferimento alla classe che laimplementa. In ogni classe creata per personalizzare il processo di valutazione,è comunque presente un piccolo esempio commentato, che si può seguire comeguida.

Quando si genera il codice a partire da un file FACPL dove ci sono anche deicomandi import, automaticamente è generato anche il codice dei file importati,senza la necessità di fare operazioni aggiuntive.

Per generare il codice XML a partire dalla politiche FACPL, invece, si utilizzail comando disponibile nel menù contestuale e i file generati sono posti nellacartella src-xml.

Completata la generazione del codice Java si può utilizzare la libreria, de-scritta in Sezione 5.1, per la valutazione delle richieste. Per completare questaoperazione si deve prima aggiungere alle risorse del progetto Java il jar disponi-bile sul sito [13]. Per eseguire la valutazione delle richieste è sufficiente eseguire


Figura 5.9: Messaggio generato dal processo di valutazione FACPL

il file Main.java come un’applicazione Java. Il risultato di questa operazione èun messaggio a video che riporta le decisione prese dal PDP e dal PEP per lerichieste valutate.

Se prendiamo le politiche FACPL del caso di studio definite nell’editor comein Figura 5.8, vi possiamo applicare l’insieme R formato dalle richieste presentiin Appendice B e vedere le decisioni calcolate. L’esito della valutazione dellerichieste mostrato a video è quello riportato in Figura 5.9. Si può vedere che ledecisioni calcolate dalla libreria di valutazione concordano con quelle definitedalla semantica formale nella Sezione 4.4.

La descrizione a video non riporta tutti i dettagli della valutazione eseguita,ma all’interno del progetto è possibile trovare un file di log, contenente la de-scrizione dei risultati della valutazione di tutte le componenti. In dettaglio, ilfile di log riporta tutte le chiamate alle funzioni di valutazione e agli algoritmidi combinazione e le decisioni ottenute. Un esempio di log per la valutazionedi un target è il seguente:

PermitOverrides - -> permit override started

Rule - rule1: start rule eval

PAFEvalElement - rule1- evaluateTarget:

Request - Request_attribute: Struct_Name action + action-id

Request - Attribute values: Read

TargetExpression - Loading method: evaluateFunction


TargetExpression - End target expression eval. Decision: MATCH

TargetTree - Target Expression Decision: MATCH

PAFEvalElement - End Target Decision: MATCH

Rule - MatchDecision:MATCH

Tutto il processo di valutazione delle richieste è documentato seguendo lastruttura del frammento sopra presentato. Il log può essere utilizzato per con-trollare il comportamento delle politiche e trovare eventuali errori nella lorodefinizione.

Le funzionalità descritte nella presente sezione permettono di definire poli-tiche FACPL e calcolare le decisioni per le richieste di accesso all’interno di ununico ambiente di lavoro. La libreria per la valutazione delle richieste può an-che essere utilizzata separatamente dal plugin Eclipse, definendo le classi Javacorrispondenti a politiche e richieste. Il supporto sintattico e la generazione au-tomatica del codice permettono però una maggiore produttività dell’attività disviluppo.

6C O N C L U S I O N I

In questa tesi abbiamo affrontato le problematiche collegate al controllo degliaccessi e all’utilizzo degli standard a esso collegati, con particolare attenzionea XACML.

La descrizione dello standard XACML ha delineato i ruoli e i compiti del pro-cesso di autorizzazione e le caratteristiche delle politiche del modello PBAC. Ladefinizione del processo di valutazione delle richieste in linguaggio naturale hafatto si che non tutte le implementazioni di XACML siano consistenti tra loro.Nel dettaglio, alcuni casi particolari di valutazione non sono gestiti nello stes-so modo e, per ottenere uguali risultati di valutazione, è necessario effettuarepiccole modifiche alle politiche.

Il nostro lavoro è stato quello di definire il linguaggio alternativo FACPL e glistrumenti necessari al suo utilizzo. La definizione di FACPL permette di scriverepiù agevolmente le politiche e, utilizzando gli strumenti implementati, di valu-tarle e tradurle in corrispondenti politiche di XACML 3.0. A questo si aggiungel’utilità della definizione delle regole semantiche, che permettono di compren-dere in dettaglio il funzionamento del processo di autorizzazione. Perciò, taliregole possono anche servire come guida all’implementazione di architetturedi valutazione.

La creazione dell’ambiente di sviluppo entro Eclipse, facendo uso del fra-mework Xtext, offre varie funzionalità di supporto alla scrittura e permette inol-tre di introdurre, in futuro, altre componenti per esempio collegate all’analisidelle politiche.

L’architettura di valutazione implementata è verificata secondo i test descrittinel Capitolo 5. Non è stato però possibile definire dei test di confronto completicon altri tool XACML, in quanto attualmente la versione 3.0 non è stata ancorarilasciata e tutte le implementazioni note, come HERASAF, sono definite per laversione 2.0, non compatibile sintatticamente con la nuova versione.

6.1 sviluppi futuri

Le regole della semantica formale permettono lo sviluppo di tecniche di analisiper il confronto tra politiche e la verifica di proprietà. Ad esempio, equivalenze

87

88 conclusioni

e preordini tra decision-tuple associate a differenti politiche sarebbero un primoobbiettivo da sviluppare per definire relazioni tra politiche. Questo approcciopuò essere utilizzato anche per gli algoritmi di combinazione, definendo dellerelazioni tra loro, allo scopo di identificare le differenze e valutare anche nuovialgoritmi da inserire nel processo di valutazione.

Quando si definisce un insieme di politiche per un sistema di controllo de-gli accessi, l’effetto globale delle politiche non è facile da analizzare. A questoscopo, la definizione di proprietà di copertura rispetto ai requisiti di sicurez-za o altre asserzioni logiche, è un elemento di supporto importante per glisviluppatori.

La modifica e l’aggiornamento delle politiche è una operazione che deve assi-curare l’assenza di modifiche al comportamento globale del sistema, cioè deveevitare carenze di sicurezza o risorse non adeguatamente gestite. Il controllodi queste operazioni si può effettuare facendo uso dell’analisi conosciuta comechange impact analysis [5]. Con questa analisi è possibile confrontate due politi-che tra loro e vedere le differenti conseguenze sul sistema. In letteratura sonogià presenti lavori a riguardo, devono però essere adattati alla ultime versionidello standard. L’utilizzo di questa analisi e dei preordini nell’estensione dellepolitiche assicurano un codice stabile e corretto.

Un aspetto legato non direttamente alla semantica, ma che influenza note-volmente le prestazioni del processo di valutazione, è la definizione del PAP,cioè delle modalità di salvataggio e recupero delle politiche. Da parte di OASIS

non ci sono indicazioni sulle tecniche da seguire, ma soltanto alcune modalitàdi gestione degli aggiornamenti delle politiche riportati in [24]. L’utilizzo di lo-giche descrittive per rappresentare le politiche potrebbe essere una tecnica dautilizzare per indicizzare le politiche, agevolandone così il recupero.

Gli strumenti implementati possono essere estesi con il supporto all’analisidi politiche, realizzando gli aspetti sopra descritti, e introducendo la gestionedel PAP definita in [24]. Per il PEP, invece, si potrebbe definire una semantica piùdettagliata, introducendo anche la suddivisione in categorie delle obbligazionipresentata in Sezione 4.3.4.

Un aspetto importante da valutare è una più completa analisi delle per-formance, confrontando anche future implementazioni di XACML 3.0. L’ar-chitettura di valutazione, inoltre, può essere definita come un servizio webcomprensivo di ogni componente, dal PEP al PDP e al PAP.

6.2 lavori collegati

Nella letteratura scientifica sono molti i lavori collegati a XACML e sono orien-tati principalmente alla definizione di logiche per l’analisi del processo diautorizzazione.

6.2 lavori collegati 89

Una logica per la formalizzazione di XACML è stata proposta da Nielson, Niel-son e Ramli in [20]. Facendo uso prima di una logica a tre valori, estesa poi asei per rappresentare tutti i casi di indeterminate, gli autori definiscono dellefunzioni di valutazione per i singoli elementi di XACML. Con queste funzioniè possibile poi costruire delle relazioni d’ordine per gli algoritmi di combina-zione, mostrando in un reticolo la relazione d’ordine tra i vari valori ottenibilicombinando più politiche.

Un approccio simile al precedente, ma dedicato principalmente ai target e allepolitiche, è presentato da Morisset e Crampton in [7]. In questo caso è utilizza-ta una logica a tre valori per modellare la valutazione degli elementi e definirerelazioni d’ordine tra essi. Nella prima parte, l’articolo si concentra sulla defi-nizione di operatori che permettono il confronto tra target, mentre a seguireestende i risultati per la combinazione di politiche. Questo approccio offre lapossibilità di valutare i target rispetto ad eventuali attacchi basati su riscritturao cancellazione di attributi della richiesta, minimizzando così comportamentinon desiderabili.

In riferimento alla change impact analysis, [8] propone il tool Margrave per va-lutare le differenze tra due versioni di una politica. Gli elementi di XACML sonorappresentati facendo uso di un multi-terminal binary decision diagram, cioè unaforma particolare di diagramma delle decisioni, sul quale si possono provarecondizioni logiche. Il diagramma è poi esteso per permettere il confronto tracoppie di politiche e quindi realizzare la change impact analysis. Per elaborarequesti diagrammi sono definite una serie di operazioni, che sono alla base delfunzionamento del tool.

Il tema del confronto tra politiche XACML è trattato anche in [11]. In questocaso, basandosi su una logica descrittiva decidibile, sono definite delle analisi,per individuare ridondanze e verificare condizioni logiche. La logica utilizzatapermette anche di definire tecniche di indicizzazione di politiche e analisi diproprietà di copertura dei requisiti.

Strumenti esistenti che supportano XACML 3.0 non ci sono, ma già l’utilizzodi HERASAF, definito per la versione 2.0, permette di comprendere le compo-nenti necessarie per definire il processo di valutazione delle richieste. Inoltre,un tool molto utile è X-Create [12], che data una politica definisce in modoautomatico una suite di richieste di test. Le richieste sono generate sulla basedella definizione dei target.

92 funzioni di match e linguaggio per le espressioni

Nella definizione della grammatica di FACPL e poi anche per la realizzazionedel linguaggio in Xtext si utilizza la grammatica delle condizioni riportata inTabella A.2 e A.3.

Expression ::= string-equal(StringExpr, StringExpr)

| boolean-equal(BoolValue, BoolValue)

| integer-equal(IntExpr, IntExpr)

| double-equal(DoubleExpr, DoubleExpr)

| and(BoolValue, . . . , BoolValue)

| or(BoolValue, . . . , BoolValue)

| not(BoolValue)

| integer-greater-than(IntExpr, IntExpr)

| integer-greater-than-or-equal(IntExpr, IntExpr)

| integer-less-than(IntExpr, IntExpr)

| integer-less-than-or-equal(IntExpr, IntExpr)

| double-greater-than(DoubleExpr, DoubleExpr)

| double-greater-than-or-equal(DoubleExpr, DoubleExpr)

| double-less-than(DoubleExpr, DoubleExpr)

| double-less-than-or-equal(DoubleExpr, DoubleExpr)

| dateTime-greater-than(DateExpr, DateExpr)

| dateTime-greater-than-or-equal(DateExpr, DateExpr)

| dateTime-less-than(DateExpr, DateExpr)

| dateTime-less-than-or-equal(DateExpr, DateExpr)

| string-at-least-one-member-of(BagExpr, BagExpr)

| string-subset(BagExpr, BagExpr)

Tabella A.2: Grammatica per le espressioni delle condizioni - Parte 1

BR I C H I E S T E D ’ A C C E S S O P E R I L C A S O D I S T U D I O

Listato B.1: Caso di studio epSOS - Request 1

Reque s t : {Request1( s u b j e c t / pu rpo seo fu s e , "TREATEMENT" )( s u b j e c t / r o l e , "med i ca l doc to r " )( s u b j e c t / doctor−id , " jh1234 " )( s u b j e c t / h l 7 . p e rm i s s i on , "PRD−003" )( s u b j e c t / h l 7 . p e rm i s s i on , "PRD−005" )( s u b j e c t / h l 7 . p e rm i s s i on , "PRD−010" )( s u b j e c t / h l 7 . p e rm i s s i on , "PRD−016" )( r e s o u r c e / r e s ou r c e−id , "34133−9" )( r e s o u r c e / r e s ou r c e−i d . emai l , "ma i l@gma i l . com" )( a c t i o n / ac t i on−id , "Read" )

}


Reque s t : {Request2( s u b j e c t / pu rpo seo fu s e , "TREATEMENT" )( s u b j e c t / r o l e , "med i ca l doc to r " )( s u b j e c t / doctor−id , " jh1234 " )( s u b j e c t / h l 7 . p e rm i s s i on , "PRD−004" )( s u b j e c t / h l 7 . p e rm i s s i on , "PRD−010" )( r e s o u r c e / r e s ou r c e−id , "57829−4" )( r e s o u r c e / r e s ou r c e−i d . emai l , "ma i l@gma i l . com" )( a c t i o n / ac t i on−id , "Read" )

}

95

96 richieste d’accesso per il caso di studio


Reque s t : {Request3( s u b j e c t / pu rpo seo fu s e , "TREATEMENT" )( s u b j e c t / r o l e , "med i ca l doc to r " )( s u b j e c t / doctor−id , " jh1234 " )( s u b j e c t / h l 7 . p e rm i s s i on , "PRD−004" )( s u b j e c t / h l 7 . p e rm i s s i on , "PRD−010" )( r e s o u r c e / r e s ou r c e−id , "57829−4" )( r e s o u r c e / r e s ou r c e−i d . emai l , "ma i l@gma i l . com" )( a c t i o n / ac t i on−id , " De l e t e " )

}


Reque s t : {Request4( s u b j e c t / pu rpo seo fu s e , "TREATEMENT" )( s u b j e c t / r o l e , "med i ca l doc to r " )( s u b j e c t / h l 7 . p e rm i s s i on , "PRD−003" )( s u b j e c t / h l 7 . p e rm i s s i on , "PRD−005" )( s u b j e c t / h l 7 . p e rm i s s i on , "PRD−010" )( s u b j e c t / h l 7 . p e rm i s s i on , "PRD−016" )( r e s o u r c e / r e s ou r c e−id , "34133−9" )( r e s o u r c e / r e s ou r c e−i d . emai l , "ma i l@gma i l . com" )( a c t i o n / ac t i on−id , "Read" )

}

B I B L I O G R A F I A

[1] XACML Implementations. https://www.oasis-open.org/committees/tc_

home.php?wg_abbrev=xacml#other.

[2] Itemis AG. Model Based Software Development. http://xtext.itemis.com/.

[3] Axiomatics. XACML customers. http://www.axiomatics.com/customers.

html.

[4] Kent Beck. Junit - resources for test driven development, 2012. http:

//www.junit.org/.

[5] S.A. Bohner and R.S. Arnold. Software change impact analysis. PractitionersSeries. IEEE Computer Society Press, 1996.

[6] J. Clark and S. DeRose. XML Path Language (XPath) version 1.0, 1999.http://www.w3.org/TR/xpath.

[7] Jason Crampton and Charles Morisset. Ptacl: A language for attribute-based access control in open systems. In POST, volume 7215 of LectureNotes in Computer Science, pages 390–409. Springer, 2012.

[8] Kathi Fisler, Shriram Krishnamurthi, Leo A. Meyerovich, and Michael CarlTschantz. Verification and change-impact analysis of access-controlpolicies. In ICSE, pages 196–205. ACM, 2005.

[9] Goole. Google guice - a lightweight dependency injection framework, 2011.http://code.google.com/p/google-guice/.

[10] Alan H. Karp. Authorization-based access control for the services orientedarchitecture. In C5, pages 160–167. IEEE Computer Society, 2006.

[11] Vladimir Kolovski, James A. Hendler, and Bijan Parsia. Analyzing webaccess control policies. In WWW, pages 677–686. ACM, 2007.

[12] LabSe. X-create. http://labsewiki.isti.cnr.it/labse/tools/xcreate/

public/main.

[13] Andrea Margheri. Formal access control policy language, 2012. http:

//rap.dsi.unifi.it/xacml_tools/.

[14] Massimiliano Masi, Rosario Pugliese, and Francesco Tiezzi. Formalisationand implementation of the xacml access control mechanism. In ESSoS,

97

https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=xacml # other

https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=xacml # other

http://xtext.itemis.com/

http://www.axiomatics.com/customers.html

http://www.axiomatics.com/customers.html

http://www.junit.org/

http://www.junit.org/

http://www.w3.org/TR/xpath

http://code.google.com/p/google-guice/

http://labsewiki.isti.cnr.it/labse/tools/xcreate/public/main

http://labsewiki.isti.cnr.it/labse/tools/xcreate/public/main

http://rap.dsi.unifi.it/xacml_tools/

http://rap.dsi.unifi.it/xacml_tools/

98 Bibliografia

volume 7159 of Lecture Notes in Computer Science, pages 60–74. Springer,2012.

[15] NIST. A survey of access control models, 2009. http:

//csrc.nist.gov/news_events/privilege-management-workshop/

PvM-Model-Survey-Aug26-2009.pdf.

[16] OASIS XACML TC. Security assertion markup language (saml). http:

//saml.xml.org/.

[17] OASIS XACML TC. eXtensible Access Control Markup Language(XACML) version 2.0, 2005. http://docs.oasis-open.org/xacml/2.0/

access_control-xacml-2.0-core-spec-os.pdf.

[18] The Eclipse Foundation open source community. Eclipse. http://www.

eclipse.org/.

[19] The Eclipse Foundation open source community. Eclipse modelingframework project, 2009. http://www.eclipse.org/modeling/emf/.

[20] Carroline Dewi Puspa Kencana Ramli, Hanne Riis Nielson, and FlemmingNielson. The logic of xacml - extended. CoRR, abs/1110.3706, 2011.

[21] Morris Sloman. Policy driven management for distributed systems. J.Network Syst. Manage., 2(4):333–360, 1994.

[22] OASIS XACML TC. eXtensible Access Control Markup Language(XACML) version 3.0 c.s. 01, 2010. http://docs.oasis-open.org/xacml/

3.0/xacml-3.0-core-spec-cs-01-en.pdf.

[23] OASIS XACML TC. XACML v3.0 Multiple Resource Profile ver-sion 1.0, April 2009. http://docs.oasis-open.org/xacml/3.0/xacml-3.

0-multiple-v1-spec-cd-1-en.pdf.

[24] OASIS XACML TC. XACML v3.0 Administration and Delegation Pro-file version 1.0, August 2010. http://docs.oasis-open.org/xacml/3.0/

xacml-3.0-administration-v1-spec-cs-01-en.pdf.

[25] The epSOS project. A european ehealth project. http://www.epsos.eu.

[26] The Herasaf consortium. HERASAF. http://www.herasaf.org.

[27] XACML users. Discussion for future PAP architecture. https:

//wiki.oasis-open.org/xacml/Policy%20Administration%20Point%

20Architecture.

[28] Xtend2, 2012. http://www.eclipse.org/xtend/.

[29] Xtext. Language Development Made Easy. http://www.eclipse.org/Xtext/.

http://csrc.nist.gov/news_events/privilege-management-workshop/PvM-Model-Survey-Aug26-2009.pdf



http://saml.xml.org/

http://saml.xml.org/

http://docs.oasis-open.org/xacml/2.0/access_control-xacml-2.0-core-spec-os.pdf

http://docs.oasis-open.org/xacml/2.0/access_control-xacml-2.0-core-spec-os.pdf

http://www.eclipse.org/

http://www.eclipse.org/

http://www.eclipse.org/modeling/emf/

http://docs.oasis-open.org/xacml/3.0/xacml-3.0-core-spec-cs-01-en.pdf

http://docs.oasis-open.org/xacml/3.0/xacml-3.0-core-spec-cs-01-en.pdf

http://docs.oasis-open.org/xacml/3.0/xacml-3.0-multiple-v1-spec-cd-1-en.pdf

http://docs.oasis-open.org/xacml/3.0/xacml-3.0-multiple-v1-spec-cd-1-en.pdf

http://docs.oasis-open.org/xacml/3.0/xacml-3.0-administration-v1-spec-cs-01-en.pdf

http://docs.oasis-open.org/xacml/3.0/xacml-3.0-administration-v1-spec-cs-01-en.pdf

http://www.epsos.eu

http://www.herasaf.org

https://wiki.oasis-open.org/xacml/Policy%20Administration%20Point%20Architecture



http://www.eclipse.org/xtend/

http://www.eclipse.org/Xtext/

Progetto e realizzazione di un linguaggio formale per il...

Documents

Transcript of Progetto e realizzazione di un linguaggio formale per il...