P. 1
Ontology-Based Access Control Policy Interoprability

Ontology-Based Access Control Policy Interoprability

|Views: 9|Likes:
Published by Auxilia Richard

More info:

Published by: Auxilia Richard on Apr 26, 2013
Copyright:Attribution Non-commercial

Availability:

Read on Scribd mobile: iPhone, iPad and Android.
download as PDF, TXT or read online from Scribd
See more
See less

12/19/2014

pdf

text

original

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.

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 <Research, Author, writes, written by, Book> 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.

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 <! , head, role, co-role, tail>, where the context

Table 2: Lexons representing the concept of condition. Secondly. In the eHealth domain. The PDP then re-evaluate the credentials to decide whether to grant or deny access to the SR.e. Firstly. In general. Context TAS3Policy TAS3Policy TAS3Policy TAS3Policy Head term Condition Descriptor Descriptor Descriptor role has subsumes subsumes subsumes Of is-a is-a is-a co-role Tail term Descriptor Time Location Attribute model. 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. The PDP determines that the security attributes provided by the SR are different from those expected in the condition.e. Table 4: Lexons representing the concept of target. For example. such as its network address or its identity (e.e.V)}) associated with the SR (Figure 1). 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 A resource is an entity on which an action is performed and is described by descriptors (Table 4). and (ii) to detect the generalization/specialisation between security attributes (e. Thus. If the two parties use the same vocabulary for expressing their respective attribute types and values. A permission grants the right to an agent to perform an action on a resource. 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 However. We can identify two scenarios for which it is essential to achieve semantic interoperability between the two parties. 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. In a network environment.g. this approach removes the impractical restriction on SRs Several models for access control policies have been proposed over the years [9]. or a bundle of complex operations provided as an integrated set. passport number. A resource can therefore be anything e. If the attribute types and values are annotated with concepts from the security policy ontology and extended to represent specific security domains. security policies (in the form of access control policies) are imposed to protect inappropriate behaviour on personal data. login ID. a PEP enforces the action of an access control policy after the evaluation of its condition by a PDP. data. This example leads to the SP refusing to grant access to the SR even though the attribute values share some common semantics. an annotation is a set of lexons representing the links between concepts and serves as a semantic definition for the security attributes and conditions. In this approach. which sends the request to its PDP to be evaluated. or an agent. Based on this information. in TAS3. we focus on Attribute-Based Access Control (ABAC) policies [10]. a security attribute may describe any property of the agent. In TAS3. 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). but the value given by the SR is “doctor” whereas the SP is expecting “practitioner”. Instead of directly denying access the SR. a doctor may be able to consult (i. or email address). but use different vocabularies to represent their values. the action) the content of his patient’s record (i. An action is an event that an agent seeks to perform (Table 3).2 Access Control Policy An access control policy [8] determines who is authorized to access a resource. a request is made to a service provider. 4. In this case. Note also that an action is given a list of parameters (i. the two-parties share the term “function” to represent the attribute types. Table 3: Lexons representing the concept of action. permissions are assigned to security attributes. Based on their annotations. attributes) defining how the action must be performed. For example. the PDP contact an Interpreter service to evaluate whether the attribute types and their values are equivalent. the target) once she has gained access to it. Table 5: Lexons representing the concept of access control policy. In general. the SR and the SP share the same vocabulary for the attribute types. In the ABAC . and those security attributes are assigned to an agent to perform one or more actions on one or more resources.g. ABAC policies control the access to resources based on the security attributes assigned to a user (Table 5). the Interpreter will either transform the attribute types and values to the local vocabulary or return the original security attributes. for example. Figure 2 describes the role of the ontology in achieving semantic interoperability across services in different security domains. a PEP enforces the action of an access control policy after the evaluation of its condition by a PDP. 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 Figure 1: Traditional Access Control Policy Evaluation 3. the two parties use different vocabularies to represent the attribute types and their values. then the process is straightforward. then we can interpret whether these attributes are equivalent. Ontology-based Interoperability During access control evaluation. As a result. Note that an action can either be a simple operation. the SP will then determine whether the security attributes are equivalent to those stated in the conditions of its access control policy. the generic requirement can be satisfied by a more specific fulfilment).g. annotations can be used during the policy evaluation process (i) to disambiguate different denotation of the same security attribute.

Security and Management Policy Specification. such as access control policies. and Samarati. pp. (1994). [7] Sloman. and Lasilla.be Prof. (2005).be Dr.org/specs/index. Data modelling versus ontology engineering.. T. IEEE Communication Magazine. (2005).. 5. (2001).reul@vub.ac. [3] Gruber. Robert Meersman VUB STARLab Pleinlaan 2. pp. Access Control: Policies. Secondly. References [1] OASIS Standard. and Mechanisms . 40-48. R. Note that the implementation of security policies requires the user to represent their security domain with specific ontologies. E. P. pp. [6] Meersman. 137-196. eXtensible Access Control Markup Language (XACML) Version v2. P. (1993). 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. 31(4):12-17. and Jarrar. pp.0. Authors Mr. Chadwick and L. IEEE Network Special Issue on Policy Based Networking. M. Database Management and Information Systems. We would like to thank D. 6...be Figure 2: Interoperability in Access Control Policy Evaluation. 16(2):10-19.Trusted Architecture for Securely Shared Services). Scientific American. This ontology covers the core elements of security policies (i. B-1050 Brussels quentin. and De Capitani di Vimercati. and Tong. 561–569. we proposed a solution to semantic interoperability when evaluating access control policies in distributed environment. M. . As a result.. Semantics ontology tools in information system design. Meersman.php#xacmlv2. [10] Yuan. 34-43. More specifically.0 [2] Berners-Lee. 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.. Shi from the University of Kent for their expertise on security policies. Access Control: Principles and Practice. Towards principles for the design of ontologies used for knowledge sharing. of the International Symposium on Methodologies for Intelligent Systems (ISMIS99). [9] Samarati. pp. J. Attribute Based Access Control (ABAC) for Web Services. Condition. Quentin Reul VUB STARLab Pleinlaan 2. Proc. Conclusion and Future Work In this paper. [8] Sandhu. (2001). 907928. Resource) and can easily be extended to represent specific security policies. E. The Semantic Web. B-1050 Brussels meersman@vub. Proc. Available at http://www. Web and ontologies: Playtime or business at the last frontier in computing?. pp. P.ac. [4] Meersman. Proc. Models. Action. May. R. Acknowledgements The research leading to these results has received funding from the EC's FP7 programme under grant agreement n° 216287 (TAS! . 61–67. (2002). Hendler. Formal Ontology in Conceptual Analysis and Knowledge Representation.and SPs in distributed environment to share identical vocabularies to describe the conceptual model of their respective security domains. T. [5] Spyns. SIGMOD Record Special Issue on Semantic Web. R. (1999).e. S. R..ac. T. and Lupu. (2002).zhao@vub. of the Workshop on Database and Information Systems Research for Semantic Web and Enterprises. we first presented a security policy ontology based on the DOGMA framework. O. Foundation of Security Analysis and Design. 3rd International Conference on Web Services (ICWS 2005).oasis-open. Gang Zhao VUB STARLab Pleinlaan 2. B-1050 Brussels gang. (2002).

You're Reading a Free Preview

Download
scribd
/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->