e Xtensible access control Markup Language XACML Maurizio

e. Xtensible access control Markup Language (XACML) Maurizio Argoneto

Cos’è XACML ? � Acronimo di: e. Xtensible Access Control Markup Language � Standard OASIS che descrive: � Un linguaggio di Policy, utilizzato per descrivere i requisiti generali del controllo degli accessi a risorse distribuite. (xmlns: xacml=“urn: oasis: names: tc: xacml: 2. 0: policy: schema: os”) � Un linguaggio per gestire gli accessi a risorse, che permette di sapere quando una data azione su di una risorsa può essere compiuta o meno e di interpretarne un eventuale risultato. (xmlns: xacmlcontext=“urn: oasis: names: tc: xacml: 2. 0: context: schema: os”) � Entrambi i linguaggi sono derivati dall’XML.

Contesto di utilizzo tipico � Qualcuno vuole effettuare alcune operazioni su di una risorsa (posta su file system ditribuiti o su server web). � L’azione può essere portata a termine solo se chi la esegue ha i giusti permessi. � Bisogna definire chi fa da tramite tra i passi precedenti e stabilisce il proseguire o meno dell’operazione.

Requisiti �I requisiti minimi per un linguaggio di policy sono: �Combinare regole e policy individuali in un unico set di policy �Provvedere ad una definizione flessibile delle procedure per cui regole e policy vengono combinate �Provvedere alla creazione di metodi per trattare multipli soggetti in azione �Avere metodi di base per effettuare delle decisioni di autorizzazione su attributi delle risose richieste �Provvedere alla creazione di metodi per trattare con attributi multi-valore

Punti a favore di XACML � E’ uno standard � Si utilizza qualcosa che è stato gia rivisto da community di esperti e utenti. � E’ generico � Può essere utilizzato in qualsiasi sistema. � E’ distribuito � Una policy può riferirsi ad altre policy poste in contesti arbitrari. � E’ potente � In quanto può essere esteso tramite l’aggiunta di nuovi tipi di dati, nuove funzioni e ruoli.

Funzionamento

PEP (Policy Enforcement Point) E’ quell’entità di sistema che effettua il controllo sugli accessi, facendo richieste di decisione e facendo rispettare le decisioni di autorizzazione. Livello logico che protegge la risorsa richiesta (posta su file system distribuito o web server che sia)

PEP (Policy Enforcement Point) Il PEP DEVE attenersi alla decisione di autorizzazione

Funzionamento

PIP (Policy Information Point) E’ l’entità di sistema che ha la funzione di archivio dei valori dei vari attributi di risorsa, azione o ambiente. Esso fornisce i valori degli attributi al context handler.

Funzionamento

PDP (Policy Decision Point) E’ l’entità di sistema che valuta le policy applicabili e produce la decisione di autorizzazione per l’esecuzione dell’azione sulla risorsa richiesta.

PDP (Policy Decision Point) �Quando un utente cerca di accedere ad una risorsa, il PEP ne definisce gli attributi ed assegna al PDP il compito di decidere se autorizzare o meno la richiesta. �La decisione è presa in base alla descrizione degli attributi dell’utente.

Funzionamento

PAP (Policy Administration Point) E’ quella parte di sistema che produce le singole policy e i gruppi di policy (policy set) e le salva in un apposito repository

Data Flow Model

Data Flow model (1)

Data Flow model (2) �Situazione di base: �qualcuno vuole effettuare un’azione su di una risorsa �Questo il flusso delle operazioni: �Il PAP scrive policy singole o set di policy e le rende disponibili al PDP. Questi set di oggetti rappresentano le politiche per uno specifico target �Chi richiede l’accesso alla risorsa, effettua una richiesta al PEP �Il PEP manda la richiesta al Context handler aggiungendo attributi per la risorsa, l’azione e il sistema

Data Flow model (3) �Il context handler, prima richiede gli attributi dal PIP, poi costruisce una richiesta XACML e la manda al PDP �Il PDP valuta le politiche allegate alla richiesta �Infine ritorna la risposta (con inclusa la decisione di autorizzazione) al context handler �Il context handler traduce la risposta e la ritorna al PEP �Il PEP fa rispettare gli obblighi dati dalla decizione di autorizzazione �Se l’accesso è permesso, quindi, il PEP autorizza il richiedente ad accedere alla risorsa, altrimenti gli nega l’accesso

Context Handler E’ l’entità di sistema che converte la richiesta dal suo formato nativo al formato canonico XACML e viceversa e che permette la comunicazione tra tutte le altre componenti del sistema.

Policy language model �Le 3 principali componenti di questo modello sono: �Regole �Policy Set

Regole �Una regola è l’unità elementare di una policy �Può essere valutata in base al contesto �I componenti di una regola sono: �Il target �L’effetto �Una condizione �Nel markup sono rappresentate da più elementi <Rule>

Regole – Il Target �Il target definisce un set di: �Risorse �Soggetti �Azioni �Ambienti Ai quali la regola deve essere applicata • Nel markup, è rappresentato dall’elemento <Target>

Regole – L’effetto di una regola indica cosa intende l’autore di tale regola per una risposta vera o una risposta falsa a tale regola. E’ una conseguenza della Rule. Sono permessi solo due valori • Permit • Deny Nel markup, è rappresentato dall’attributo obbligatorio Effect, dell’elemento Rule

Regole – La condizione di una regola rappresenta un espressione booleana che raffina l'applicabilità della regola oltre i predicati impliciti del relativo target. Di conseguenza, può essere assente. Una condizione indica delle valutazioni sugli attribuiti che provengono da un contesto di richiesta. I valore che questa condizione può ritornare sono True, False o Indeterminate segnala una condizione di errore interna al PDP. Nel caso in cui la condition restituisca False, la regola sarà Not. Applicable Nel markup è rappresentata dall’elemento <Condition>, figlio dell’elemento <Rule>

Policy Dal Data Flow model è possibile vedere che le regole non sono scambiate tra le entità del sistema. Di conseguenza, è compito del PAP combinare le regole in una policy Una policy comprende 4 componenti: • Un target • Un algoritmo di combinazione delle regole (applicabile per forza se la policy ha più di una regola) • Un set di regole • Obbligazioni Nel markup è rappresentata dall’elemento <Policy>

Policy – Il Target �Esattamente come per le regole, il target definisce un set di: �Risorse �Soggetti �Azioni �Ambienti Ai quali la policy corrente dev’essere applicata

Policy – algoritmo di combinazione delle regole E’ un algoritmo che specifica le procedure per le quali i risultati di valutazione delle regole componenti sono uniti quando la politica viene valutata Una policy può avere dei parametri combinati che vanno ad influire all’esecuzione e ai risultati di questo algoritmo

Policy - Obblighi Gli obblighi possono essere aggiunti dell’autore della policy Quando il PDP valuta una policy che contiene degli obblighi restituisce un certo numero di quegli obblighi al PEP nel contesto di risposta Gli obblighi, nel markup, sono rappresentate dall’elemento <Obbligations>

Policy Set �Un Policy Set contiene 4 componenti: • • Un target Un algoritmo di combinazione delle regole Un set di policy Obblighi E’ importante che non siano presenti dei conflitti tra le policy presenti in un Policy. Set, pena il fallimento della valutazione da parte del PDP • Nel markup è rappresentato dall’elemento <Policy. Set>, elemento che può essere la root di un documento XACML

Considerazione sul Target E’ importante sapere che il Target è ciò che conta nella valutazione di una Polcy (Rule e/o Policy. Set), per cui bisogna utilizzarlo il più possibile senza lasciare dei campi vuoti. In questo modo la valutazione del PDP nel risulta accelerata, nel caso il target match di una policy fallisca si passa direttamente all’elemento successivo, senza valutare Rules e/o Conditions.

Algoritmi di combinazione Sono algoritmi utilizzati per riconciliare decisioni che regole o politiche individuali prendono all’interno di policy o policy set. • Esistono algoritmi di combinazione sia per policy che per regole. • Esempi di algoritmi di combinazione standard sono: Deny-overrides, Permit-overrides, First applicable, Only-one-applicable. • XACML permette inoltre di definire algoritmi di combinazione personalizzati.

Algoritmi di combinazione �Permit-Overrides � Nell’insieme di regole presenti in una policy, se solamente una regola ha come effetto “Permit”, il risultato della combinazione delle regole deve essere “Permit”. � Se invece, nessuna regola ha come effetto “Deny”, e tutte le altre hanno “Not. Applicable”, la combinazione dovrà essere “Deny”. � L’effetto “Permit” ha la precendeza senza riguardo ai risultati delle valutazioni di tutte le altre regole della policy. � Se si riscontra un errore durante la valutazione della condizione di una regola che ha come effetto “Permit”, la valutazione continua fino alla prossima regola con effetto “Permit”, se non la si trova l’intera policy risulterà con effetto “Indeterminate”, con allegato l’appropriato messaggio d’errore. � Gli stessi discorsi valgono nei confronti di un Policy. Set e le singole Policy appartenenti.

Algoritmi di combinazione �Deny-Overrides � Nell’insieme di regole presenti in una policy, se solamente una regola ha come effetto “Deny”, il risultato della combinazione delle regole deve essere “Deny”. � Se invece, nessuna regola ha come effetto “Permit”, e tutte le altre hanno “Not. Applicable”, la combinazione dovrà essere “Permit”. � L’effetto “Deny” ha la precendeza senza riguardo ai risultati delle valutazioni di tutte le altre regole della policy. � Se si riscontra un errore durante la valutazione della condizione di una regola che ha come effetto “Deny”, la valutazione continua fino alla prossima regola con effetto “Deny”, se non la si trova l’intera policy risulterà con effetto “Indeterminate”, con allegato l’appropriato messaggio d’errore. � Gli stessi discorsi valgono nei confronti di un Policy. Set e le singole Policy appartenenti

Algoritmi di combinazione �Ordered-Deny-Overrides �Il comportamento di questo algoritmo è lo stesso del Deny-Overrides, ma con una eccezione: � L’ordine in cui la collezione di regole viene valutata deve rispecchiare l’ordine di tale collezione deciso all’interno della policy (o di un Policy. Set). �Orderd-Permit-Overrides �Il comportamento di questo algoritmo è lo stesso del Permit-Overrides, ma con una eccezione: � L’ordine in cui la collezione di regole viene valutata deve rispecchiare l’ordine di tale collezione deciso all’interno della policy (o di un Policy. Set).

Algoritmi di combinazione �First-Applicable �Ogni regola va valutata nello stesso ordine in cui si presenta all’interno della policy. �Se, il target di una particolare regola è abbinato a quello della richiesta e la condizione sia valutata a true, allora la valutazione dell’intera policy sarà definita dal valore della condizione della regola sopra citata (Es: “True” “Permit” e “False” “Deny”)

Algoritmi di combinazione �Only-One-Applicable �Nell’intero insieme di Policy in un Policy. Set, se nessuna di queste è considerata applicabile, allora il risultato della combinazione di policy per l’intero Policy. Set sarà “Not. Applicable”. �Se più di una di queste policy è considerata applicabile, allora il risultato della combinazione di policy per l’intero Policy. Set sarà “Indeterminate” �Se solo una di queste policy è considerata applicabile, allora il risultato della valutazione del Policy. Set, sarà lo stesso della valutazione della singola policy.

Documenti XACML Come detto, XACML definisce due linguaggi, che come tali, danno vita a due tipi di documenti diversi: • Documenti XACML per le politiche di sicurezza (definiti dal linguaggio di Policy) • Documenti XACML per il contesto di richiesta e di risposta (definiti dal linguaggio per gestire gli accessi alle risorse)

Struttura di un documento XACML (per le politiche di sicurezza) � La struttura di un documento XACML standard, per la descrizione di politiche di sicurezza, ha sempre come elementi di root: � L’elemento <Policy. Set> contenitore di singole policy o di altri policy set. <xs: element name="Policy. Set" type="xacml: Policy. Set. Type"/> <xs: complex. Type name="Policy. Set. Type"> <xs: sequence> <xs: element ref="xacml: Description" min. Occurs="0"/> <xs: element ref="xacml: Policy. Set. Defaults" min. Occurs="0"/> <xs: element ref="xacml: Target"/> <xs: choice min. Occurs="0" max. Occurs="unbounded"> <xs: element ref="xacml: Policy. Set"/> <xs: element ref="xacml: Policy. Set. Id. Reference"/> <xs: element ref="xacml: Policy. Id. Reference"/> <xs: element ref="xacml: Combiner. Parameters"/> <xs: element ref="xacml: Policy. Set. Combiner. Parameters"/> </xs: choice> <xs: element ref="xacml: Obligations" min. Occurs="0"/> </xs: sequence> <xs: attribute name="Policy. Set. Id" type="xs: any. URI" use="required"/> <xs: attribute name="Version" type="xacml: Version. Type" default="1. 0"/> <xs: attribute name="Policy. Combining. Alg. Id" type="xs: any. URI" use="required"/> </xs: complex. Type>

L’elemeto <Policy. Set>

L’elemento <Policy> • L’elemento <Policy> che rappresenta una singola politica di controllo degli accessi, espressa attraverso una serie di regole <xs: element name="Policy" type="xacml: Policy. Type"/> <xs: complex. Type name="Policy. Type"> <xs: sequence> <xs: element ref="xacml: Description" min. Occurs="0"/> <xs: element ref="xacml: Policy. Defaults" min. Occurs="0"/> <xs: element ref="xacml: Combiner. Parameters" min. Occurs="0"/> <xs: element ref="xacml: Target"/> <xs: choice max. Occurs="unbounded"> <xs: element ref="xacml: Combiner. Parameters" min. Occurs="0"/> <xs: element ref="xacml: Rule. Combiner. Parameters" min. Occurs="0"/> <xs: element ref="xacml: Variable. Definition"/> <xs: element ref="xacml: Rule"/> </xs: choice> <xs: element ref="xacml: Obligations" min. Occurs="0"/> </xs: sequence> <xs: attribute name="Policy. Id" type="xs: any. URI" use="required"/> <xs: attribute name="Version" type="xacml: Version. Type" default="1. 0"/> <xs: attribute name="Rule. Combining. Alg. Id" type="xs: any. URI" use="required"/> </xs: complex. Type>

L’elemento <Rule>, figlio dell’elemento <Policy>, definirà le singole regole nella politica. E’ il cuore di una policy. <xs: element name="Rule" type="xacml: Rule. Type"/> <xs: complex. Type name="Rule. Type"> <xs: sequence> <xs: element ref="xacml: Description" min. Occurs="0"/> <xs: element ref="xacml: Target" min. Occurs="0"/> <xs: element ref="xacml: Condition" min. Occurs="0"/> </xs: sequence> <xs: attribute name="Rule. Id" type="xs: string" use="required"/> <xs: attribute name="Effect" type="xacml: Effect. Type" use="required"/> </xs: complex. Type>

L’elemento <Target> Un Target è fondamentalmente un’insieme di condizioni semplificate per il soggetto, la risorsa o l’azione che sono venuti in contatto con un Policy. Set, una Policy o una regola; condizioni che vengono poi applicate alla richiesta. L’elemento <Target> non è utilizzato solamente per controllare l’applicabilità della richiesta, ma provvedere anche ad indicizzare le varie policy. <xs: element name="Target" type="xacml: Target. Type"/> <xs: complex. Type name="Target. Type"> <xs: sequence> <xs: element ref="xacml: Subjects" min. Occurs="0"/> <xs: element ref="xacml: Resources" min. Occurs="0"/> <xs: element ref="xacml: Actions" min. Occurs="0"/> <xs: element ref="xacml: Environments" min. Occurs="0"/> </xs: sequence> </xs: complex. Type>

Gli elementi <Subjects> e <Subject> L’elemento <Subject> può contenere: • L’elenco degli attributi legati al soggetto corrente (se relativo al contesto di richiesta) <xs: element name="Subject" type="xacml-context: Subject. Type"/> <xs: complex. Type name="Subject. Type"> <xs: sequence> <xs: element ref="xacml-context: Attribute" min. Occurs="0” max. Occurs="unbounded"/> </xs: sequence> <xs: attribute name="Subject. Category" type="xs: any. URI” default="urn: oasis: names: tc: xacml: 1. 0: subject-category: access-subject"/> </xs: complex. Type> • Una o più regole di match di valori di soggetto, risorsa, azione o ambiente (se relativo ad una singola regola) <xs: element name="Subject" type="xacml: Subject. Type"/> <xs: complex. Type name="Subject. Type"> <xs: sequence> <xs: element ref="xacml: Subject. Match" max. Occurs="unbounded"/> </xs: sequence> </xs: complex. Type> L’elemento <Subjects> non è altro che una collezione di uno o più soggetti.

Esempio Simple. Policy 1. xml

Struttura di un documento XACML (per il contesto di richiesta) Questi documenti rappresentano un’ipotetica richiesta che può essere sottomessa al PDP, sulla quale vengono poi definite una o più policy. Queste informazioni di richiesta vengono rappresentate attraverso un “contesto di richiesta”. Il documento XACML che definisce questo contesto, deve avere come root l’elemento <Request>, che rappresenta la richiesta alla risorsa.

L’elemento <Request> (1) L’elemento <Request> è uno strato di astrazione utilizzato dal linguaggio di policy, in quanto ad un PDP conforme, non è necessario istanziare realmente il contesto di richiesta sottoforma di documento XML. Tutti i sistemi però, che si attengono alle specifiche XACML, devono produrre esattamente le stesse decisioni di autorizzazione come se tutti gli input siano trasformati nella forma di un elemento <Request>.

L’elemento <Request> (2) Questo elemento contiene le specifiche per i soggetti, le risorse, l’azione e l’ambiente specificati all’interno del contesto di richiesta. <xs: element name="Request" type="xacml-context: Request. Type"/> <xs: complex. Type name="Request. Type"> <xs: sequence> <xs: element ref="xacml-context: Subject" max. Occurs="unbounded"/> <xs: element ref="xacml-context: Resource" max. Occurs="unbounded"/> <xs: element ref="xacml-context: Action"/> <xs: element ref="xacml-context: Environment"/> </xs: sequence> </xs: complex. Type>

L’elemento <Resource> L'elemento <Resource> specifica le informazioni sulla risorsa alla quale è stato richiesto l'accesso, elencando una sequenza di elementi <Attribute> connessi alla risorsa. Questo elemento può includere il contenuto della risorsa <xs: element name="Resource" type="xacml-context: Resource. Type"/> <xs: complex. Type name="Resource. Type"> <xs: sequence> <xs: element ref="xacml-context: Resource. Content" min. Occurs="0"/> <xs: element ref="xacml-context: Attribute" min. Occurs="0" max. Occurs="unbounded"/> </xs: sequence> </xs: complex. Type>

L’elemento <Action> L'elemento <Action> specifica l'azione chiesta sulla risorsa, elencando un insieme di elementi <Attribute> connessi con l'azione. <xs: element name="Action" type="xacml-context: Action. Type"/> <xs: complex. Type name="Action. Type"> <xs: sequence> <xs: element ref="xacml-context: Attribute" min. Occurs="0" max. Occurs="unbounded"/> </xs: sequence> </xs: complex. Type>

L’elemento <Environment> rappresenta un insieme di attributi relativi all’ambiente legato alla richiesta effettuata <xs: element name="Environment" type="xacml-context: Environment. Type"/> <xs: complex. Type name="Environment. Type"> <xs: sequence> <xs: element ref="xacml-context: Attribute" min. Occurs="0" max. Occurs="unbounded"/> </xs: sequence> </xs: complex. Type>

L’elemento <Attribute> è l’astrazione centrale del contesto di richiesta; questo contiene meta dati e uno o più valori di attributi. I meta dati di ogni attributo contengono: • Il contrassegno di tale attributo • Il mittente di tale atributo Gli elementi <Attribute. Selector> e <Attribute. Designator> nella politica possono riferirsi agli attributi per mezzo di questi meta dati. <xs: element name="Attribute" type="xacml-context: Attribute. Type"/> <xs: complex. Type name="Attribute. Type"> <xs: sequence> <xs: element ref="xacml-context: Attribute. Value" max. Occurs="unbounded"/> </xs: sequence> <xs: attribute name="Attribute. Id" type="xs: any. URI" use="required"/> <xs: attribute name="Data. Type" type="xs: any. URI" use="required"/> <xs: attribute name="Issuer" type="xs: string" use="optional"/> </xs: complex. Type>

Esempio Simple. Request. xml

Struttura di un documento XACML (per il contesto di risposta) Una volta che il richiedente effettua una richiesta per eseguite un’azione su di una particolare risorsa, e una volta che a questa richiesta vengono applicate delle policy dal PDP, il Context Handler deve produrre una risposta adeguata per il richiedente. Anche la risposta è definita attraverso un documento XACML, composto dagli elementi del namespace per il contesto di richiesta (xacml: context).

L’elemento <Response> (1) L’elemento <Response> è l’elemento di root per i documenti che rappresentano il contesto di risposta. Anch’esso definisce un livello di astrazione per il sistema di autorizzazioni che tutti gli applicativi che rispettano le specifiche fornite da XACML devono implementare, in quanto esso deve essere trasformato nella forma di una decisione di autorizzazione corretta.

L’elemento <Response> (2) Questo elemento incapsula la decisione di autorizzazione prodotta dal PDP. Inoltre contiene un elenco di uno o più risultati per quante sono state le richieste pervenute. N. B. : l’implementazione della gestione di multi-risorse è facoltativa <xs: element name="Response" type="xacml-context: Response. Type"/> <xs: complex. Type name="Response. Type"> <xs: sequence> <xs: element ref="xacml-context: Result" max. Occurs="unbounded"/> </xs: sequence> </xs: complex. Type>

L’elemento <Result> rappresenta un’unica decisione di autorizzazione per l’accesso alla risorsa specificata nell’attributo Resource. Id. Un risultato può includere una serie di obblighi che devono essere rispettati dal PEP. Se il PEP non capisce o non può rispettare un obbligo deve comportarsi come se il PDP abbia negato l'accesso alla risorsa chiesta. <xs: complex. Type name="Result. Type"> <xs: sequence> <xs: element ref="xacml-context: Decision"/> <xs: element ref="xacml-context: Status" min. Occurs="0"/> <xs: element ref="xacml: Obligations" min. Occurs="0"/> </xs: sequence> <xs: attribute name="Resource. Id" type="xs: string" use="optional"/> </xs: complex. Type>

L’elemento <Decision> contiene il risultato dell’applicazione della policy sulla richiesta. I valori permessi per quest elemento sono: • Permit – l’accesso richiesto è permesso • Deny – l’accesso richiesto è negato • Indeterminate – il PDP non è stato in grado di valutare la richiesta di accesso • Not. Applicable – il PDP non ha nessuna policy da applicare alla richiesta di accesso <xs: element name="Decision" type="xacml-context: Decision. Type"/> <xs: simple. Type name="Decision. Type"> <xs: restriction base="xs: string"> <xs: enumeration value="Permit"/> <xs: enumeration value="Deny"/> <xs: enumeration value="Indeterminate"/> <xs: enumeration value="Not. Applicable"/> </xs: restriction> </xs: simple. Type>

L’elemento <Status> rappresenta lo stato del risultato della decisione di autorizzazione. Al suo interno ha: • Un codice di stato • Un messaggio di stato • I dettagli di stato <xs: element name="Status" type="xacml-context: Status. Type"/> <xs: complex. Type name="Status. Type"> <xs: sequence> <xs: element ref="xacml-context: Status. Code"/> <xs: element ref="xacml-context: Status. Message" min. Occurs="0"/> <xs: element ref="xacml-context: Status. Detail" min. Occurs="0"/> </xs: sequence> </xs: complex. Type>

Esempio Simple. Response. xml

Tipi di dati � Tipi di dati definiti dalle specifiche XACML: � � urn: oasis: names: tc: xacml: 1. 0: data-type: x 500 Name. urn: oasis: names: tc: xacml: 1. 0: data-type: rfc 822 Name urn: oasis: names: tc: xacml: 2. 0: data-type: ip. Address urn: oasis: names: tc: xacml: 2. 0: data-type: dns. Name � Tipi di dati definiti dalle specifiche di XML Schema: � � � � � http: //www. w 3. org/2001/XMLSchema#string http: //www. w 3. org/2001/XMLSchema#boolean http: //www. w 3. org/2001/XMLSchema#integer http: //www. w 3. org/2001/XMLSchema#double http: //www. w 3. org/2001/XMLSchema#time http: //www. w 3. org/2001/XMLSchema#date. Time http: //www. w 3. org/2001/XMLSchema#any. URI http: //www. w 3. org/2001/XMLSchema#hex. Binary http: //www. w 3. org/2001/XMLSchema#base 64 Binary � Tipi di dati per la specifica del tempo: � http: //www. w 3. org/TR/2002/WD-xquery-operators-20020816#day. Time. Duration � http: //www. w 3. org/TR/2002/WD-xquery-operators-20020816#year. Month. Duration

XACML extensibility points XACML essendo figlio di XML, ha vari punti di estensione: • Tipi di attributi in quanto esistono degli attributi (Attribute. Id, Data. Type, Function. Id, Match. Id, Obligation. Id, Policy. Combining. Alg. Id, Rule. Combining. Alg. Id, Status. Code, Subject. Category) che hanno delle URI come valori, attributi che possono essere estesi creando nuove URI che rappresentano nuove semantiche. • Attributi strutturati in quanto gli elemtni <xacml: Attribute. Value> e <xacmlcontext: Attribute. Value> possono contenere istanze di tipi di dati XML strutturati

Considerazioni sulla sicurezza Quando si decide di implementare un sistema basato su XACML, bisogna tener conto di alcuni scenari di compromissione della privacy e della sicurezza. I possibili scenari sono due: • Modello di minaccia (Threat model) • Rilevazione non autorizzata

Considerazioni sulla sicurezza Threat model Si assume di avere un “avversario” che si pone nel canale di comunicazione tra i vari attori XACML e che abbia la possibilità di interpretare, inserire, eliminare e modificare i messaggi in transito sul canale o parti di essi. Altri punti di vulnerabilità possono così crearsi in altre entità del sistema, come il PEP, il PDP e il PAP. Vulnerabilità che può quindi compromettre i controlli sugli accessi richiesti.

Considerazioni sulla sicurezza Rilevazione non autorizzata XACML non ha definito alcun meccanismo da ereditare per proteggere le informazioni dei messaggi scambiati tra i vari attori della comunicazione. Di conseguenza, un “avversario” può osservare il contenuto di questi messaggi e violarne quindi la privacy a discapito della sicurezza dell’interno sistema

Implementazioni � Sun’s XACML implementation http: //sunxacml. sourceforge. net � Parthenon XACML Evaluation Engine http: //www. parthenoncomputing. com � XACML. NET http: //mvpos. sourceforge. net � AXESCON XACML 2. 0 Engine (Beta version) http: //axescon. com/ax 2 e � Swedish Institute of Computer Science: XACML 3. 0 Administrative Policy support (Beta version) http: //www. sics. se/spot/xacml_3_0. html � University of Murcia (UMU), Spain: Java-based XACML editor http: //xacml. dif. um. es/ � Brown University, US: Margrave, XACML policy verification and change analysis tool http: //www. cs. brown. edu/research/plt/software/margrave/ � UMU NAS-SAML XACML policy infopath templates http: //libra. dif. um. es/~gabilm/designs/nas_saml/

Conlcusioni Il controllo degli accessi a risorse è uno di quei campi di studio applicati in un gran numero di applicazioni, sia grandi che piccole. XACML tenta di definire degli standard per questo campo, in modo tale che una volta messo in piedi il sistema con tutte le sue entità (PEP, PDP, ecc. . ), risulti facile ed intuitivo costruire delle politiche di sicurezza per la protezione delle più svariate risorse poste in sistemi differenti.

THE END http: //www. peppedotnet. it