Ontology-based Access Control Policy Interoperability Quentin Reul (STARLab), Gang Zhao (STARLab), and Robert Meersman (STARLab)
1. Introduction The TAS3 (Trusted Architecture for Securely Shared Services) project aims to develop an open, secure and trusted architecture for the exchange of personal data across distributed services. As personal data is generated over a human life, it is collected and stored at distributed locations and is used by a multitude of services. In the employability domain, for instance, a person is continuously learning new competences not only based on her education history, but also based on her employment experience. Such service-oriented architecture (SOA) relies on semantic interoperability to enable secure access to personal data based on a common vocabulary. For example, the eXtensible Access Control Markup Language (XACML) [1] provides a XML-based syntax enabling a Policy Decision Point (PDP) to determine whether a request to access a resource should be granted, and to return an answer to a Policy Enforcement Point (PEP), which allows or denies access to the resource. However, XACML is merely a data model as it lacks the element of semantic agreement beyond the boundary of the organization that developed it. Thus, semantic interoperability across services based on XACML alone is not feasible. Semantic Web technologies provide the means to address this problem. The Semantic Web [2] extends the current World Wide Web (WWW) with resources in machine-understandable format. For instance, the actions and resources that are subject to access control policies can be given meaning through the use of ontologies. An ontology is commonly defined as: “a formal, explicit specification of a shared conceptualization” [3]. More specifically, an ontology is a server stored unambiguous and flexible meaning agreement on the semantics of concepts and the relations between them in a given domain. In this paper, we present security policy ontology based on the DOGMA (Developing Ontology-Grounded Methods and Applications) framework [4]. Given this security policy ontology and ontologies representing their respective security domains, services requesters (SRs) and service providers (SPs) interoperate with each other with the facility of interpretation of attribute types and their values in a request. More specifically, the security attributes of the SR in a Security Domain A can be evaluated by the PDP of the SP in a Security Domain B based on their ontological annotations. Thus, this approach removes the impractical restriction on SRs and SPs in distributed environment to share identical vocabularies to describe the conceptual model of their respective security domains. The rest of the paper is organised as follows. In section 2, we describe the DOGMA framework, while the next section presents the developed security policy ontology. Section 4 describes how semantic interoperability can be achieved when evaluating access control policies in the TAS3 project, while the final section concludes on the work done so far and outlines future work.
2. Background DOGMA [4] is a formal ontology engineering framework that is not restricted to a particular representation language. Moreover, DOGMA makes a distinction between the lexical representation of concepts and their semantic constraints. This strict separation is known as the double articulation principle [5], and aims to enhance the potential for reuse and scalability. This results from the fact that it is easier to reach an agreement on the conceptualization rather than on domain rules [6]. Consequently, the DOGMA framework consists of two layers; namely the lexon base and the commitment layer. The lexon base layer stores plausible binary fact-types, called lexons. A lexon is fomally described as a 5-tuple , where the context
identifier (i.e. ! ) is used to group lexons that are logically related to each other in the conceptualization of a domain. Intuitively, a lexon may be read as: within the context !, head may have a relation with tail in which it plays a role, and conversely, in which tail plays a corresponding co-role. For example, the lexon can be read as: in the context Research, Author plays the role of writes Book and Book plays the role of being written by Author. The goal of the lexon base is to reach a common and agreed understanding about the ontology terminology and is thus aimed at human understanding. The commitment layer mediates between the lexon base layer and its application. More specifically, it consists of a set of lexons from the lexon base that approximate well the intended conceptualization, followed by the addition of a set of constraints and/or rules. An important difference with the lexon base layer is that commitments are semantically unambiguous and consistent. For example, MAND([Research, Author, writes, Book]) express that an author has written at least one book. Moreover, the commitment layer provides mappings between the ontology and the data layer (e.g. databases).
3. Security Policy Ontology A security policy imposes constraints governing the behaviour of a system [7]. More specifically, a security policy defines a set of conditions, which are evaluated to determine whether a set of actions may be performed on a resource. For example, an access control policy could state that only placement advisors (i.e. the condition) have the right to consult (i.e. the action) the CV of a student (i.e. the resource). Table 1: Lexons representing the concept of security policy. Context TAS3Policy TAS3Policy TAS3Policy TAS3Policy TAS3Policy TAS3Policy TAS3Policy TAS3Policy
Head term SecurityPolicy SecurityPolicy SecurityPolicy SecurityPolicy SecurityPolicy SecurityPolicy SecurityPolicy Person
role specifies controls has has has has written-by is-a
co-role specified-by controlled-by Of Of Of Of Writes Subsumes
Tail term Condition Action Resource Effect Identifier Description Person Agent
Table 1 provides the conceptualization of security policy based on lexons. The effect of a security policy provides a statement committing the system to enact the action articulated in the policy. For example, the effect of an access control policy would be to grant or deny access to a resource. In distributed systems, every security policy is given an identifier (e.g. URN) to uniquely refer to it within an information system as well as a natural language description of what the policy actually does. A security policy is written by an person (e.g. system admin) and is recorded to provide provenance. The rest of this section first describes the concepts of Condition, Action, and Resource in more detail. Then, we demonstrate how these concepts can be used to represent access control policies. 3.1 Core Elements A condition determines whether or not an action should be performed. In other words, conditions specify the environment (i.e. the descriptor) for an action to be executed (Table 2). For example, an access control policy could state that students can only enter the university library if it is a weekday and that the time is between 9am and 5pm. Descriptors, such as time and location, express the condition of a security policy.
Table 2: Lexons representing the concept of condition. Context TAS3Policy TAS3Policy TAS3Policy TAS3Policy
Head term Condition Descriptor Descriptor Descriptor
role has subsumes subsumes subsumes
co-role
Tail term Descriptor Time Location Attribute
Of is-a is-a is-a
An action is an event that an agent seeks to perform (Table 3). Note that an action can either be a simple operation, or a bundle of complex operations provided as an integrated set. Note also that an action is given a list of parameters (i.e. attributes) defining how the action must be performed. Table 3: Lexons representing the concept of action. Context TAS3Policy TAS3Policy TAS3Policy TAS3Policy TAS3Policy
Head term Event Action Action Action Parameter
role performed-by is-a controlled-by has is-a
co-role Performs Subsumes Controls Of Subsumes
Tail term Agent Event SecurityPolicy Parameter Attribute
model, permissions are assigned to security attributes, and those security attributes are assigned to an agent to perform one or more actions on one or more resources. In a network environment, a security attribute may describe any property of the agent, such as its network address or its identity (e.g. passport number, login ID, or email address).
4. Ontology-based Interoperability During access control evaluation, a service request (SR) will send among other things information about its security attributes to be granted access to a resource by a service provider (SP). The parameters of the request includes the actions (A) to be performed on which resource (R) and the list of attribute types and values ({(T,V)}) associated with the SR (Figure 1). Based on this information, the SP will then determine whether the security attributes are equivalent to those stated in the conditions of its access control policy. If the two parties use the same vocabulary for expressing their respective attribute types and values, then the process is straightforward.
A resource is an entity on which an action is performed and is described by descriptors (Table 4). A resource can therefore be anything e.g. data, or an agent. For example, in TAS3, security policies (in the form of access control policies) are imposed to protect inappropriate behaviour on personal data. Table 4: Lexons representing the concept of target. Context TAS3Policy TAS3Policy TAS3Policy TAS3Policy TAS3Policy
Head term Resource Resource Resource Object PersonalData
role subsumes subsumes described-by subsumes identifies
co-role is-a is-a Describes is-a identified-by
Tail term Agent Object Descriptor PersonalData Person
3.2 Access Control Policy An access control policy [8] determines who is authorized to access a resource. A permission grants the right to an agent to perform an action on a resource. In general, a PEP enforces the action of an access control policy after the evaluation of its condition by a PDP. In the eHealth domain, for example, a doctor may be able to consult (i.e. the action) the content of his patient’s record (i.e. the target) once she has gained access to it. In general, a PEP enforces the action of an access control policy after the evaluation of its condition by a PDP. Table 5: Lexons representing the concept of access control policy. Context TAS3Policy TAS3Policy TAS3Policy TAS3Policy TAS3Policy TAS3Policy TAS3Policy TAS3Policy TAS3Policy TAS3Policy
Head term AccessControlPolicy AccessControlPolicy Access Access ABACPolicy ABACPolicy SecurityAttribute Permission SecurityAttribute SecurityAttribute
role is-a controls is-a on is-a has has grants assigned-to has
co-role subsumes controlled-by subsumes under subsumes of assigned-to granted-by has of
Tail term SecurityPolicy Access Action Resource AccessControlPolicy SecurityAttribute Permission Action Agent Validity
Several models for access control policies have been proposed over the years [9]. In TAS3, we focus on Attribute-Based Access Control (ABAC) policies [10]. ABAC policies control the access to resources based on the security attributes assigned to a user (Table 5). In the ABAC
Figure 1: Traditional Access Control Policy Evaluation
However, it would be unrealistic to assume that two parties from different application and/or security domains would be prepared to adopt identical terms for the disclosure of security attributes and conditions in access control policy evaluation. We can identify two scenarios for which it is essential to achieve semantic interoperability between the two parties. Firstly, the SR and the SP share the same vocabulary for the attribute types, but use different vocabularies to represent their values. For example, the two-parties share the term “function” to represent the attribute types, but the value given by the SR is “doctor” whereas the SP is expecting “practitioner”. This example leads to the SP refusing to grant access to the SR even though the attribute values share some common semantics. Secondly, the two parties use different vocabularies to represent the attribute types and their values. If the attribute types and values are annotated with concepts from the security policy ontology and extended to represent specific security domains, then we can interpret whether these attributes are equivalent. In this approach, an annotation is a set of lexons representing the links between concepts and serves as a semantic definition for the security attributes and conditions. Thus, annotations can be used during the policy evaluation process (i) to disambiguate different denotation of the same security attribute, and (ii) to detect the generalization/specialisation between security attributes (e.g. the generic requirement can be satisfied by a more specific fulfilment). Figure 2 describes the role of the ontology in achieving semantic interoperability across services in different security domains. In this case, a request is made to a service provider, which sends the request to its PDP to be evaluated. The PDP determines that the security attributes provided by the SR are different from those expected in the condition. Instead of directly denying access the SR, the PDP contact an Interpreter service to evaluate whether the attribute types and their values are equivalent. Based on their annotations, the Interpreter will either transform the attribute types and values to the local vocabulary or return the original security attributes. The PDP then re-evaluate the credentials to decide whether to grant or deny access to the SR. As a result, this approach removes the impractical restriction on SRs
and SPs in distributed environment to share identical vocabularies to describe the conceptual model of their respective security domains.
[6] Meersman, R. (2002). Web and ontologies: Playtime or business at the last frontier in computing?, Proc. of the Workshop on Database and Information Systems Research for Semantic Web and Enterprises, pp. 61–67. [7] Sloman, M., and Lupu, E. (2002). Security and Management Policy Specification, IEEE Network Special Issue on Policy Based Networking, 16(2):10-19. [8] Sandhu, R., and Samarati, P. (1994). Access Control: Principles and Practice, IEEE Communication Magazine, pp. 40-48. [9] Samarati, P., and De Capitani di Vimercati, S. (2001). Access Control: Policies, Models, and Mechanisms. Foundation of Security Analysis and Design, pp. 137-196. [10] Yuan, E., and Tong, T. (2005). Attribute Based Access Control (ABAC) for Web Services. Proc. 3rd International Conference on Web Services (ICWS 2005), pp. 561–569. Authors
Figure 2: Interoperability in Access Control Policy Evaluation.
5. Conclusion and Future Work In this paper, we first presented a security policy ontology based on the DOGMA framework. This ontology covers the core elements of security policies (i.e. Condition, Action, Resource) and can easily be extended to represent specific security policies, such as access control policies. Note that the implementation of security policies requires the user to represent their security domain with specific ontologies. Secondly, we proposed a solution to semantic interoperability when evaluating access control policies in distributed environment. More specifically, we showed how the security policy ontology could be used to interpret the attribute types and their values exchanged by SRs and SPs in different security domain. As a result, this approach removes the impractical restriction on SRs and SPs in distributed environment to share identical vocabularies to describe the conceptual model of their respective security domains.
6. Acknowledgements The research leading to these results has received funding from the EC's FP7 programme under grant agreement n° 216287 (TAS! - Trusted Architecture for Securely Shared Services). We would like to thank D. Chadwick and L. Shi from the University of Kent for their expertise on security policies. References [1] OASIS Standard. (2005). eXtensible Access Control Markup Language (XACML) Version v2.0. Available at http://www.oasis-open.org/specs/index.php#xacmlv2.0 [2] Berners-Lee, T., Hendler, J. and Lasilla, O. (2001). The Semantic Web, Scientific American, May, pp. 34-43. [3] Gruber, T. (1993). Towards principles for the design of ontologies used for knowledge sharing, Formal Ontology in Conceptual Analysis and Knowledge Representation, pp. 907928. [4] Meersman, R. (1999). Semantics ontology tools in information system design, Proc. of the International Symposium on Methodologies for Intelligent Systems (ISMIS99). [5] Spyns, P., Meersman, R., and Jarrar, M. (2002). Data modelling versus ontology engineering, SIGMOD Record Special Issue on Semantic Web, Database Management and Information Systems, 31(4):12-17.
Mr. Quentin Reul VUB STARLab Pleinlaan 2, B-1050 Brussels
[email protected] Dr. Gang Zhao VUB STARLab Pleinlaan 2, B-1050 Brussels
[email protected] Prof. Robert Meersman VUB STARLab Pleinlaan 2, B-1050 Brussels
[email protected]
