1. Introduction to XACML Informative presentation to LegalRuleML TC 2012-02-15 by Paul Tyson Slide 1

2. XACML ● XACML purpose and scope ● Policy language basics ● Notional architecture ● XACML and semantic web technologies ● Strengths and weaknesses of XACML ● XACML and LegalRuleML Slide 2

3. XACML purpose ● eXtensible Access Control Markup Language ● Designed for representing and enforcing authorization policies; i.e., making Permit/Deny decisions for – a particular subject (person, principal, agent, etc.) – performing a particular action – on, with, or to a particular resource (document, file, device, web page, physical artifact, etc.) Slide 3

4. XACML rules ● Consequents are either “Permit” or “Deny” (specified in the policy language and constrained by the schema) – To accommodate incomplete information and processing errors, run-time consequents “Not Applicable” and “Indeterminate” are specified in the evaluation procedure. ● Antecedents are formed of predicates that test attribute values describing the subject, action, and resource of a XACML Request. Slide 4

5. Combining algorithms ● Rules are contained in Policies. ● Rule combining algorithms are specified at the policy level to resolve conflicts when multiple rules are found applicable during evaluation. ● Policies may be contained in Policy Sets. ● Policy combining algorithms are specified at the policy set level to resolve conflicts. Slide 5

6. Combining algorithms (cont.) ● Common combining algorithms – first-applicable – deny-overrides – permit-overrides – ordered-deny-overrides – ordered-permit-overrides – deny-unless-permit – permit-unless-deny ● Custom combining algorithms may be implemented Slide 6

7. XACML policy structure ● PolicySet ? – @PolicySetId – @PolicyCombiningAlgId – PolicySet? – Policy ● @PolicyId ● @RuleCombiningAlgId ● Rule – @RuleId – @Effect – Target ? – Condition ? Slide 7

8. Target element ● Target – AnyOf + ● AllOf + – Match + ● @MatchId ● is a conjunctive list of ● and represent disjunctive and conjunctive lists, respectively ● is a Boolean-valued binary predicate indicated by @MatchId Slide 8

9. Target example: resources under ITAR jurisdiction ITAR <AttributeDesignator Category=”resource” DataType=”string” AttributeId=”jurisdiction” MustBePresent=”false”/> Slide 9

10. Condition element ● Condition – Apply ● @FunctionId ● has 1 child, which must specify a Boolean-valued function. ● Conditions are used to apply arbitrary tests on attribute values in the request context. ● Example: “Subject is not a US person or is not in the US.” Slide 10

11. Condition example: non-US person or location false <AttributeDesignator Category=”subject” DataType=”boolean” AttributeId=”us-person” MustBePresent=”false”/> US <AttributeDesignator Category=”subject” DataType=”string” AttributeId=”location” MustBePresent=”false”/> Slide 11

12. Points to note about Condition ● elements are functional language s-expressions ● is a typed literal ● returns a bag of typed values from the request context ● Equivalent logical constructions could be used – For clarity, or for stylistic reasons – To match the natural-language rule wording – For more fail-safe results in abnormal evaluation (e.g. missing attributes) Slide 12

13. Policy example: basic US ITAR <Policy PolicyId=”us-itar” RuleCombiningAlgId=”first-applicable”> US International Traffic in Arms Regulations (ITAR) policy. <!-- as shown previously: resources that fall under ITAR jurisdiction, i.e. jurisdiction=”ITAR” --> ITAR resources are not allowed to non-US Persons, nor outside of the US. <!-- No Target required at this level; it is inherited from ancestor Target elements --> <!-- as shown previously: subjects who are not US persons or are outside the US --> Slide 13

14. Policy evaluation ● Policy is evaluated for a specific request context containing subject, action, and resource attributes. ● For policies and policy sets, the Target determines applicability. ● Rule evaluation: – First the target (if none, treat as empty conjunctive list, or true) – If target is applicable, evaluate the condition; if true, rule's “Effect” attribute value is considered by the rule- combining algorithm. Slide 14

15. Obligation and Advice ● An Obligation is a normative addendum to an authorization decision: if the client does not recognize or cannot fulfill the obligation, it must not act on the decision. ● An Advice is an informative addendum: the client is free to use or ignore it while acting on the given authorization decision. Slide 15

16. Obligation and Advice (cont.) ● Written as expressions in Rules, Policies, or PolicySets. ● Apply to “Permit” or “Deny” decisions – Due to syntactic oddity, cannot specify an Obligation/Advice to apply to both types of decisions ● Each applicable Obligation/Advice expression is evaluated to return a single Obligation/Advice element with an ID and zero or more attributes. Slide 16

17. Obligation and Advice (cont.) ● Obligation/Advice can accumulate through policy tree evaluation ● Due to combinatorial possibilities of policy tree evaluation with various combining algorithms, confusing or conflicting obligations may be returned. The XACML spec recognizes the possibility of ambiguity but does not provide any means to avoid or resolve it. Slide 17

18. Obligation example ● ITAR resources may be exported in specific situations if approved in advance by the US State Department. ● All ITAR exports must be logged with details about the date and place of export, the items exported, the persons and countries involved, and the authorization for export. Slide 18

19. Obligation example (Policy) <AttributeDesignator Category=”subject” DataType=”string” AttributeId=”subject-id” MustBePresent=”false”/> <AttributeDesignator Category=”subject” DataType=”string” AttributeId=”location” MustBePresent=”false”/> TAA-123456 Slide 19

20. Obligation example (Response) Permit John Doe CA TAA-123456 Slide 20

21. Miscellaneous syntactic features ● PolicyIdReference, PolicySetIdReference ● VariableDefinition, VariableReference ● Content element, AttributeSelector Slide 21

22. Notional architecture ● XACML adopted a notional architecture from earlier access control models. ● Logical modules of the architecture – PAP, Policy Administration Point ● Policy repository – PDP, Policy Decision Point ● obtains applicable policies from PAP to evaluate requests from PEP – PEP, Policy Enforcement Point ● sends request to PDP, receives decision response – PIP, Policy Information Point ● supplies attribute values to PDP Slide 22

23. Notional architecture (cont.) ● Policies are evaluated with respect to a request context (a set of attributes) ● The initial request context is supplied by the Request instance from the PEP. ● The context handler may add to the request context, either as required by the PDP (during policy evaluation), or by customized behavior. ● Behavior of context handler is not specified by the XACML specification. Slide 23

24. Notional architecture (cont.) ● The distributed architecture is supported by separate top- level syntactic constructs for Policy (or PolicySet), Request, and Response. ● Allows for independent development of components as long as common attribute vocabulary is used – Hint: attribute vocabulary could be expressed as RDF to promote conformance Slide 24

25. XACML and semantic web ● XACML TC has not addressed semantic web compatibility ● Not aware of any research into RDF representations of XACML concepts ● These are just my own unpublished speculations.... Slide 25

26. XACML and semantic web (cont.) ● XACML attributes as RDF properties ● Targets as OWL class definitions – Matches are data property restrictions – Attribute categories represent object property restrictions ● Conditions as rules (RIF, SWRL, RuleML) – alternatively, as further property restrictions ● Policy evaluation as satisfiability of ontology that includes a particular set of subject, action, and resource instances in a Request Slide 26

27. XACML Strengths ● “Business-friendly” – Easy to translate business policies and procedures, laws, regulations into XACML policies – Flexible policy composition to handle both redundant and orthogonal concerns – Subject/Action/Resource attributes focus discussions with stakeholders ● Ready-to-use architecture with straight-forward implementation path ● Commercial vendor support Slide 27

28. XACML weaknesses ● Semantic web compatibility – maybe someday ● Yet-another-rule-language island ● Cannot always flatten a complex set of object relationships into subject/action/resource attributes ● Lack of model-theoretic foundation (more a problem to computer scientists than a practical limitation) Slide 28

29. XACML and LegalRuleML ● True or False? “Anything that can be written in XACML can be written in LegalRuleML.” – If false, is there a gap in LegalRuleML? – If true ● Why do we need 2 standards? ● Is it easier/faster/better to write in one or the other? ● What is the cost of specifying and implementing interoperability (e.g. translators, language profiles)? ● Will the XACML and LegalRuleML communities ever engage in overlapping areas of practice; i.e., is it even necessary to ask these questions? Slide 29