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

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 p1 and p2: p1 P-subsumes p2 or p1 ⊑P p2 if r R∀ ∈ , p1(r) = P ⇒ p2(r) = P

• Problem is: given p1 and p2, efficiently determine if p1 P-subsumes p2

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 vn is true

– Encode scalars using a binary encoding, so x is item #5 if x0 ¬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 <Condition> elements and goes to

a great deal of trouble to express conditions using <Scope> only

– Our own examples use integer comparisons

Property TimeLines of XACML

Variables Result

C1 3.48 s 13157 56 Holds

C2 4.06 s 13175 42 Holds

C6 4.95 s 13150 89 Fails

C9 3.68 s 13107 51 Fails

M1 16.09 s 457 109 Holds

M2 15.94 s 405 108 Holds

V1 6.85 s 102 52 Fails

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