Maurizio Argoneto
 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:xacmlcontext=“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.
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
 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.
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
 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
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
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>
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 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
Considerazione sul Target
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.
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 “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.
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 “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
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 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).
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 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.
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 <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’elemeto <PolicySet>
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: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>
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>
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
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>
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: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.
Esempio
SimplePolicy1.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: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>
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>
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>
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’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>
Esempio
SimpleRequest.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:ResponseType"/>
<xs:complexType name="ResponseType">
<xs:sequence>
<xs:element ref="xacml-context:Result" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
L’elemento <Result>
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>
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>
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>
Esempio
SimpleResponse.xml
Tipi di dati
 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 extensibility points
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 strutturati
in quanto gli elemtni <xacml:AttributeValue> e <xacmlcontext:AttributeValue> 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/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 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