On the Use of OWL Reasoning for Evaluating Access Control Policies Fabio Marfia Mario Arrigoni Neri Filippo Pellegrini Politecnico di Milano University of Bergamo Politecnico di Milano DEIB - Department of Department of Computer DEIB - Department of Information, Electronics and Engineering and Mathematical Information, Electronics and Bioengineering Methods Bioengineering Via Ponzio, 34/5 viale Marconi, 5 Via Ponzio, 34/5 20133, Milano - Italy 24044, Dalmine (BG) - Italy 20133, Milano - Italy fabio.marfia@polimi.it mario.arrigonineri@unibg.it filippo1.pellegrini@mail.polimi.it Marco Colombetti Politecnico di Milano DEIB - Department of Information, Electronics and Bioengineering Via Ponzio, 34/5 20133, Milano - Italy marco.colombetti@polimi.it ABSTRACT logically-independent policy management systems has been We present a Description Logics approach to the manage- considered in the last decade. ment of XACML policies. We explain how policies can be mapped to a DL axiomatization, and how authorization re- As a matter of facts, an increasing number of distributed ap- quests can be answered using standard DL reasoning tools. plications have been meeting complex problems in manag- Our model represents a valid substratum for managing poli- ing distribution and access authorizations of contents in the cies whose expressivity can not be captured by standard last years. Description and enforcement of policies can be- engines. Furthermore, advanced security functionalities, as come a very complex task in large systems. An independent Policy Harmonization and Policy Explanation, can be im- Policy Management architecture represents a scalable and plemented in the context of the present model. re-usable environment for: formally specifying policies (Pol- icy Editing and Storing); automatically asserting, according to the specified policies, whether an agent is authorized to Categories and Subject Descriptors commit an act, or not (Policy Evaluation); automatically D.4.6 [Security and Protection]: Access Controls resolving conflicts between policies (Policy Harmonization); generating human-readable explanations of the causes of a General Terms specific policy evaluation (Policy Explanation); eventually Management, Security enforce an agent to commit an act or perpetrate penaliza- tion acts against agents, as a response to policy violations (Policy Enforcement). Keywords Access Control, Policy Languages, Description Logics, Rea- Several standard languages have been defined for the formal soning representation of policies in such type of environment. How- ever, in fact, the current de facto standard in access control 1. INTRODUCTION policy languages is represented by XACML [8]. As data engineers decided to create application-independent logical mechanisms of data storage in the ’60s, and first XACML defines standard protocols for transmitting creden- database systems became available, the chance of modeling tials, requesting resources, defining and storing access poli- cies; together with the definition of a general security layer, made up of different and specialised software components [7]. Such a layer deals with the aforementioned tasks of allow- ing policy administrators to edit and store policies, handling conflicts between contradictory decrees, providing a ultimate response for access requests, together with an explanation of such a response eventually. We present an implementation of an XACML-compliant frame- work in this paper, based on OWL and reasoning technolo- 71 gies. The expression and application of deontic propositions harmonizing conflict between policies, are delegated to is well known in literature, however, as far as we know, this the PAP. is the first time they are applied with the specific aim of providing a solution for an XACML security layer, even if 2. A Domain TBOX, representing a meaningful por- activities for formalizing XACML policies with Description trayal of the application domain. It is arbitrarily ex- Logics (DL) were done in the past, for Policy Harmonization pressive and it is thought to cover the whole collection purposes [3]. of concepts and relations involved in the application domain. Relying many core functionalities on DL reasoning activ- 3. A Domain Assertional BOX (ABOX), gathering ities, performances result worse than any known XACML the different descriptions of the individuals and re- engine’s. Consequently, the present approach has to be con- sources involved in the application domain. They are sidered in cases where current XACML technologies are un- represented as an instantiations of the concepts and able to capture the expressiveness of the policies involved, relations depicted in the Domain TBOX. or as a substratum for providing advanced functionalities as, e.g., Policy Explanation. Both Domain TBOX and ABOX are stored and managed by the PIP. The paper proceeds as follows: we present the modular structure of the framework in Section 2. We explain how DL axioms are generated from a collection of XACML poli- 3. POLICIES AS AXIOMATIC cies, and how policy evaluation is done in Section 3. PROPOSITIONS As presented in Section 2, the PAP allows a policy admin- 2. THE POLICY FRAMEWORK istrator to edit and store policies in the form of an XACML As described in [7], the XACML standard defines a gen- collection. XACML represents the XML-compliant descrip- eral framework for receiving data requests and handling re- tion of the policies in the environment, while the DL form of sponses according to an arbitrarily large collection of poli- the same collection is represented by an OWL TBOX. Poli- cies, that are stored in a repository according to a standard cies are translated from the former representation to the XML-compliant model. The subsequent architectural com- latter automatically. ponents are defined for the framework: Kolovski et al. [3] present how to formalize XACML poli- • Policy Enforcement Point (PEP): Point which in- cies, using a more complex syntax than DL, defined DDL− . tercepts user’s access request to a resource, makes a That is done according to three types of XACML combining evaluation request to the PDP to obtain the access algorithms (see also [7]): permit-overrides, deny-overrides, evaluation (i.e. access to the resource is approved or first-applicable. We decided to reduce the expressivity of rejected), and acts on the received evaluation; the XACML collection specifiable by the PAP, in respect • Policy Decision Point (PDP): Point which evalu- to the aforementioned formalisation, as follows: the policy ates access requests against authorization policies be- collection is reduced to a set of XACML rules, applying ac- fore issuing access responses; cording to the policy combining algorithm deny-overrides only. The algorithm takes into consideration every rule, and, • Policy Administration Point (PAP): Point which then, if both access deny and permit apply, an access deny manages access authorization policies; is returned as a response. Whether nothing is found to be • Policy Information Point (PIP): The system en- applied in the whole set of rules, a final general policy is tity that acts as a source of attribute values; defined in order to deny any access. Such approach allows • Context Handler: the Context Handler deals with to rely on standard DL technologies for reasoning without the coordination of the communications between PDP, involving the DDL− formalisation, obtaining better perfor- PEP and PIP; in particular, it acts in order to return mances and an easier policy representation. We believe that the output of the PDP to the PEP as a response for such simplification is a sufficient approach for satisfying the an access request, consisting eventually in a retrieved requirements of many real-life environments in which, for se- resource. curity reasons, every access is denied ex-ante, while policies are applied for modifying such default behaviour. The technology behind the PEP, that is developed in order to enforce or regulate access to resources, is strongly do- In order for the rules to be properly translated into an OWL main dependent and it is not matter of the current work. TBOX, they can not be expressed arbitrarily: we have then The PDP is provided with a Policy Evaluator component identified five different policy archetypes, according to which that interfaces with a DL Reasoner. Policy evaluations and the policies must be defined. The identified archetypes cover explanations are generated by the PDP as a result of a rea- a wide range of expressiveness, in particular the three stan- soning activity on three different ontologies: dard models IBAC (Identity Based Access Control), RBAC (Role Based Access Control) and ABAC (Attribute Based 1. A Policy Terminological Box (TBOX), that is the Access Control) are covered by the model. expression of the active policies and it is obtained as a result of an algorithmic translation from an XACML The five different policy archetypes are shown in Table 1. collection of policies. Tasks such as providing an in- Each policy can be composed with others using AND or OR terface for policy editing to policy administrators, syn- conjunctions in our model, as foreseen by XACML proto- chronizing the TBOX ontology with XACML policies, col, in order to generate complex rules. Furthermore, each 72 Table 1: Policy Archetypes Access Con- ID Description Example trol Reference A single subject is allowed to access to one or more re- John Andrews can read Healthcare Assistant 1 IBAC sources Documents A group of subjects is allowed to access to one or more Medical Consultants can write a Medical Regula- 2 RBAC resources tion Document Only subjects with specific attributes are allowed to ac- 3 ABAC Females can not read Andrology Documents cess to one or more resources Only subjects in a specific relation with another subject A tutor of a person that is not of age can read 4 ABAC with specific attributes are allowed to access to one or document 305871 more resources Only subjects in a specific relation with another subject A subject can read all the records of the ward 5 N/A are allowed to access to the resources that refer to the he/she works in latter subject policy can be positive or negative, allowing the policy ad- Finally, the negative permission to be annotated, CanNotRead, ministrator to permit or deny access to specific resources. is defined as a superproperty of a specific property chain, as follows: We describe two between the five policy archetypes, together with policy examples, in Section 3.1, while specifying how objectProperty: each type of policy is translated into a set of axioms. We identityOn_hasGender_F_Class o describe how policies can be combined with AND or OR topObjectProperty o conjunctions in Section 3.2. We present how the PDP can identityOn_AndrologyDocument obtain policy evaluations from the generated axioms in Sec- SubPropertyOf: tion 3.3. CanNotRead All the individuals with the dataProperty hasGender value 3.1 Policy Archetypes "F" are connected in this way with the property CanNotRead to each resource belonging to the class AndrologyDocument. 3.1.1 Type 3 - ABAC Simple Policy The Type 3 archetype represents the permission released or denied to a single subject characterized by one or more at- 3.1.2 Type 5 - Triangular Relation Policy The Type 5 policy archetype puts in relation the subject and tributes, for the access to a resource or a group of resources. the resource generating the permission only in the case that A sample XACML Type 3 rule is shown in Table 1, allowing a common individual is in a specific connection with both of every subject with dataProperty hasGender equal to "F" to them. The added permission property represents the side of read the group of resources AndrologyDocument. The pol- a triangle in such a case, where its vertexes are represented icy is translated into a TBOX ontological policy with the by the subject, the resource and the individual in common. subsequent procedure. First, an OWL class is generated, A sample Type 5 rule is shown in Table 1, allowing every containing only the individuals characterized by the afore- subject to read every MedicalRecord of the ward in which mentioned property: he worksIn. Class: The OWL axiomatic expression of such a policy is character- hasGender_F_Class ized by a single property chain expressed as a subproperty equivalentTo: of the involved permission property: hasGender value "F" objectProperty: Then, the functional Identity Property worksIn o identityOn_hasGender_F_Class is defined for the gener- ownsRecord ated class, representing the property of each member of the SubPropertyOf: class pointing to the member itself: canRead Class: hasGender_F_Class 3.2 Combining Policies equivalentTo: As stated, the presented policies can be also expressed to- identityOn_hasGender_F_Class some Self gether in a single XACML rule using AND or OR opera- tors. As it can be understood, each archetype differs from The same is done for the group of resources, represented in the others for the way in which the subject requirements the Domain TBOX ontology by the class AndrologyDocu- are expressed only, while the expression of permission and ment: resources (a single one, or a group) are the same. So, a joined expression of two policies can be, for example, allow- Class: ing a Medic that is male to read every AndrologyDocument. AndrologyDocument That is an expression of a Type 2 + Type 3 policy. equivalentTo: identityOn_AndrologyDocument some Self In case that many policies are joined with an OR conjunc- 73 tion, it is sufficient to translate each policy singularly into a to DL is executed within a reasonable time, Policy Decision TBOX policy. In case that many policies are joined with an performances are worse than any known XACML engine, in AND conjunction, the approach changes whether none, one the order of 100x in time approximately. Anyway, we believe or more Type 5 policy are present. In case that no Type 5 that our solution can be a reasonable alternative in a real- policy is present, a new class is defined as an intersection of life scenario to ordinary XACML engines for the subsequent all the classes that identify the subject requirements for ev- reasons: ery policy. Then, a new Identity Property is created for the class and the positive or negative permission is assigned as • An optimized code and an efficient hardware can sup- a superproperty of the property chain between the created port a usable PDP engine for real-time interactions in Identity Property, the topOjbectProperty and the Identity real-life environments; Property on the resources, as it is done for any of the Type • DL expressiveness can be used to define policies which 1 to 4 archetypes. complexity can not be caught by ordinary XACML engines; In case that one Type 5 policy is present, a new class is defined as an intersection of all the classes that identify the • External applications can generate interesting portrays subject requirements for every policy of Type 1 to 4. Then, of the regulation state by accessing to the framework a new Identity Property is created for the class and the posi- semantics for an end-user; tive or negative permission is assigned as a superproperty of • Automatic agents may regulate their behaviour by read- the property chain between the just created Identity Prop- ing and reasoning on provided policies; erty and the two object properties involved in the Type 5 • Advanced complex tasks can be exploited that are al- policy. most impossible for ordinary XACML frameworks; as Policy Explanation, or Policy Harmonization. Expression of an axiomatic policy is not possible, using DL, in case of AND conjunction between more than one Type Policy Explanation can be provided together with the re- 5 policies. That because specification of double paths be- sponse using OWL Explanation technology [2], as already tween the same identities is involved, and it is not possible. done by Marfia [4]. A Policy Harmonization service based However, the issue can be addressed using SWRL Rules [6]. on the OWL policy representation can be developed for the framework, accordingly to what presented by Kolovski et al. 3.3 Policy Evaluation [3]. Once the XACML policies are correctly translated into a Policy TBOX by the PAP, when the PDP receives an XACML access request from the Context Handler (more formally, an 5. REFERENCES [1] DL Query guide - Protégé DLQueryTab. XACML Context [7]), it retrieves the Policy TBOX from the http://protegewiki.stanford.edu/wiki/DLQueryTab, PAP and the Domain TBOX and ABOX from the PIP. 2008. After that, the task of Policy Evaluation reduces itself to [2] M. Horridge, B. Parsia, and U. Sattler. Laconic and the process of querying the set of the retrieved ontologies, Precise Justifications in OWL. In Proceedings of the 7th for verifying whether they logically entail or not two spe- International Conference on The Semantic Web, ISWC cific theorems: the one stating that the subject can do the ’08, pages 323–338, Berlin, Heidelberg, 2008. requested action on the requested resource (positive permis- Springer-Verlag. sion theorem), and the one stating that the subject can not [3] V. Kolovski, J. Hendler, and B. Parsia. Analyzing Web do the requested action on the requested resource (negative Access Control Policies. In Proceedings of the 16th permission theorem). International Conference on World Wide Web, WWW ’07, pages 677–686, New York, NY, USA, 2007. ACM. Whether only the positive permission theorem is found, a [4] F. Marfia. Using Abductive and Inductive Inference to positive authorization is returned by the PDP to the Con- Generate Policy Explanations. In M. Obaidat, text Handler. A negative authorization is returned in any A. Holzinger, and P. Samarati, editors, Proceedings of other case. As an example, we can assume that the per- International Conference on Security and Cryptography mission request for john_andrews to read the document (SECRYPT 2014). SciTePress, 2014. document_305871 is received by the PDP from the Context [5] A. Mourad and H. Jebbaoui. SBA-XACML: Set-based Handler. Two DL queries [1] are sent, then, to the set of approach providing efficient policy decision process for ontologies for retrieving the two subsequent theorems: accessing Web services. Expert Syst. Appl., 42(1):165–178, 2015. 1. john_andrews canRead document_305871. [6] SWRL: A Semantic Web Rule Language Combining 2. john_andrews canNotRead document_305871. OWL and RuleML. http://www.w3.org/Submission/SWRL/, 2004. If theorem 1 is found only, the response of the PDP is a [7] OASIS XACML Version 3.0 Specification. positive authorization. Otherwise, the response is a negative http://docs.oasis-open.org/xacml/3.0/xacml-3. authorization. 0-core-spec-cs-01-en.pdf, 2013. [8] OASIS eXtensible Access Control Markup Language 4. CONCLUSION AND FUTURE WORK (XACML). We measured the algorithm performances in respect to the https://www.oasis-open.org/committees/xacml/, best known XACML engines [5]. While policy conversion 2013. 74