Marchi GiuseppeMiro Radenovic

Acronimo di: eXtensible 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:xacml-context=“urn:oasis:names:tc:xacml:2.0:context:schema:os”)

Entrambi i linguaggi sono derivati dall’XML.

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.

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

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.

E’ quell’entità di sistema che effettua il controllosugli accessi, facendo richieste di decisione efacendo rispettare le decisioni di autorizzazione.

Livello logico che protegge la risorsa richiesta (posta su file system distribuito o web server chesia)

Il PEP DEVE attenersi alla decisione di autorizzazione

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.

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

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.

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

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

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

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.

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

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>

Il target definisce un set di: Risorse Soggetti Azioni Ambienti

Ai quali la regola deve essere applicata

• Nel markup, è rappresentato dall’elemento <Target>

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

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.Indeterminate segnala una condizione di errore interna al PDP.Nel caso in cui la condition restituisca False, la regola sarà NotApplicable

Nel markup è rappresentata dall’elemento <Condition>, figlio dell’elemento <Rule>

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>

Esattamente come per le regole, il target definisce un set di: Risorse Soggetti Azioni Ambienti

Ai quali la policy corrente dev’essere applicata

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

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>

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 PolicySet, pena il fallimento della valutazione da parte del PDP

• Nel markup è rappresentato dall’elemento <PolicySet>, elemento che può essere la root di un documento XACML

E’ importante sapere che il Target è ciò che conta nella valutazione di una Polcy (Rule e/o PolicySet), 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.

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.

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 “NotApplicable”, 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 PolicySet e le singole Policy appartenenti.

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 “NotApplicable”, 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 PolicySet e le singole Policy appartenenti

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 PolicySet).

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 PolicySet).

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”)

Only-One-Applicable Nell’intero insieme di Policy in un PolicySet, se

nessuna di queste è considerata applicabile, allora il risultato della combinazione di policy per l’intero PolicySet sarà “NotApplicable”.

Se più di una di queste policy è considerata applicabile, allora il risultato della combinazione di policy per l’intero PolicySet sarà “Indeterminate”

Se solo una di queste policy è considerata applicabile, allora il risultato della valutazione del PolicySet, sarà lo stesso della valutazione della singola policy.

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)

La struttura di un documento XACML standard, per la descrizione di politiche di sicurezza, ha sempre come elementi di root:

L’elemento <PolicySet>contenitore di singole policy o di altri policy set. <xs:element name="PolicySet" type="xacml:PolicySetType"/>

<xs:complexType name="PolicySetType"><xs:sequence>

<xs:element ref="xacml:Description" minOccurs="0"/><xs:element ref="xacml:PolicySetDefaults" minOccurs="0"/>

<xs:element ref="xacml:Target"/><xs:choice minOccurs="0" maxOccurs="unbounded">

<xs:element ref="xacml:PolicySet"/> <xs:element ref="xacml:Policy"/>

<xs:element ref="xacml:PolicySetIdReference"/><xs:element ref="xacml:PolicyIdReference"/>

<xs:element ref="xacml:CombinerParameters"/><xs:element ref="xacml:PolicyCombinerParameters"/><xs:element ref="xacml:PolicySetCombinerParameters"/>

</xs:choice> <xs:element ref="xacml:Obligations" minOccurs="0"/>

</xs:sequence><xs:attribute name="PolicySetId" type="xs:anyURI" use="required"/><xs:attribute name="Version" type="xacml:VersionType" default="1.0"/><xs:attribute name="PolicyCombiningAlgId" type="xs:anyURI" use="required"/></xs:complexType>

• L’elemento <Policy>che rappresenta una singola politica di controllo degli accessi, espressa attraverso una serie di regole

<xs:element name="Policy" type="xacml:PolicyType"/><xs:complexType name="PolicyType"> <xs:sequence> <xs:element ref="xacml:Description" minOccurs="0"/>

<xs:element ref="xacml:PolicyDefaults" minOccurs="0"/> <xs:element ref="xacml:CombinerParameters" minOccurs="0"/> <xs:element ref="xacml:Target"/> <xs:choice maxOccurs="unbounded"> <xs:element ref="xacml:CombinerParameters" minOccurs="0"/> <xs:element ref="xacml:RuleCombinerParameters" minOccurs="0"/> <xs:element ref="xacml:VariableDefinition"/> <xs:element ref="xacml:Rule"/> </xs:choice> <xs:element ref="xacml:Obligations" minOccurs="0"/> </xs:sequence> <xs:attribute name="PolicyId" type="xs:anyURI" use="required"/> <xs:attribute name="Version" type="xacml:VersionType" default="1.0"/> <xs:attribute name="RuleCombiningAlgId" type="xs:anyURI" use="required"/></xs:complexType>

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:RuleType"/> <xs:complexType name="RuleType"> <xs:sequence>

<xs:element ref="xacml:Description" minOccurs="0"/> <xs:element ref="xacml:Target" minOccurs="0"/> <xs:element ref="xacml:Condition" minOccurs="0"/> </xs:sequence> <xs:attribute name="RuleId" type="xs:string" use="required"/> <xs:attribute name="Effect" type="xacml:EffectType" use="required"/> </xs:complexType>

Un Target è fondamentalmente un’insieme di condizioni semplificate per il soggetto, la risorsa o l’azione che sono venuti in contatto con un PolicySet, 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:TargetType"/><xs:complexType name="TargetType">

<xs:sequence> <xs:element ref="xacml:Subjects" minOccurs="0"/> <xs:element ref="xacml:Resources" minOccurs="0"/> <xs:element ref="xacml:Actions" minOccurs="0"/> <xs:element ref="xacml:Environments" minOccurs="0"/></xs:sequence>

</xs:complexType>

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:SubjectType"/><xs:complexType name="SubjectType"> <xs:sequence> <xs:element ref="xacml-context:Attribute" minOccurs="0” maxOccurs="unbounded"/> </xs:sequence> <xs:attribute name="SubjectCategory" type="xs:anyURI” default="urn:oasis:names:tc:xacml:1.0:subject-category:access-subject"/>

</xs:complexType>

• 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:SubjectType"/><xs:complexType name="SubjectType"> <xs:sequence> <xs:element ref="xacml:SubjectMatch" maxOccurs="unbounded"/> </xs:sequence>

</xs:complexType>

L’elemento <Subjects> non è altro che una collezione di uno o più soggetti.

SimplePolicy1.xml

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> è 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>.

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:RequestType"/><xs:complexType name="RequestType"> <xs:sequence> <xs:element ref="xacml-context:Subject" maxOccurs="unbounded"/> <xs:element ref="xacml-context:Resource" maxOccurs="unbounded"/> <xs:element ref="xacml-context:Action"/> <xs:element ref="xacml-context:Environment"/> </xs:sequence></xs:complexType>

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:ResourceType"/><xs:complexType name="ResourceType"> <xs:sequence> <xs:element ref="xacml-context:ResourceContent" minOccurs="0"/> <xs:element ref="xacml-context:Attribute" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence></xs:complexType>

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:ActionType"/><xs:complexType name="ActionType"> <xs:sequence> <xs:element ref="xacml-context:Attribute" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence></xs:complexType>

L’elemento <Environment> rappresenta un insieme di attributi relativi all’ambiente legato alla richiesta effettuata

<xs:element name="Environment" type="xacml-context:EnvironmentType"/><xs:complexType name="EnvironmentType"> <xs:sequence> <xs:element ref="xacml-context:Attribute" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence></xs:complexType>

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 <AttributeSelector> e <AttributeDesignator> nella politica possono riferirsi agli attributi per mezzo di questi meta dati.

<xs:element name="Attribute" type="xacml-context:AttributeType"/><xs:complexType name="AttributeType"> <xs:sequence> <xs:element ref="xacml-context:AttributeValue" maxOccurs="unbounded"/> </xs:sequence> <xs:attribute name="AttributeId" type="xs:anyURI" use="required"/> <xs:attribute name="DataType" type="xs:anyURI" use="required"/> <xs:attribute name="Issuer" type="xs:string" use="optional"/></xs:complexType>

SimpleRequest.xml

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> è 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.

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:ResponseType"/><xs:complexType name="ResponseType"> <xs:sequence> <xs:element ref="xacml-context:Result" maxOccurs="unbounded"/> </xs:sequence></xs:complexType>

L’elemento <Result> rappresenta un’unica decisione di autorizzazione per l’accesso alla risorsa specificata nell’attributo ResourceId.

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:complexType name="ResultType"> <xs:sequence> <xs:element ref="xacml-context:Decision"/> <xs:element ref="xacml-context:Status" minOccurs="0"/> <xs:element ref="xacml:Obligations" minOccurs="0"/> </xs:sequence> <xs:attribute name="ResourceId" type="xs:string" use="optional"/></xs:complexType>

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• NotApplicable – il PDP non ha nessuna policy da applicare alla

richiesta di accesso

<xs:element name="Decision" type="xacml-context:DecisionType"/><xs:simpleType name="DecisionType"> <xs:restriction base="xs:string"> <xs:enumeration value="Permit"/> <xs:enumeration value="Deny"/> <xs:enumeration value="Indeterminate"/> <xs:enumeration value="NotApplicable"/> </xs:restriction></xs:simpleType>

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:StatusType"/><xs:complexType name="StatusType"> <xs:sequence> <xs:element ref="xacml-context:StatusCode"/> <xs:element ref="xacml-context:StatusMessage" minOccurs="0"/> <xs:element ref="xacml-context:StatusDetail" minOccurs="0"/> </xs:sequence></xs:complexType>

SimpleResponse.xml

Tipi di dati definiti dalle specifiche XACML: urn:oasis:names:tc:xacml:1.0:data-type:x500Name. urn:oasis:names:tc:xacml:1.0:data-type:rfc822Name urn:oasis:names:tc:xacml:2.0:data-type:ipAddress urn:oasis:names:tc:xacml:2.0:data-type:dnsName

Tipi di dati definiti dalle specifiche di XML Schema: http://www.w3.org/2001/XMLSchema#string http://www.w3.org/2001/XMLSchema#boolean http://www.w3.org/2001/XMLSchema#integer http://www.w3.org/2001/XMLSchema#double http://www.w3.org/2001/XMLSchema#time http://www.w3.org/2001/XMLSchema#date http://www.w3.org/2001/XMLSchema#dateTime http://www.w3.org/2001/XMLSchema#anyURI http://www.w3.org/2001/XMLSchema#hexBinary http://www.w3.org/2001/XMLSchema#base64Binary

Tipi di dati per la specifica del tempo: http://www.w3.org/TR/2002/WD-xquery-operators-20020816#dayTimeDuration http://www.w3.org/TR/2002/WD-xquery-operators-20020816#yearMonthDuration

XACML essendo figlio di XML, ha vari punti di estensione:• Tipi di attributi

in quanto esistono degli attributi (AttributeId, DataType, FunctionId, MatchId, ObligationId, PolicyCombiningAlgId, RuleCombiningAlgId, StatusCode, SubjectCategory) che hanno delle URI come valori, attributi che possono essere estesi creando nuove URI che rappresentano nuove semantiche.

• Attributi strutturatiin quanto gli elemtni <xacml:AttributeValue> e <xacml-context:AttributeValue> possono contenere istanze di tipi di dati XML strutturati

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

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.

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

Sun’s XACML implementationhttp://sunxacml.sourceforge.net

Parthenon XACML Evaluation Enginehttp://www.parthenoncomputing.com

XACML.NEThttp://mvpos.sourceforge.net

AXESCON XACML 2.0 Engine (Beta version)http://axescon.com/ax2e

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 editorhttp://xacml.dif.um.es/

Brown University, US: Margrave, XACML policy verification and change analysis toolhttp://www.cs.brown.edu/research/plt/software/margrave/

UMU NAS-SAML XACML policy infopath templateshttp://libra.dif.um.es/~gabilm/designs/nas_saml/

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.

http://www.peppedotnet.it