The Logic of XACML - Extended

In order to manage modularity in access control, XACML constructs policies into several components, namely PolicySet, Policy and Rule. A PolicySet is a collection of other PolicySets or Policies whereas a Policy consists of one or more Rules. A Rule is the smallest component of XACML policy and each Rule only either grants or denies an access. As an illustration, suppose we have access control policies used within a National Health Care System. The system is composed of several access control policies of local hospitals. Each local hospital has its own policies such as patient policy, doctor policy, administration policy, etc. Each policy contains one or more particular rules, for example, in patient policy there is a rule that only the designated patient can read his or her record. In this illustration, both the National Health Care System and local hospital policies are PolicySets. However the patient policy is a Policy and one of its rules is the patient record policy. Every policy is only applicable to a certain target and a policy is applicable when a request matches to its target, otherwise, it is not applicable. The evaluation of composing policies is based on a combining algorithmthe procedure for combining decisions from multiple policies. There are four standard combining algorithms in XACML i.e., (i) permit-overrides, (ii) deny-overrides, (iii) first-applicable and (iv) only-one-applicable.

The syntax of XACML is based on XML format [2], while its standard semantics is described normatively using natural language in [14]. Using English paragraphs in standardization leads to misinterpretation and ambiguity. In order to avoid this drawback, we define an abstract syntax of XACML 3.0 and a formal XACML components evaluation based on XACML 3.0 specification in Section 2. Furthermore, the evaluation of the XACML combining algorithms is explained in Section 3.

Recently there are some approaches to formalizing the semantics of XACML. In [8], Halpern and Weissman show XACML formalization using First Order Logic (FOL). However, their formalization does not capture whole XACML specification. It is too expensive to express XACML combining algorithms in FOL. Kolovski et al. in [10,11] maps a large fragment of XACML to Description Logic (DL) -a subset of FOLbut they leave out the formalization of only-one-applicable combining algorithm. Another approach is to represent XACML policies in term of Answer Set Programming (ASP). Although Ahn et al. in [3] show a complete XACML formalization in ASP, their formalization is based on XACML 2.0, which is out-of-date nowadays. More particular, the combining algorithms evaluation in XACML 2.0 is simpler than XACML 3.0. Our XACML 3.0 formalization is closer to multi-valued logic approach such as Belnap logic [4] and D-algebra [13]. Bruns et al. in [5,6] and Ni et al. in [13] define a logic for XACML using Belnap logic and D-algebra, respectively. In some cases, both methods show different results from the XACML standard specification. We discuss the shortcoming of formalization based either on Belnap logic or on D-algebra in Section 4 and we conclude in Section 5.

XACML syntax is described verbosely in XML format. For our analysis purpose, we do abstracting XACML components. From the abstraction, we show how XACML evaluates policies. We give an example how XACML policies can be described in our abstraction and the components evaluation at the end of this section.

There are three main policy components in XACML, namely PolicySet, Policy and Rule. PolicySet is the root of all XACML policies. A PolicySet is composed of a sequence of other PolicySet or Policy components along with a policy combining algorithm ID and a Target. A Policy is composed of a sequence of Rule, a Target and a rule combining algorithm ID. A Rule is a single entity that defines the individual rule in the policy. Each Rule has a particular effect to an access request, i.e., either deny or permit the access. Each Rule is composed of a Target and a Condition. A Target is an XACML component that indicates under which categories an XACML policy is applicable. A Target consists of conjunction of AnyOf component with each AnyOf consists of disjunction of AllOf components and each AllOf consists of conjunction of Match. Each Match contains only one particular category to be matched with the request. Typical categories of XACML attributes are subject category (e.g. human user, workstation, etc) action category (e.g. read, write, delete, etc), resource category (e.g. dat