Access Control

1. CS 290C: Formal Models for Web Software Lectures 12: Modeling and Analyzing Access Control PoliciesInstructor: Tevfik Bultan

2. Access Control • Web-based applications are used to access all types of sensitive information such as bank accounts, employee records and even health records. • Given the ease of access provided by the Web, it is crucial to provide access control mechanisms to applications that deal with sensitive information. • Moreover, due to the increasing use of service oriented architectures, it is necessary to develop techniques for keeping the access control policies consistent across heterogeneous systems and applications spanning multiple organizations.

3. XACML • “eXtensible Access Control Markup Language” (XACML), is an XML-based language for expressing access rights to arbitrary objects that are identified in XML • It particularly focuses on the composition of many individual policies into a single “super-policy”

4. Role Based Access Control (RBAC) • XACML uses Role Based Access Control (RBAC) • In RBAC, instead of identifying a set of access rules for individual users, the users are grouped into a set of roles • Then the access control rules are specified based on roles and combined into an access control policy • A user with a particular role obtains access to an operation if that role has access to that operation based on the access control policy

5. XACML Policy Enforcement • XACML policy enforcement consists of three main components: • A policy • A Policy Enforcement Point (PEP) • A Policy Decision Point (PDP)

6. XACML Components • An XACML Policy Enforcement Point (PEP) is the gateway that determines whether an action is permitted or not • PEP takes access requests, which are specially formatted XML documents that define a set of data values • PEP forwards the request to Policy Decision Point (PDP)

7. XACML Components • Policy Decision Point (PDP) evaluates the request and sends back a response • To get to the policies, the PDP uses the Policy Administration Point (PAP), which stores the policies and makes them available to the PDP • PDP may also invoke the Policy Information Point (PIP) service to retrieve the attribute values related to the subject, the resource, or the environment

8. XACML Architecture Request Policy Enforcement Point (PEP) Policy Decision Point (PDP) Policy Information Point (PIP) Policy Administration Point (PAP) Attribute Store Policy Store

9. XACML Result • After the request is evaluated, the Policy Enforcement Points yield one of four results: • Permit, meaning that the access request is permitted; • Deny, meaning that the access request will not be permitted; • Not Applicable, meaning that this particular policy says nothing about the request; • Indeterminate, which means that something unexpected has occurred and the execution of the policy has failed. • Which result occurs depends on what result the policy dictates, given the data in the access request.

10. XACML Policies • XACML policies are written in XML, and typically authored using a dedicated policy editor. • The language describes three classes of objects: • individual rules • collections of rules called policies, and • collections of policies called policy sets.

11. XACML Components • Target: Determines the applicability of a rule, a policy or a policy set to the incoming request using three attributes: • Subject • Resource • Action • The values of these attributes are compared with the values of the attributes in the request  • If they match then the policy is considered relevant to the request and is evaluated

12. XACML Components • Obligations: Obligations are the actions that must be performed by the PEP in conjunction with the enforcement of an authorization decision • After a policy has been evaluated, specific obligations are sent to the PEP along with the authorization decision. • In addition to enforcing the authorization decision, the PEP is responsible for executing the operations specified as obligations.

13. XACML rules • XACML rules are the most basic component of a policy • They have a goal effect which is either Permit or Deny • They have a domain of applicability, and conditions under which they can yield Indeterminate • The domain of applicability (target) is specified as a series of predicates about the environmental data that must all be satisfied for the rule to yield its goal effect.

14. XACML Rules • Rules: A policy can contain multiple rules. Each rule is associated with: • Condition: A statement about the attributes that evaluates to True, False, or Indeterminate. • Effect: The intended consequence of the satisfied rule. It can either take the value Permit or Deny. • Target: Determines whether or not a rule is relevant for a request.

15. Rule/Policy Combinators • In XACML there are several policy combinator operators: • Permit-overrides(p, q) always yields Permit if either p or q yield Permit. • Deny-overrides(p, q) always yields Deny if either p or q yield Deny. • Only-one-applicable(p, q) requires that one of p or q yield NotApp and then yields the other half’s answer. • First-applicable(p, q) yields p’s answer unless that answer is NotApp, in which case it yields q’s answer.

16. XACML Policies and Policy Sets • XACML policies are constructed by combining individual rules • XACML policy sets are constructed by combining policies • Rule and policy combination operations are similar

17. Policies can be Tricky • We would like to check properties of policies since writing policies and combining them can be tricky and error-prone • Assume a policy with • two Roles: Faculty and Student • two resources: InternalGrades, ExternalGrades • three actions: Assign, View, Receive • An access control Policy: • POL1: Requests for students to Receive ExternalGrades, and for faculty to Assign and View both InternalGrades and Externalgrades will succeed.

18. Policies can be Tricky • Example properties: • PR1: There do not exist members of Student who can Assign ExternalGrades • PR2: All members of Faculty can Assign both InternalGrades and ExternalGrades • PR3: No combination of roles exists such that a user with those roles can both Receive and Assign the resource ExternalGrades

19. Policies can be Tricky • PR1 and PR3 do not hold: • A student can request to receive an external grade (which POL1 permits) while simultaneously assigning an external grade • An action in XACML is a set, it does not have to be a singleton. So, the policy developer is responsible for checking this condition.

20. Policies can be Tricky • Change POL1 by requiring that each attribute is a single attribute (using an XACML construct), call this policy POL2 • PR1 and PR3 do not hold for POL2 either • Counter-example, a person can be both a Student and a Faculty • We can demand that the roles should be disjoint (using another XACML construct) which results in POL3 • For POL3 all three properties hold

21. Policies can be Tricky • Next we add the teaching assistants (TAs) to our policy. • POL4 gives the TAs same privileges as Faculty • However, since TAs are also students, this again leads to violation of properties PR1 and PR3 • A counter-example shows that a TA who is a Student can assign an ExternalGrade and is not a Faculty • POL5: TA can view and assing InternalGrades but not ExternalGrades combined with POL3 • This combined policy satisfies all three properties

22. Policies can be Tricky • Next we extend the policy one more time by adding a FacultyFamily role • POL6: Faculty family members can enroll in classes and receive external grades. • Then we add the following property: • PR4: All members of role FacultyFamily can receive ExternalGrades • However, POL6 violates PR3 • A person who has both Faculty and FacultyFamily roles (e.g. spouse of a Faculty is also a Faculty) can receive and assign external grades • This can be fixed again by requiring that the roles be disjoint, which results in POL7, which satisfies all properties

23. Another Example Policy • Let us look at another simple example policy in XACML • This simple policy states that • to be able to vote • a person must be at least 18 years old and • a person who has voted already cannot vote.

24. XACML Example 1 <?xml version="1.0" encoding="UTF-8"?> 2 <Policy xmlns="urn:..." xmlns:xsi="...-instance" 3 xmlns:md="http:.../record.xsd" PolicySetId="urn:example:policyid:1" 4 RuleCombiningAlgId="urn:...:deny-overrides"> 5 <Target> 6 <Subjects><AnySubject/></Subjects> 7 <Resources><AnyResource/></Resources> 8 <Actions> 9 <Action> 10 <ActionMatch MatchId="urn:...:string-equal"> 11 <AttributeValue DataType="...#string">vote </AttributeValue> 12 <ActionAttributeDesignator AttributeId="urn:example:action" 13 DataType="...#string"/> 14 </ActionMatch> 15 </Action> 16 </Actions> 17 </Target> 18 <Rule RuleId="urn:example:ruleid:1" Effect="Deny">19 <Condition FunctionId="urn:...:integer-less-than"> 20 <Apply FunctionId="urn:...:integer-one-and-only"> 21 <SubjectAttributeDesignator AttributeId="urn:example:age" 22 DataType="...#integer"/> 23 </Apply> 24 <AttributeValue DataType="...#integer">18</AttributeValue> 25 </Condition> 26 </Rule> 27 <Rule RuleId="urn:example:ruleid:2" Effect="Deny"> 28 <Condition FunctionId="urn:...:boolean-equal"> 29 <Apply FunctionId="urn:...:boolean-one-and-only"> 30 <SubjectAttributeDesignator AttributeId="urn:example:voted-yet" 31 DataType="...#boolean"/> 32 </Apply> 33 <AttributeValue DataType="...#boolean">True</AttributeValue> 34 </Condition> 35 </Rule> 36 <Rule RuleId="urn:example:ruleid:3" Effect="Permit"/> 37 </Policy>

25. Example Policy • A request, the input information we receive for the given policy, consists of the age of the person in question and whether they have voted already. • We can represent this as a Cartesian product of the power sets of XML Schema basic types, as follows: R = P(xsd:int) x P(xsd:boolean) x P(xsd:string) • Each member of R is a request that indicates the age of the person, whether or not they have voted already, and the action they are attempting (could be voting or something else) • The use of power sets is due to XACML semantics. • In XACML an attribute always describes a set of values, never a scalar value. • A scalar value, for example the age of a person, is represented as a singleton set.

26. Motivation • XACML is complex and not easy to read • Combining policies that are each individually fine can have catastrophic consequences • We would like some way to verify that a complex policy does not behave unexpectedly • Best if this doesn’t rely upon a new language

27. Automated Verification of XACML Policies • Three approaches • Margrave: • Converts XACML policies to multi-terminal decision diagrams • Alloy translation • Translate an XACML policy specification to an Alloy specification an check properties on the Alloy specification • Direct SAT translation • Translate a verification query about an XACML policy directly to a SAT instance and use a SAT solver to determine if the property holds • All three are bounded approaches • They check the property within a given bound

28. Margrave Approach • Margrave use multi-terminal decision diagrams (MTBDDs) for automated analysis of XACML policies • MTBDDs are like BDDs (binary decision diagrams) • BDDs have two terminal nodes (True or False) • MTBDDs have multiple terminal nodes

29. Binary Decision Diagrams Overview • Reduced Ordered Binary Decision Diagrams (BDDs) • An efficient data structure for representing truth sets of boolean formulas and manipulating them • There are BDD packages available: (for example CUDD from Colorado University) • BDDs are a canonical representation for boolean functions • given two boolean logic formulas F and G, if F and G are equivalent (i.e. if their truth sets are the same), then their BDD representations will be the same

30. Binary Decision Trees Fix a variable order. In each level of the tree, branch on the value of the variable in that level. • Examples for boolean formulas on two variables Variable order: x, y x  y x  y x False x x x x F T F T F T F T y y y y y y y y F T F T F T F T F T F T F T F T F T T T F F F T F F T T F F F F

31. Binary Decision Diagrams • BDDs are Reduced and Ordered • Reduced: • Merge all identical sub-trees in the binary decision tree (converts it to a directed-acyclic graph) • Remove redundant tests (if the false and true branches for a node go to the same place, remove that node) • Ordered • We pick a fix order for the Boolean variables: x0< x1< x2 < … • The nodes in the BDD are listed based on this ordering

32. BDDs • Repeatedly apply the following transformations to a binary decision tree: • Remove duplicate terminals • Remove duplicate non-terminals • Remove redundant tests • These transformations transform the tree to a directed acyclic graph

33. Binary Decision Trees vs. BDDs x  y x  y x False x x x x F T F T F T F T y y y y y y y y F T F T F T F T F T F T F T F T F T T T F F F T F F T T F F F F x x x F F T F F T T y y F T F T F T F T F T

34. Good News About BDDs • Given BDDs for two boolean logic formulas F and G • The BDDs for F  G and F  G are of size |F|  |G| (and can be computed in that time) • The BDD for F is of size |F| (and can be computed in that time) • F ? G can be checked in linear time • Satisfiability of F can be checked in constant time • No, this does not mean that you can solve SAT in constant time

35. Bad News About BDDs • The size of a BDD can be exponential in the number of boolean variables • The sizes of the BDDs are very sensitive to the variable ordering. Bad variable ordering can cause exponential increase in the size of the BDD • There are functions which have BDDs that are exponential for any variable ordering (for example binary multiplication)

36. Back to Margrave Approach • Margrave implements • algorithms for MTBDD construction for rules • algorithms for MTBDD construction for rule/policy combinations • The MTBDDs constructed from XACML policies have three terminal nodes: • Permit, Deny, Not-Applicable

37. Margrave Approach • Margrave also supports several operators that enable manipulation of a policy for verification purposes: • Restrict-to-dec: can be used to restrict a policy to only a particular type of decision (such as Permit) • Get-present-matches and get-present-attrValues can be used to identify which values make the BDD eveluate to true • There are also operations that allow the developer to make comparisons (such as subset) among policies • Using these operations one can explore the properties of a given policy

38. Margrave Change Impact Analysis • Margrave also supports a type of change impact analysis • Given two policies, Margrave is able to construct a new MTBDD that identifies the changes between these two policies • By querying this difference MTBDD the developer can identify all the differences between two policies

39. SAT Based approaches • Instead of using the decision diagram approach used in Margrave, another approach is to use a SAT based approach • Construct a SAT instance that corresponds to the property that we want to check about the policy • There are two possible ways of doing this: • Use Alloy as an intermediate language • Translate XACML policy to Alloy and let Alloy construct the SAT instance • Directly translate to SAT

40. Problem definition • A policyp ∈ P is a function from a request to one of the four values permit (P), deny (D), not-applicable (N) or indeterminate (I) • We can define relationships among policies to identify which one is more permissive or more restrictive etc. • Given policies p1 and p2: p1P-subsumesp2 or p1 ⊑Pp2 if ∀r∈R, p1(r) = P ⇒ p2(r) = P • Problem is: given p1 and p2, efficiently determine if p1P-subsumes p2

41. Problem definition, cont. • We can assume that policies are always constructed from primitive elements • Permit, Deny ∈ P • Basic policies which always permit or always deny • The rest of the policies are constructed by applying following operations on these basic policies: • Restricting the domain of applicability of a policy using conditions • Combining the policies using policy combination functions • Permit-overrides, Deny-overrides, Only-one-applicable, First-applicable

42. Alloy Translation • Use a normal form for policy specification (triple) • Map each policy to a sig • Develop Alloy mappings for policy combination operations • Express the queries about policies as assert statements static sig P1 extends Triple {} { ... } static sig P2 extends Triple {} { ... } assert Subset { P1.permit in P2.permit P1.deny in P2.deny P1.error in P2.error }

43. Alloy Translation • Define a sig for the possible set of request values • Also define a sig for constants in the policy sig R { age : set Integer, voted : set Bool, actions : set String } static sig CONSTANTS { eighteen : scalar Integer, vote : scalar String, ... }

44. Alloy Translation • Need to interpret many functions on domains such as integers which are not handled by Alloy using facts fact { all a,b,c:Type { LessThan (a, b) = True && LessThan (b, c) = True => LessThan (a, c) = True } } sig S_0 extends E {} [ all x : age | LessThan(x, CONSTANTS.eighteen) = True }

45. Alloy Translation • Alloy translation approach does not work well • The translation to Alloy ends up being to inefficient due to encoding of integer perdicates and other functions that are not directly support by Alloy • A direct SAT translation worked much better.

46. Direct Translation to SAT • Given a policy in this form, how to go about analysis? • Convert to a normal form • Formulate the question • Encode as a SAT problem • Translate to CNF • Run SAT solver

47. Step 1: Normal Form • Why a normal form at all? • It is a triplet that identifies the domain values for which the policy evaluates to Permit, Deny, or Indeterminate • All the remaining domain values map to NotApplicable • Why not perform analysis on the raw policy? • Not obvious how to translate the raw policy to SAT in some cases • Enables optimization • May be able to convert other specification languages to the same normal form and compare them

48. Step 2: Formulate the Question • In our case, we have chosen policy subsumption as the question we want to answer about a policy • This is translatable to a Boolean implication if each of the component forms can be so translated

49. Step 3: Encode as a SAT Problem • We have to bound the problem or it becomes undecidable • Translation technique is standard • Encode sets as arrays of Boolean variables, so item #n is in the set if vn is true • Encode scalars using a binary encoding, so x is item #5 if x0 ∧ ¬x1 ∧ x2 • Subsumption translates to implication • Final step is negating the formula • We are looking for violations of the property • If the generated SAT instance is satisfiable then the property does not hold

50. Step 4: Translate to CNF • Boolean formulas must be translated into CNF for them to be useful for a SAT solver • We use the structure preserving transformation • Not the best, but easy to code and get right • SAT solution time does not represent a significant time sink for us