CS 290C: Formal Models for Web Software
Lectures 12: 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 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.
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)
• 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
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
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
XACML Architecture
Request
Policy
Enforcement
Point
(PEP)
Policy
Decision Point
(PDP)
Policy
Information
Point
(PIP)
Policy
Administration
Point
(PAP)
Attribute
Store
Policy
Store
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 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
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.
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
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 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.
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
• 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
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
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
F
T
y
F
F
F
T
y
y
T F
T
T
T
T
x
F
F
F
T
y
y
T F
T
F
T
F
x
F
F
F
y
y
T F
T
F
T
T
T
F
F
y
T F
T
F
F
F
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
BDDs
•
Repeatedly apply the following transformations to a binary
decision tree:
1. Remove duplicate terminals
2. Remove duplicate non-terminals
3. Remove redundant tests
•
These transformations transform the tree to a directed
acyclic graph
Binary Decision Trees vs. BDDs
xy
xy
x
False
x
x
x
x
F
T
y
F
F
F
T F
T
T
T
T
F
T
y
y
F
F
F
T F
T
F
T
F
T
y
y
x
F
F
T
T
T
F
T
F T
T
T
F
T
T
y
T F
F
F
y
T F
T
F
F
F
F
x
F
T
F
T
y
T
F
y
x
F
y
F
F
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
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)
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
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
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 Psubsumes p2
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-oneapplicable, 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 ∧ ¬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
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 XACML specification
– Continue conference manager
– Our own examples on a voting policy
• Everything runs very quickly
– Major bottleneck is CNF translation
Results
• Examples are very distinct
– Medico example: A simple medical database meant to
be accessed by physicians
• uses many advanced XACML features
– Continue: web-based conference management tool,
aiding paper submission, review, discussion and
notification tasks
• contains no <Condition> elements and goes to a
great deal of trouble to express conditions using
<Scope> only
– Voting example: A simple policy for voting rules
• Our own made-up example, uses integer
comparisons
Selected Results
Property
Time
Lines of
XACML
C1
C2
C6
3.48 s
13157
56
Holds
4.06 s
13175
42
Holds
4.95 s
13150
89
Fails
C9
M1
M2
V1
3.68 s
13107
51
Fails
16.09 s
457
109
Holds
15.94 s
405
108
Holds
6.85 s
102
52
Fails
Variables
Result
Results
• 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