XACML OASIS eXtensible Access Control Markup Language

1. XACMLOASIS eXtensible Access Control Markup Language Steve Carmody July 10, 2003

2. Outline • What is the Problem…. • The XACML Model • Some Examples • Implementation Status

3. Authz Landscape Business Systems (HR, Student. Admissions) Assigning Roles Provisioning Attribute Release Policy Store Transport Of Attributes PEP PDP

4. Requirements • To provide a method for combining individual rules and policies into a single policy set that applies to a particular decision request. • To provide a method for flexible definition of the procedure by which rules and policies are combined. • To provide a method for dealing with multiple subjects acting in different capacities. • To provide a method for basing an authorization decision on attributes of the subject and resource. • To provide a method for dealing with multi-valued attributes. • To provide a method for basing an authorization decision on the contents of an information resource. • To provide a set of logical and mathematical operators on attributes of the subject, resource and environment.

5. Requirements • To provide a method for handling a distributed set of policy components, while abstracting the method for locating, retrieving and authenticating the policy components. • To provide a method for rapidly identifying the policy that applies to a given action, based upon the values of attributes of the subjects,resource and action. • To provide an abstraction-layer that insulates the policy-writer from the details of the application environment. • To provide a method for specifying a set of actions that must be performed in conjunction with policy enforcement. • The motivation behind XACML is to express these well-established ideas in the field of access-control policy using an extension language of XML.

6. What Kinds of Questions Do We Want to Ask? • Can this entity perform this action on this resource? • Can these entities perform this action on this resource? • ? What are all the (resource, action) pairs this person is authorized to perform?

7. What is the Problem…. • The XACML Model • Some Examples • Implementation Status

8. Policy Policy Credentials Collector Authentication Authority Attribute Authority Policy Decision Point Policy Credentials Credentials Assertion Authorization Decision Assertion Attribute Assertion Authentication Assertion System Entity Policy Enforcement Point Application Request The Theoretical Model

9. XACML is an OASIS standard that describes • A policy language • used to describe general access control requirements, and has standard extension points for defining new functions, data types, combining logic, etc. • An access control decision request/response language • lets you form a query to ask whether or not a given action should be allowed, and interpret the result. • The response always includes an answer about whether the request should be allowed using one of four values: • Permit, • Deny, • Indeterminate (an error occurred or some required value was missing, so a decision cannot be made) • Not Applicable (the request can't be answered by this service).

10. An Access Control Request • Subject • A set of attributes associated with the entity making the request • Resource • The resource to which access is being requested • Action • The requested action to be performed on the resource • Environment

11. Top Level Constructs – Rule, Policy, and PolicySet • XACML defines three top-level policy elements: • <Rule>, • <Policy> • <PolicySet>. • The <Rule> element • contains a boolean expression that can be evaluated in isolation • is not intended to be accessed in isolation by a PDP. • It is not intended to form the basis of an authorization decision by itself. • It may form the basic unit of management, and be re-used in multiple policies.

12. Top Level Constructs – Rule, Policy, and PolicySet • The <Policy> element • contains a set of <Rule> elements and • a specified procedure for combining the results of their evaluation. • It is the basic unit of policy used by the PDP, and so it is intended to form the basis of an authorization decision. • The <PolicySet> element • contains a set of <Policy> or other <PolicySet> elements and • a specified procedure for combining the results of their evaluation. • It is the standard means for combining separate policies into a single combined policy.

13. Policies (more) • The complete policy applicable to a particular decision request may be composed of a number of individual rules or policies. • For instance, in a personal privacy application, • the owner of the personal information may define certain aspects of disclosure policy, • and the enterprise that is the custodian of the information may define certain other aspects. • In order to render an authorization decision, it must be possible to combine the two separate policies to form the single policy applicable to the request.

14. Attributes • The currency that XACML deals in is attributes. • Attributes are named values of known types that may include an issuer identifier or an issue date and time. • Specifically, attributes are characteristics of the Subject, Resource, Action, or Environment in which the access request is made. • A user's name, their security clearance, the file they want to access, and the time of day are all attribute values. • When a request is sent from a PEP to a PDP, that request is formed almost exclusively of attributes, and they will be compared to attribute values in a policy to make the access decisions.

15. Making a Decision • Find relevant policies and rules • Evaluate the Rules • Combine the results

16. Targets - Finding a policy that applies to a given request. • A Target is associated with a PolicySet, Policy or Rule • The Subject, Resource and Action in a Request are matched against Targets, using the Conditions specified in the Target • A Condition is a set of statements about Attributes whose truth can be evaluated • If all the conditions of a Target are met, then its associated PolicySet, Policy, or Rule applies to the request. • In addition to being a way to check applicability, Target information also provides a way to index policies.

17. Policies Based on Resource Contents • Sometimes, an authorization decision is based on data contained in the information resource to which access is requested. • a common component of privacy policy is that a person should be allowed to read records for which he or she is the subject. • The corresponding policy must contain a reference to the subject identified in the information resource itself. • XACML provides facilities for doing this • when the information resource can be represented as an XML document. • When the information resource is not an XML document, specified attributes of the resource can be referenced

18. Evaluating Rules • Once a Policy has been found and verified to apply to a request, its Rules are evaluated. • A policy can have any number of Rules which contain the core logic of an XACML policy. • The heart of most Rules is a Condition, which is a boolean function. If the Condition evaluates to true, then the Rule's Effect (a value of Permit or Deny that is associated with successful evaluation of the Rule) is returned. • Evaluation of a Condition can also result in an error (Indeterminate) or discovery that the Condition doesn't apply to the request (NotApplicable). • A Condition can be quite complex, built from an arbitrary nesting of non-boolean functions and attributes.

19. “Accumulating” a Decision • A Policy or PolicySet may contain multiple policies or Rules, • each of which may evaluate to different access control decisions, • XACML needs some way of reconciling the decisions each makes. • Rule-Combining and Policy-Combining Algorithms • Combining Algorithms represent various ways of combining multiple decisions into a single decision. • Deny-overrides • Permit-overrides • Etc • Custom Combining algorithms • Combining Algorithms are used to build up increasingly complex policies

20. To be Covered…Some Other Time…. • AttributeDesignator • AttributeSelector • Bags

21. A Few More Concepts

22. Obligations - Other required actions • In many applications, policies specify actions that MUST be performed, either instead of, or in addition to, actions that MAY be performed. • XACML provides facilities to specify actions that MUST be performed in conjunction with policy evaluation in the <Obligations> element. • There are no standard definitions for these actions in version 1.0 of XACML. • Therefore, bilateral agreement between a PAP and the PEP that will enforce its policies is required for correct interpretation. • PEPs that conform with v1.0 of XACML are required to deny access unless they understand all the <Obligations> elements associated with the applicable policy. • <Obligations> elements are returned to the PEP for enforcement.

23. XACML context • The core language is insulated from the application environment by the XACML context, in which the scope of the XACML specification is indicated by the shaded area. • The XACML context is defined in XML schema, describing a canonical representation for the inputs and outputs of the PDP. • Attributes referenced by an instance of XACML policy may be in the form of XPath expressions on the context,or attribute designators that identify the attribute by subject, resource, action or environment and its identifier. • Implementations must convert between the attribute representations in the application environment (e.g., SAML, J2SE, CORBA, and so on) and the attribute representations in the XACML context. • How this is achieved is outside the scope of the XACML specification. In some cases, such as SAML, this conversion may be accomplished in an automated way through the use of an XSLT transformation.

25. What is the Problem…. • The XACML Model • Some Examples • Implementation Status

26. A Sample Policy • XACML policy for my Calendar • A single PolicySet that has several pieces that can easily be split out • and considered on their own

27. The top-level Target says that everything in this policy applies to my calendar. After that there are four sub-policies • .<PolicySet xmlns="urn:oasis:names:tc:xacml:1.0:policy" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:oasis:names:tc:xacml:1.0:policy cs-xacml-schema-policy-01.xsd" PolicySetId="stcCalenderPolicy" PolicyCombiningAlgId="urn:oasis:names:tc:xacml:1.0:policy-combining-algorithm:first-applicable"> • <Description>This policy defines all the access restrictions on Steve's calendar.</Description> • <!-- This policy applies to all accesses to Steve's calendar --> • - <Target> • - <Subjects> • <AnySubject /> • </Subjects> • - <Resources> • - <Resource> • - <ResourceMatch MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal"> • <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">stc@cal.brown.edu</AttributeValue> • <ResourceAttributeDesignator DataType="http://www.w3.org/2001/XMLSchema#string" AttributeId="urn:oasis:names:tc:xacml:1.0:resource:resource-id" /> • </ResourceMatch> • </Resource> • </Resources> • - <Actions> • <AnyAction /> • </Actions> • </Target>

28. Policy that applies to Steve, the owner, who has all rights • - <Policy PolicyId="OwnerPolicy" RuleCombiningAlgId="urn:oasis:names:tc:xacml:1.0:rule-combining-algorithm:first-applicable"> • - <Target> • - <Subjects> • - <Subject> • - <SubjectMatch MatchId="urn:oasis:names:tc:xacml:1.0:function:rfc822Name-equal"> • <AttributeValue DataType="urn:oasis:names:tc:xacml:1.0:data-type:rfc822Name">stc@brown.edu</AttributeValue> • <SubjectAttributeDesignator DataType="urn:oasis:names:tc:xacml:1.0:data-type:rfc822Name" AttributeId="principleName" /> • </SubjectMatch> • </Subject> • </Subjects> • - <Resources> • <AnyResource /> • </Resources> • - <Actions> • <AnyAction /> • </Actions> • </Target> <!-- If it's the calendar owner, we permit anything --> • <Rule RuleId="OwnerRule" Effect="Permit" /> • </Policy>

29. A couple policies that are only allowed if the action is read • - <Policy PolicyId="ReadAccessPolicy" RuleCombiningAlgId="urn:oasis:names:tc:xacml:1.0:rule-combining-algorithm:permit-overrides"> <!-- only use if they're requesting read access --> • - <Target> • - <Subjects> • <AnySubject /> • </Subjects> • - <Resources> • <AnyResource /> • </Resources> • - <Actions> • - <Action> • - <ActionMatch MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal"> • <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">read</AttributeValue> • <ActionAttributeDesignator DataType="http://www.w3.org/2001/XMLSchema#string" AttributeId="urn:oasis:names:tc:xacml:1.0:action:action-id" /> • </ActionMatch> • </Action> • </Actions> • </Target>

30. Allow read access to anyone affiliated with Brown • - <Rule RuleId="affiliationWithBrown" Effect="Permit"> • - <Target> • - <Subjects> • - <Subject> • - <SubjectMatch MatchId="urn:oasis:names:tc:xacml:1.0:function:rfc822Name-match"> • <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">.brown.edu</AttributeValue> • <SubjectAttributeDesignator DataType="urn:oasis:names:tc:xacml:1.0:data-type:rfc822Name" AttributeId="scopedAffiliation" /> • </SubjectMatch> • </Subject> • </Subjects> • - <Resources> • <AnyResource /> • </Resources> • - <Actions> • <AnyAction /> • </Actions> • </Target> • </Rule>

31. See if they're in the Brown course cs123 and have provided an acceptible entitlement • - <Rule RuleId="acceptibleEntitlements" Effect="Permit"> • - <Target> • - <Subjects> • - <Subject> • - <SubjectMatch MatchId="urn:oasis:names:tc:xacml:1.0:function:anyURI-equal"> • <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#anyURI">urn:mace:brown.edu:course:cs123</AttributeValue> • <SubjectAttributeDesignator DataType="http://www.w3.org/2001/XMLSchema#anyURI" AttributeId="groupMembership" /> • </SubjectMatch> • </Subject> • </Subjects> • - <Resources> • <AnyResource /> • </Resources> • - <Actions> • <AnyAction /> • </Actions> • </Target> • - <Condition FunctionId="urn:oasis:names:tc:xacml:1.0:function:anyURI-is-in"> • - <Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:anyURI-one-and-only"> • <SubjectAttributeDesignator AttributeId="entitlement" DataType="http://www.w3.org/2001/XMLSchema#anyURI" /> • </Apply> • <SubjectAttributeDesignator AttributeId="acceptibleEntitlements" DataType="http://www.w3.org/2001/XMLSchema#anyURI" /> • </Condition> • </Rule>

32. Policy that applies to Seth, a friend, who can schedule events a week or more from now • - <Policy PolicyId="addInOneWeekOrMore" RuleCombiningAlgId="urn:oasis:names:tc:xacml:1.0:rule-combining-algorithm:first-applicable"> • - <Target> • - <Subjects> • - <Subject> • - <SubjectMatch MatchId="urn:oasis:names:tc:xacml:1.0:function:rfc822Name-equal"> • <AttributeValue DataType="urn:oasis:names:tc:xacml:1.0:data-type:rfc822Name">stp@alumni.brown.edu</AttributeValue> • <SubjectAttributeDesignator DataType="urn:oasis:names:tc:xacml:1.0:data-type:rfc822Name" AttributeId="principleName" /> • </SubjectMatch> • </Subject> • </Subjects> • - <Resources> • <AnyResource /> • </Resources> • - <Actions> • - <Action> • - <ActionMatch MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal"> • <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">add</AttributeValue> • <ActionAttributeDesignator DataType="http://www.w3.org/2001/XMLSchema#string" AttributeId="urn:oasis:names:tc:xacml:1.0:action:action-id" /> • </ActionMatch> • </Action> • </Actions> • </Target> • (continued)

33. - <Rule RuleId="IsMoreThanOneWeekAhead" Effect="Permit"> • - <Condition FunctionId="urn:oasis:names:tc:xacml:1.0:function:dateTime-greater-than"> • - <Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:dateTime-add-dayTimeDuration"> • - <Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:dateTime-one-and-only"> • <ResourceAttributeDesignator DataType="http://www.w3.org/2001/XMLSchema#dateTime" AttributeId="calendarEntryDateTime" /> • </Apply> • <AttributeValue DataType="http://www.w3.org/TR/xquery-operators#dayTimeDuration">P7D</AttributeValue> • </Apply> • - <Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:dateTime-one-and-only"> • <EnvironmentAttributeDesignator DataType="http://www.w3.org/2001/XMLSchema#dateTime" AttributeId="urn:oasis:names:tc:xacml:1.0:environment:current-dateTime" /> • </Apply> • </Condition> • </Rule>

34. If we didn't fall into the above categories, then we deny • - <Policy PolicyId="denyAllOthers" RuleCombiningAlgId="urn:oasis:names:tc:xacml:1.0:rule-combining-algorithm:deny-overrides"> • - <Target> • - <Subjects> • <AnySubject /> • </Subjects> • - <Resources> • <AnyResource /> • </Resources> • - <Actions> • <AnyAction /> • </Actions> • </Target> • <Rule RuleId="denyOthers" Effect="Deny" /> • </Policy> • </PolicySet>

35.  - The first policy checks to see if the subject is stc@brown.edu. If it is, •    then the owner is making a request, and is therefore allowed to do •    anything. No other checking is done. •  - The second policy has a target that checks to see if the action is "read" •    and if it is then there are a couple of rules. The first rule says that •    anyone affiliated with Brown is allowed access. The second rule says •    that anyone in course cs123 who provides an acceptible entitlement is •    allowed access. I tried to use names based on our conversation this morning, •    but again feel free to change things around if you'd like. Note that after •    our talk I decided that the best way to show dynamic attribute retrieval •    was in a rule, so in the second rule here, the assumption is that the •    acceptible entitlements come from some attribute source. •  - The third policy allows stp@alumni.brown.edu permission to add any event •    to your calendar, so long as the event is at least one week away. I think •    that's kind of a neat constraint that you can't do in the real world, and •    I wish I could use it on my calendar at work (I come in a lot to find that •    I've been scheduled for that day). Note that I also have read access to •    your calendar since I'm affiliated with Brown, per the second policy. •  - The fourth policy is a default, fall-through policy that says if none of •    the first three policies applied, then deny everyone else.

36. What is the Problem…. • The XACML Model • Some Examples • Implementation Status

37. Implementation Status • Sun has a java based implementation • They have open-sourced it • http://sunxacml.sourceforge.net/ • Provides complete support for • all the mandatory features of XACML as well as a number of optional features. • Specifically, there is full support for • parsing both policy and request/response documents, • determining applicability of policies, and • evaluating requests against policies. • All of the standard attribute types, functions, and combining algorithms are supported, and • There are APIs for adding new functionality as needed. • There are also APIs for writing new retrieval mechanisms used for finding things like policies and attributes.

38. Using the Sun Implementation • Sun is funding a summer intern • She is developing “glue” between common environments and the XACML engine • A library to build XACML Requests and parse Responses • Apache plugin • Perl Package (wrapper) • ? Suggestions ?

39. Questions?