Marchi Giuseppe Miro Radenovic

1. Marchi GiuseppeMiro Radenovic

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

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

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

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

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

8. Il PEP DEVE attenersi alla decisione di autorizzazione

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

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

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

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

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

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

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

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

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

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

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

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

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

27. Esattamente come per le regole, il target definisce un set di: • Risorse • Soggetti • Azioni • Ambienti Ai quali la policy corrente dev’essere applicata

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

45. SimplePolicy1.xml

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

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

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

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

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