members of a role x are also implicitly members of a role

y. In addition, RBAC introduces constraints that are a pow-

erful mechanism for laying out higher-level organizational
policies. Separation of duty (SoD) is a well-known principle
for preventing fraud by identifying conflicting roles and has
been studied in considerable depth by RBAC community [3],
[7], [17]. SoD constraints in RBAC can be divided into Static
SoD constraints, Dynamic SoD constraints and Historical
SoD constraints. Static SoD constraints typically require that
no user should be assigned to conflicting roles. Dynamic
Figure 2. Tree structure of the example XACML policy. SoD constraints–with respect to activated roles in sessions–
typically require that no user can activate conflicting roles
simultaneously. Historical SoD constraints restrict the as-
policy of the entire company, has two rules r1 and r2 signment and activation of conflicting roles over the course
indicating that of time.
• all employees can read and change codes during work-
C. Answer Set Programming
ing hours from 8:00 to 17:00 (r1 ), and
• nobody can change code during non-working hours ASP [20], [18] is a recent form of declarative program-
(r2 ). ming that has emerged from the interaction between two
lines of research—nonmonotonic semantics of negation in
On the other hand, each department is responsible for
logic programming and applications of satisfiability solvers
deciding whether employees can read codes during non-
to search problems. The idea of ASP is to represent the
working hours. A local policy p2 for a development depart-
search problem we are interested in as a logic program
ment with three rules r3 , r4 and r5 is that
whose intended models, called “stable models (a.k.a. answer
• developers can read codes during non-working hours
sets),” correspond to the solutions of the problem, and then
(r3 ), find these models using an answer set solver—a system for
• testers cannot read codes during non-working hours
computing stable models. Like other declarative computing
(r4 ), and paradigms, such as SAT (Satisfiability Checking) and CP
• testers and developers cannot change codes during non-
(Constraint Programming), ASP provides a common basis
working hours (r5 ). for formalizing and solving various problems, but is distinct
Note that the rule combining algorithm for policy p1 is from others such that it focuses on knowledge representation
permit−overrides and the rule combining algorithm for and reasoning: its language is an expressive nonmonotonic
policy p2 is deny−overrides. language based on logic programs under the stable model
semantics [11], [9], which allows elegant representation of
B. Role-based Access Control several aspects of knowledge such as causality, defaults, and
RBAC is a widely accepted alternative to traditional incomplete information, and provides compact encoding of
mandatory access control (MAC) and discretionary access complex problems that cannot be translated into SAT and
control (DAC) [24]. As MAC is used in the classical defense CP [19]. As the mathematical foundation of answer set
arena, the access is based on the classification of objects programming, the stable model semantics was originated
such as security clearance [23] while the main idea of DAC from understanding the meaning of negation as failure in
is that the owner of an object has the discretion over who Prolog, which has the rules of the form
can access the object [15], [22]. However, RBAC is based
a1 ← a2 , . . . , am , not am+1 , . . . , not an (1)
on the role of the subjects and can specify security policy
in a way that maps to an organizational structure. A general where all ai are atoms and not is a symbol for negation
family of RBAC models called RBAC96 was proposed by as failure, also known as default negation. Intuitively, under
Sandhu et al. [21]. Intuitively, a user is a human being the stable model semantics, rule (1) means that if you have
or an autonomous agent, a role is a job function or job generated a2 , . . . , am and it is impossible to generate any of
title within the organization with some associated semantics am+1 , . . . , an then you may generate a1 . This explanation
regarding the authority and responsibility conferred on the seems to contain a vicious cycle, but the semantics are
user assigned to the role, and a permission is an approval carefully defined in terms of fixpoint.
of a particular mode of access to one or more objects in While it is known that the transitive closure (e.g., reach-
the system or some privileges to carry out specified actions. ability) cannot be expressed in first-order logic, it can be
Roles are organized in a partial order ≥, so that if x ≥ y handled in the stable model semantics. Given the fixed extent
then a role x inherits the permissions of a role y. Therefore, of edge relation, the extent of reachable is the transitive

3
 A. Abstracting XACML Policy Components
We consider a subset of XACML that covers more con-
structs than the ones considered in [28] and [16]. We allow
the most general form of Target, take into account Condition,
and cover all four combining algorithms.
XACML components can be abstracted as follows: At-
tributes are the names of elements used by a policy.
Attributes are divided into three categories: subject at-
tributes, resource attributes and action attributes. In the
example policy above, developer, tester and employee
are subject attributes; read and change are action at-
tributes; codes is a resource attribute. A Target is a triple
Figure 3. Logic-based policy reasoning for XACML. ⟨Subjects, Resources, Actions⟩. A Condition is a conjunction
of comparisons. An Effect is either “permit,” “deny,” or
“indeterminate.”
closure of edge.
• An XACML rule can be abstracted as
reachable(X, Y ) ← edge(X, Y )
reachable(X, Y ) ← reachable(X, Z), reachable(Z, Y ) ⟨RuleID, Effect, Target, Condition⟩
Several extensions were made over the last twenty years. where RuleID is a rule identifier. For example, rule r1
The addition of cardinality constraints turns out to be useful in Figure 1 can be viewed as
in knowledge representation. A cardinality constraint is
⟨r1 , permit, ⟨employee, read ∨ change, codes⟩,
of the form lower{l1 , . . . , ln }upper where l1 , . . . , ln are 8 ≤ time ≤ 17⟩.
literals and lower and upper are numbers. A cardinality
constraint is satisfied if the number of satisfied literals in • An XACML policy can be abstracted as
l1 , . . . , ln is in between lower and upper. It is also allowed ⟨PolicyID, Target , Combining Algorithm, ⟨r1 , . . . , rn ⟩⟩
to contain variables in cardinality constraints. For instance,
where PolicyID is a policy identifier, r1 , . . . , rn
more than one edge(X) ← 2{edge(X, Y ) : vertex(Y )}.
are rule identifiers and Combining Algorithm is
means that more than one edge(X) is true if there are at either permit−overrides, deny−overrides, or
least two edges connect X with other vertices. first−applicable. For example, policy p1 in Fig-
The language also has useful constructs, such as strong ure 1 is abstracted as:
negations, weak constraints, and preferences. What distin- ⟨p1 , Null, permit−overrides, ⟨r1 , r2 ⟩⟩.
guishes ASP from other nonmonotonic formalisms is the
availability of several efficient implementations, answer set • Similarly we can abstract an XACML policy set as
solvers, such as SMODELS1 , CMODELS2 , CLASP3 , which led ⟨PolicySetID, Target, Combining Algorithm,
to practical nonmonotonic reasoning that can be applied to ⟨p1 , . . . , pm , psm+1 , . . . , psn ⟩⟩
industrial level applications.
where PolicySetID is a policy set identifier,
III. G ENERAL XACML P OLICY A NALYSIS p1 , . . . , pm are policy identifiers, psm+1 , . . . , psn
We introduce a logic-based policy reasoning approach for are policy set identifiers, and Combining Algorithm
XACML as shown in Figure 3. First, XACML policies are is either permit−overrides, deny−overrides,
converted to ASP programs. Then, by means of off-the-shelf first−applicable, or only−one−applicable. For
ASP solvers, several typical policy analysis services, such example, policy set ps1 can be viewed as
as policy verification, comparison, redundancy and querying ⟨ps1 , Null, first−applicable, ⟨p1 , p2 ⟩⟩.
are utilized. For instance, policy verification is to check
if ASP-based representation of XACML policies entails B. Turning XACML into ASP
the property as certain formulas in its specification, policy
comparison checks the equivalence between two answer set We provide a translation module that turns an XACML
programs, and policy redundancy checking can be viewed as description into a program in ASP. This interprets a formal
an instance of simplification of ASP programs. semantics of XACML language in terms of the Answer Set
semantics.
1 http://www.tcs.hut.fi/Software/smodels .
2 http://www.cs.utexas.edu/users/tag/cmodels.html
The translation module coverts an XACML rule
.
3 http://potassco.sourceforge.net . ⟨RuleID, Effect, Target, Condition⟩