CS 290C: Formal Models for Web Software Lectures 16: Modeling and Analyzing Access Control Policies Instructor: Tevfik Bultan

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

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”

Role Based Access Control (RBAC) XACML uses Role Based Access Control (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 for an operation if that role has access to that operation based on the access control policy

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

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)

XACML Components Policy Decision Point (PDP) evaluates the request and sends back a response To get to the policies, the PDP uses the Policy Access 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

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.

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.

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

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.

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.

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.

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.

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

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.

Policies can be Tricky Example properties: –PR1: There do not exists 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

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 Actions in XACML is a set, it does not have to be a singleton. So the policy developer is responsible for checking this condition

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

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

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

Another Example Policy Let us look at a simple example policy in XACML The 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.

XACML Example 1 2 <Policy xmlns="urn:..." xmlns:xsi="...-instance" 3 xmlns:md=" PolicySetId="urn:example:policyid:1" 4 RuleCombiningAlgId="urn:...:deny-overrides"> vote 12 <ActionAttributeDesignator AttributeId="urn:example:action" 13 DataType="...#string"/> <SubjectAttributeDesignator AttributeId="urn:example:age" 22 DataType="...#integer"/> <SubjectAttributeDesignator AttributeId="urn:example:voted-yet" 31 DataType="...#boolean"/> True

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.

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

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

Margrave Approach Use multi-terminal decision diagrams (MTBDDs) –Like BDDs, however, instead of having two terminal nodes (True or False), the MTBDDs constructed from XACML policies have three terminal nodes: Permit, Deny, Not-Applicable Margrave implements –algorithms for MTBDD construction for rules – algorithms for MTBDD construction for rule/policy combinations

Margrave Approach Margrave also supports several operators that enable manipulation of a policy for verification purposes: –Restrict-do-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

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

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

Problem definition A policy p ∈ 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 p 1 and p 2 : p 1 P-subsumes p 2 or p 1 ⊑ P p 2 if ∀ r ∈ R, p 1 (r) = P ⇒ p 2 (r) = P Problem is: given p 1 and p 2, efficiently determine if p 1 P- subsumes p 2

Problem definition, cont. To aid us in this task, 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

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 }

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,... }

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 }

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.

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

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

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

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 v n is true –Encode scalars using a binary encoding, so x is item #5 if x 0 ∧ ¬x 1 ∧ x 2 –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

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

Step 5: Run SAT Solver Use zchaff If a satisfying instance is found—that is, the subsumption relation does not hold—we need to translate the solver’s output back –Solver gives the certificate in terms of the variables in the CNF formula, not an example in the environment –Conversion is simple, tedious and boring

Results We ran our tool against every sizable piece of XACML we could find –Medico example from the specification –Continue conference manager –Our own examples Everything runs very quickly –Major bottleneck is CNF translation

Results Examples are very distinct –Medico uses many advanced XACML features –Continue contains no elements and goes to a great deal of trouble to express conditions using only –Our own examples use integer comparisons

Selected Results

Results: Commentary As the paper describes, computation time is dominated by the process of CNF conversion M1 and M2 have much larger runtimes than any of the Continue examples because they are more complex despite being nearly two orders of magnitude smaller Variable and clause count gives a better idea of the complexity of the example SAT solution time unexpectedly small