__________________________________________________________

4 value(permit;deny;indeterminate).
into a set of ASP rules rule(r1;r2;r3;r4;r5).
policy(p1;p2).
decision(RuleID, Effect) ← Target ∧ Condition. policyset(ps1).
time(0..23).
An XACML policy #domain value(V;V1).
#domain rule(R;R1).
⟨PolicyID, Target, Combining Algorithm, ⟨r1 , . . . , rn ⟩⟩ #domain policy(P).
#domain time(T).
can be also translated into a set of ASP rules. In the % domain definition
subject(employee) :- subject(developer).
following we assume that R and R′ are variables that range subject(employee) :- subject(tester).
over all rule ids, and V is a variable that ranges over % r1
decision(r1,permit) :- subject(employee),action(read),
{permit, deny, indeterminate}. In order to represent the resource(codes),8<=T,T<=17, current_time(T).
effect of each rule ri (1 ≤ i ≤ n) on policy, we write decision(r1,permit) :- subject(employee),action(change),
resource(codes),8<=T,T<=17, current_time(T).
% r2
decision from(PolicyID, ri , V ) ← decision(ri , V ). decision(r2,deny) :- subject(employee),action(change),
resource(codes).
Each rule combining algorithms is turned into logic pro- % r3
gramming rules under the stable model semantics as follows: decision(r3,permit) :- subject(developer),action(read),
resource(codes).
• permit−overrides of policy p is represented as % r4
decision(r4,deny) :- subject(tester),action(read),
decision(p, permit) ← resource(codes).
decision f rom(p, R, permit) ∧ T arget. % r5
decision(r5,deny) :- subject(tester),action(change),
decision(p, deny) ← decision f rom(p, R, deny) resource(codes).
∧ not decision(p, permit) ∧ T arget. decision(r5,deny) :- subject(developer),action(change),
resource(codes).
• deny−overrides of policy p is represented as % p1
decision_from(p1,r1,V) :- decision(r1,V).
decision(p, deny) ← decision_from(p1,r2,V) :- decision(r2,V).
decision f rom(p, R, deny) ∧ T arget. decision(p1,permit) :- decision_from(p1,R,permit).
decision(p1,deny) :- decision_from(p1,R,deny),
decision(p, permit) ← decision f rom(p, R, permit) not decision(p1,permit).
∧ not decision(p, deny) ∧ T arget. % p2
decision_from(p2,r3,V) :- decision(r3,V).
• first−applicable of policy p is represented as decision_from(p2,r4,V) :- decision(r4,V).
decision_from(p2,r5,V) :- decision(r5,V).
has decision f rom(p, R) ← decision f rom(p, R, V ). decision(p2,deny) :- decision_from(p2,R,deny).
decision(p2,permit) :- decision_from(p2,R,permit),
decision(p, V ) ← decision f rom(p, ri , V ) ∧ not decision(p2,deny).
^
not has decision f rom(p, rk ) ∧ T arget. % ps1
decision_from(ps1,p1,V) :- decision(p1,V).
1≤k≤i−1 decision_from(ps1,p2,V) :- decision(p2,V).
has_decision_from(ps1,p1) :- decision_from(ps1,p1,V).
The translation of a policy set is similar to the translation decision(ps1,V) :- decision_from(ps1,p1,V).
of a policy except that the policy combining algorithm decision(ps1,V) :- decision_from(ps1,p2,V),
not has_decision_from(ps1,p1).
only−one−applicable needs to be taken into account. __________________________________________________________
For instance, only−one−applicable of policy set ps is
represented as follows: Figure 4. ASP representation of the example XACML policy
decision(ps, V ) ← decision f rom(ps, P, V )∧
1{has decision f rom(ps, P ) : policy(P )}1.
decision(ps, indeterminate) ← The problem of verifying a security property F against
2{has decision f rom(ps, P ) : policy(P )}. an XACML description can be cast into the problem of
checking whether the program
Figure 4 shows an ASP representation of the example
XACML policy in the language of GRINGO by applying our Π ∪ Πquery ∪ Πconfig
translation approach.
has no answer sets, where Π is the program corresponding
C. XACML Policy Analysis Using ASP to the XACML specification, Πquery is the program corre-
Once we represent an XACML into an ASP program Π, sponding to the program that encodes the negation of the
we can use off-the-shelf ASP solvers for several automated property to check, and Πconfig is the following program that
analysis services. In this section, we mainly illustrate how generates arbitrary configurations.
policy verification can be handled by our policy analysis subject_attributes(developer;tester;employee).
approach. action_attributes(read;change).
resource_attributes(codes).
4 We identify Target with the conjunction of its components. Also, we
identify “ ∧ ” with “,”, “ ← ” with “ :- ” and a rule of the form A ← 1{subject(X) : subject_attributes(X)}.
B, C ∨ D as a set of the two rules A ← B, C. and A ← B, D. 1{action(X) : action_attributes(X)}.