TY - JOUR
AU - Colman,, Alan
AB - Abstract In today’s dynamic ICT environments, the ability to control users’ access to information resources and services has become ever important. On the one hand, it should provide flexibility to adapt to the users’ changing needs, while on the other hand, it should not be compromised. The user is often faced with different contexts and environments that may change the user’s information needs. To allow for this, it is essential to incorporate the dynamically changing context information into the access control policies to reflect different contexts and environments through the use of a new context-aware access control (CAAC) approach with both dynamic associations of user-role and role-permission capabilities. Our proposed CAAC framework differs from the existing access control frameworks in that it supports context-sensitive access control to information resources and dynamically re-evaluates the access control decisions when there are dynamic changes to the context. It uses the dynamic context information to specify the user-role and role-permission assignment policies. We first present a formal policy model for our framework, specifying CAAC policies. Using this model, we then introduce a policy ontology for modeling CAAC policies and a policy enforcement architecture which supports access to resources according to the dynamically changing context information. In addition, we demonstrate the feasibility of our framework by considering (i) the completeness, correctness and consistency of the ontology concepts through application to healthcare scenarios and (ii) the performance and usability testing of the framework when using desktop and mobile-based prototypes. 1. INTRODUCTION Access control is one of the fundamental security mechanisms needed to protect resources against unauthorized access according to a security policy. It verifies whether a user is allowed to carry out a specific action on a resource. However, the access control decision making processes in today’s dynamic environments are not straightforward. In particular, the expected security mechanisms towards this end need to be context-aware in order to cope with highly dynamic environments, thus taking into account the context information [2, 3] (e.g. the location and request time of the users) so that they can adapt themselves to changing situations. This paradigm shift brings new challenges. On the one hand, users demand access to resources in an anytime, anywhere fashion. On the other hand, such access has to be carefully controlled due to the additional challenges coming with the dynamically changing environments. One such challenge is how to incorporate the dynamically changing context information into the access control policies, to make appropriate and yet possibly different decisions as the user’s contextual situation changes. In the literature, a significant number of access control approaches towards this end have been developed over the last couple of decades ranging from general approaches to application-specific approaches. A recent study shows that role-based access control (RBAC) [4–6] has become the most widely used access control approach [7]. It has received broad support as a general approach to access control, and is well recognized for its many advantages in large-scale authorization management [8]. RBAC typically evaluates access permission through roles assigned to users and each role assigns a collection of permissions to users who are requesting access to the resources [4, 5]. It simplifies the management of access control policies by creating user-role and role-permission mappings. However, the basic RBAC approach does not provide adequate functionality to incorporate and adapt to the dynamically changing context information of users. For example, a nurse can access a patient’s medical information in the hospital while on duty, but should not access such information while on a public bus heading home. Context-aware access control is a security mechanism needed to provide flexible control of users’ access to resources according to the currently available context information [9]. Over the last decade, a number of context-aware access control approaches have been developed, extending the basic RBAC approach by incorporating some specific types of context information: temporal information (e.g. [10, 11]), spatial information (e.g. [12]), and both time and location (e.g. [13]). Recently, several works have extended the basic RBAC approach, considering further context information other than the temporal and spatial dimensions, such as the resource and environment dimensions as well as the user dimension [14–18]. These access control approaches are highly domain-specific and still limited in capturing a wide range of important context information for context-aware user-role and role-permission assignments. This gap in the literature suggests that there is a need for a new policy model and framework for context-aware access control of software services or information resources. Consider the roles of patients and nurses in a hospital context. A nurse Mary can be allowed to access the medical health records of a patient Bob, if she has been assigned to look after Bob but only when she is located in the general ward and during her ward shift time. That is, Mary can play the nurse role and consequently can access Bob’s medical health records if these contextual conditions are fulfilled. The contextual conditions can be used for dynamically performing user-role and role-permission assignments. Therefore, an access controller needs to evaluate such contextual conditions when enabling user-role and role-permission assignments. As such kinds of dynamic attributes (contextual conditions) need to be integrated into the basic role-based access control approach, some important issues arise to realize flexible and dynamic access control. In general, in order to achieve context-awareness and integrate the dynamic attributes into the access control processes, the following research issues need to be addressed: (R1) How to specify context-aware user-role assignment policies in order to dynamically assign users to roles according to the relevant context information? (R2) How to specify context-aware role-permission assignment policies in order to dynamically assign roles to permissions according to the relevant context information? (R3) How to enforce and evaluate context-aware user-role and role-permission assignment policies in order to provide context-aware resource access permissions to users? 1.1. The contributions To address the above-mentioned research challenges and issues, the overall goal of this paper is to develop a new Context-Aware Access Control (CAAC) Policy Framework, that is capable of providing secure access to resources and services according to the dynamically changing contexts. It makes the following key contributions: (C1) Formal policy model: We propose a formal policy model that extends the basic RBAC policy model. The novel feature of our policy model is a formal language for specifying the elements of our framework, specifically addressing the following aspects. Context-aware user-role assignment (CAURA): Our policy model uses the relevant context information to specify user-role assignment policies. We take context information to mean any information that can be used to characterize the state of a relevant entity or the state of a relevant relationship between entities. Context-aware role-permission assignment (CARPA): Our policy model uses the relevant context information to specify context-aware role-permission assignment policies. Context specification language (CSL): Our policy model includes a context specification language (CSL) for expressing simple and complex contexts. The simple contexts are the basic low-level context information that is directly obtained from entities and the complex contexts are derived from other basic or complex context information. The simple and complex contexts are used to express the contextual conditions (in the form of contextual expressions) which are required in specifying context-aware user-role and role-permission assignment policies. (C2) Policy ontology: Based on the above aspects, we introduce a policy ontology for modeling context-aware access control (CAAC) policies (i.e. user-role and role-permission assignment policies) that take into account the relevant context information. The policy ontology represents the basic elements using the ontology languages OWL and SWRL. (C3) Policy enforcement architecture: A policy enforcement architecture (PEA) is introduced that supports context-specific control over access to information resources. (C4) Evaluation: Other than the above three contributions, this paper also justifies the feasibility of the policy ontology model and framework. The feasibility is demonstrated by evaluating the completeness, correctness and consistency of the ontology model components through a healthcare case study, the performance of the policy framework in terms of response time and the usability of the framework in a real setup. Completeness: Covering our policy model features, a detailed case study (including two test cases) from the healthcare domain is presented which demonstrates the completeness of the application of our proposed model components. Correctness and consistency: Assessing the base and domain-specific ontologies and executing some queries against the healthcare case study, we have evaluated the correctness and consistency of the ontology model semantics. Performance: In order to demonstrate the feasibility of our policy framework, we have conducted a set of experiments in a healthcare environment and quantified the performance overhead of our proposed framework. Usability: In order to demonstrate the practical applicability of the policy framework, we have conducted a usability study in our laboratory setup and with real users. Overall, we have demonstrated the functionality of our proposed CAAC framework using our desktop and mobile-based prototypes. Our preliminary CAAC framework has been introduced in [1], mainly including a policy model for specifying and enforcing CAAC policies. This article consolidates and extends our initial CAAC policy framework and the significant extensions are listed as follows: (E1) We have now extended the motivating scenario, mainly including the analysis of the scenario and its associated requirements for context-sensitive user-role and role-permission assignment policies, whereas our earlier paper [1] lacks the detailed analysis and the general requirements for developing dynamic CAAC applications. (E2) For the theoretical formulation of the policy model, we have now elaborated the formal policy model with details, including the background of our CAAC policy model by extending the basic RBAC policy model [5], the context specification language for expressing different contextual conditions, and the user-role and role-permission assignment policies separately. (E3) We have made significant extension to our policy ontology to model both the two sets of CAAC policies (for user-role and role-permission assignments). In particular, we have included the details of user-role and role-permission policy specifications using ontology languages OWL and SWRL (presented in Appendices A and B), whereas our earlier ontology lacks such representations. (E4) This paper extends our earlier software prototype for building CAAC applications. We have now introduced our prototype architecture, described its components and presented the detailed implementation of the components in the desktop and mobile-based settings. In particular, we have provided mechanisms and tool support for modelling and enforcing CAAC policies. Using both of our prototypes, we have analyzed the access control requests for different users with respect to different locations, times and relationships. In addition, we have demonstrated the context-sensitive access control decisions when there are dynamic changes to the context. (E5) This paper justifies the feasibility of our proposed framework by demonstrating the completeness, correctness and consistency of the policy ontology through application to healthcare case scenarios, the performance of the framework in terms of query response time and the usability testing in a real laboratory setup. Whereas, in our earlier CAAC framework [1], the evaluation only has been demonstrated via a simple case study. (E6) We have set out a complaints handling process which allows reviews and potential changes to the access control decisions and if appropriate that leads to a refinement of the policies and the ontology. This is implemented during the experiments conducted. (E7) This paper also summarizes our experience to build new CAAC applications in today’s context-sensitive dynamic world, including technical issues and challenges that have been found in our laboratory setup. (E8) In this article, we review the existing research on role-based access control in the context of the dynamically changing information (e.g. the interpersonal relationships). Finally, we present the results of our comparative study with respect to relevant state-of-the-art methods, whereas our earlier paper lacks such comparative results. 1.2. The organization of our paper The rest of this paper is organized as follows. Section 2 presents an application scenario of a healthcare domain to motivate our work. Section 3 presents a formal model for specifying the elements of our policy framework. In Section 4, we introduce a policy ontology that uses the semantic technologies for specifying context-aware access control policies. In order to support context-specific control over access to information resources, Section 5 introduces a policy enforcement architecture. Section 6 presents the feasibility of our ontology-based policy framework by considering five factors, namely completeness, correctness, consistency, performance and usability. In this section, we also summarize our experience to build CAAC applications in today’s dynamic worlds. We review the related work in Section 7 and provide a comparative analysis with respect to the relevant access control literature. Finally, Section 8 concludes the paper and outlines future work. 2. RESEARCH MOTIVATION In this section, we present a motivating scenario in the domain of patient medical records management and its associated requirements. We consider an extended application scenario from our previous work [19]. The objectives of this section are 2-fold. The first objective is to analyse the scenario which illustrates the need for the incorporation of dynamic contexts in the access control process: context-aware user-role and role-permission assignments. The second objective is to identify the general requirements of developing context-aware access control applications via the context-aware user-role and role-permission assignments. We have used suitable examples from this scenario throughout the paper to explain the concepts of our framework. 2.1. Motivating scenario Let us consider the area of patient medical records management (PMRM) in the healthcare domain as a motivating scenario (Scene #1 and Scene #2) [19]. Scene #1: The scenario begins with patient Bob who is in the emergency room due to a heart attack. While not being Bob’s usual treating physician, Jane, a general practitioner at the hospital, is required to treat Bob and needs to access Bob’s emergency medical records from the emergency room. The different types of information involved in this scenario are highly dynamic. Following the traditional RBAC, the access control policy can either be too restrictive and prevent Jane from accessing Bob’s emergency medical records (i.e. only the treating physician can), or allow Jane’s access but too liberal and potentially compromising privacy (i.e. all general practitioners can). As such, we need context-aware access control (CAAC) policies. One of the relevant policies (in natural language) is shown in Table 1. Scene #2: After getting emergency treatment, Bob is shifted from the emergency department to the general ward of the hospital and has been assigned a registered nurse, Mary, who has regular follow-up visits to monitor his health condition. Mary needs to access several types of Bob’s medical records (daily medical records, past medical history and private medical records) from the general ward with certain conditions. Table 1. A CAAC policy. No. Policy Policy #1 A general practitioner who is a treating doctor of a patient, is allowed to read/write the patient’s emergency medical records in the hospital. However, all general practitioners should be able to access the patient’s emergency medical records in the hospital (by playing the emergency doctor role), when the patient’s health condition is critical No. Policy Policy #1 A general practitioner who is a treating doctor of a patient, is allowed to read/write the patient’s emergency medical records in the hospital. However, all general practitioners should be able to access the patient’s emergency medical records in the hospital (by playing the emergency doctor role), when the patient’s health condition is critical View Large Table 1. A CAAC policy. No. Policy Policy #1 A general practitioner who is a treating doctor of a patient, is allowed to read/write the patient’s emergency medical records in the hospital. However, all general practitioners should be able to access the patient’s emergency medical records in the hospital (by playing the emergency doctor role), when the patient’s health condition is critical No. Policy Policy #1 A general practitioner who is a treating doctor of a patient, is allowed to read/write the patient’s emergency medical records in the hospital. However, all general practitioners should be able to access the patient’s emergency medical records in the hospital (by playing the emergency doctor role), when the patient’s health condition is critical View Large The different types of dynamically changing information are also involved in this scenario (e.g. the presence of the doctor and the particular nurse–patient relationship). Similar to Scene #1, the basic RBAC policy model is too restrictive to support access control to Bob’s medical records when there are dynamic changes to the context (e.g. Bob’s health condition is normal). As such, we need context-aware access control policies. The corresponding context-aware access control policies (plain-language policy rules) are shown in Table 2. Table 2. The CAAC policies. No. Policy Policy #2 A registered nurse within a hospital is granted the right to read/write a patient’s daily medical records during her ward duty time and from the location where the patient is located Policy #3 The nurse is allowed to read the patient’s past medical history, if a general practitioner is present at the same location Policy #4 The nurse can access the patient’s private medical records, if she is an assigned nurse of that patient No. Policy Policy #2 A registered nurse within a hospital is granted the right to read/write a patient’s daily medical records during her ward duty time and from the location where the patient is located Policy #3 The nurse is allowed to read the patient’s past medical history, if a general practitioner is present at the same location Policy #4 The nurse can access the patient’s private medical records, if she is an assigned nurse of that patient View Large Table 2. The CAAC policies. No. Policy Policy #2 A registered nurse within a hospital is granted the right to read/write a patient’s daily medical records during her ward duty time and from the location where the patient is located Policy #3 The nurse is allowed to read the patient’s past medical history, if a general practitioner is present at the same location Policy #4 The nurse can access the patient’s private medical records, if she is an assigned nurse of that patient No. Policy Policy #2 A registered nurse within a hospital is granted the right to read/write a patient’s daily medical records during her ward duty time and from the location where the patient is located Policy #3 The nurse is allowed to read the patient’s past medical history, if a general practitioner is present at the same location Policy #4 The nurse can access the patient’s private medical records, if she is an assigned nurse of that patient View Large These context-aware access control policies are based on a set of constraints on the user roles (e.g. general practitioner, emergency doctor, registered nurse) and services/resources (e.g. daily medical records, past medical history, private medical records). These policies need to be evaluated in conjunction with some further dynamic context information (e.g. location, ward duty time, interpersonal relationship). The above-mentioned PMRM (patient medical records management) application is an example of how to realize context-aware access control decisions. In this application scenario, we have only considered some context-aware access control policies for the general practitioners and registered nurses (two roles). For the overall PMRM application, the number of policies can be up to 500 with respect to 138 different health professionals (i.e. 138 roles) [20]. 2.2. Scenario analysis In this section, we analyse the application scenario to capture the technical challenges to control access to resources. As different types of context entities and dynamically changing context information are involved in the access control process, a number of important technical challenges arise. The context-specific control over access to patients’ medical records on the running scenario works as follows. Two different types of context information are involved in the application scenario: simple and complex contexts. For example, the identity/role of the users and the location of the users are simple contexts, and the interpersonal relationship between the user and the patient and the health status of the patient are complex contexts. The complex contexts are not obtained directly but can be derived from the other available context information. For example, in Scene #2, the derived relationship or interpersonal relationship between the registered nurse and the patient can be derived from such context information as the nurse’s profile, patient’s profile, etc. In general, how to express the relevant contextual conditions in terms of the different types of dynamic (basic and derived) context information, which are to be integrated into the access control process, is the first technical challenge. Normally, only a patient’s treating physician is able to access all the patient’s electronic health records. In the mentioned emergency scenario (Scene #1), Jane, while not being the treating doctor, can access Bob’s emergency medical records from the emergency room of the hospital by playing the emergency doctor role. That is, Jane can play the emergency doctor role when she is present in the emergency room and Bob’s health condition is critical. On the other hand, she also can play the general practitioner role. Thus, rather than having static user-role assignment, how to dynamically assign the roles to users according to relevant contextual conditions is the second technical challenge. In general, a registered nurse is granted the right to read a patient’s daily medical records within a hospital. But, she should only be able to read the medical records from the location where the patient is located, during her ward duty time. In Scene #2, Mary, a registered nurse, can access Bob’s daily medical records during her ward duty time because she is present with Bob in the general ward. Furthermore, when the context changes (e.g. Bob’s health condition becomes critical again or Mary leaves the general ward), decisions on further access requests by Mary to Bob’s daily medical records, may change accordingly (e.g. permission is denied). That is, Mary, by playing the nurse role, can access Bob’s health records only when they both are co-located in the general ward of the hospital. Therefore, how to dynamically assign the resource access permissions to roles based on the relevant contextual conditions is also an important challenge. 2.3. General requirements In this section, we identify the general requirements of developing context-aware access control applications, based on the above motivating scenario. Looking at the application scenario and technical challenges identified in the previous sections, we make some important observations concerning context-aware access control. Figure 1 illustrates the relationship chain among user, role and resource. Figure 1. View largeDownload slide The relationship chain from user to resource access. Figure 1. View largeDownload slide The relationship chain from user to resource access. The relationship chain contains two main parts: the user-role mappings based on the relevant context information, and the role-permission (resource access permission) mappings based on the relevant context information. To support such context-aware access control in a computer application like the medical records management system, we need to consider the 3Ws: who (the appropriate users by playing appropriate roles) wants to access what (the appropriate parts of the resources), and under what contextual conditions (the dynamic context information). In particular, a context-aware access control (CAAC) policy framework is required to control the access to resources in such applications by taking into account the different types of context information that impact on the access control decisions. The general requirements of developing a CAAC policy framework are as follows: (Req. 1) Representation of contextual conditions: What access control-specific basic and derived (simple and complex) context information should be considered to express the relevant contextual conditions as part of building context-aware access control? In general, there is a need to formulate the contextual conditions using the relevant context information, in order to facilitate CAAC use. (Req. 2) Specification of user-role assignment policies: How to specify the user-role assignment policies based on the relevant contextual conditions? In general, there are different types of contexts involved in the user-role mappings. For example, in the application scenario, Mary can play the nurse role under certain contextual conditions (if she is located in the general ward, during her ward shift time and Bob’s health condition is normal). If the context/situation changes (e.g. Mary leaves the general ward or Bob’s health condition changes from normal to critical), the system will not allow Mary to play the nurse role (relative to Bob). Thus, there is a need to specify dynamic user-role assignment policies based on the relevant contextual conditions. (Req. 3) Specification of role-permission assignment policies: How to specify the role-permission assignment policies based on the relevant contextual conditions? For example, in the application scenario, when the context/situation changes (e.g. Bob has come out of emergency and moved to a general ward), decisions on further access control to resources (e.g. Jane’s access to Bob’s emergency medical records by playing the general practitioner role) may change accordingly (e.g. denied). Thus, there is a need to specify context-aware role-permission assignment policies based on the relevant contextual conditions. (Req. 4) Enforcement of access control policies: How to evaluate the access control policies based on the relevant contextual conditions to realize a flexible and dynamic access control scheme? There is a need for an access controller to evaluate the context-aware user-role and role-permission assignment policies based on the relevant contextual conditions, and manage re-authorization of access as context/situation changes. 3. FORMAL POLICY MODEL FOR CAAC 3.1. Background In this section, we discuss the main elements of the traditional role-based access control model [4, 5] to motivate the need for extending the basic RBAC model to support context-aware access control requirements. The traditional RBAC policy model has become the most widely used access control paradigm for managing and enforcing security in large-scale domains [7]. The model has the following main elements: users, roles and permissions. In RBAC, the users are human beings, who are assigned to roles based on their credentials in the organizations, roles represent the job functions within the organizations, describing the authorities and responsibilities conferred on the users assigned to these roles, and permissions are the approvals to perform certain operations on resources. In the RBAC policy model, the access permissions are not assigned directly to the particular users, but to the users’ roles. That is, the central notion of RBAC is that users are assigned to appropriate roles, permissions are assigned to roles, and users can have appropriate permissions by being members of such roles. RBAC ensures that only an authorized user is given access to a certain permission, and is based on the user’s role in the organization. As such, it simplifies the management of access control policies by creating user-role and role-permission assignments. However, the RBAC policy model does not directly adapt to the requirements of the context-aware access control applications (as presented in the previous section). In particular, it does not provide adequate functionalities to incorporate and adapt to the dynamically changing context information. In the next section, we introduce a new context-aware access control (CAAC) policy framework for information resources and software services. It extends the basic concepts of RBAC to use dynamic context information while making access control decisions. The basic concepts of our policy framework are that users are dynamically assigned to roles by satisfying the relevant contextual conditions, permissions (resource/service access permissions) are dynamically assigned to roles by satisfying the relevant contextual conditions, and users acquire appropriate permissions by being members of such roles in a dynamic manner. 3.2. Core policy model Figure 2 shows the policy model of our CAAC framework and the relationships between its elements. Figure 2. View largeDownload slide Core policy model. Figure 2. View largeDownload slide Core policy model. Our policy model enables dynamic privileges assignment in two steps, letting users to access resources and services when certain contextual conditions are satisfied. In the first step, the users are dynamically assigned to the roles when a set of conditions are satisfied. In the next step, when the roles are activated, the permissions (service access permissions) are assigned to these roles when specific contextual conditions are satisfied. The two main concepts are context-aware user-role assignments and context-aware role-permission assignments. Based on the formalization of the traditional role-based access control (RBAC) model [5], we present a formal definition of our policy model. Definition 1 (Core Policy Model). The CAAC policy model has the following elements: Basic elements: U,R,Res,Opand Exp ⁠, for users, roles, resources, operations and contextual condition expressions, respectively; Composite elements: RH,ResH,OpA,P,CAURA,CARPAand Pol ⁠, for role hierarchy, resource hierarchy, operation assignments, permissions, context-aware user-role assignments, context-aware role-permission assignments and policies, respectively.These elements are explained and further defined below. First of all, we define the five basic elements of our policy model: Users (U): U represents a set of users. The users are service requesters interacting with a computing system, whose access requests are being controlled: U={u1,u2,u3,…,um} (1) Roles (R): R represents a set of roles. The roles reflect users’ job functions within the organization (e.g. healthcare domain): R={r1,r2,r3,…,rn} (2) Resources (Res): Res represents a set of resources. The resources are the objects protected by access control that represent the data/information container (e.g. the different parts of a patient’s medical records). Res={res1,res2,res3,…,reso} (3) Operations (Op): Op represents a set of operations on the resources. The operations are the actions that can be executed on the resources, for instance, read and write: Op={op1,op2,op3,…,opp} (4) Expressions (Exp): Exp represents a set of contextual expressions. The expressions are used to express the contextual conditions (using relevant context information) in order to specify the context-aware user-role and role-permission assignment policies. We use the terms of contextual expression and contextual condition interchangeably. The contextual expressions are specified in the context specification language (CSL): Exp={exp1,exp2,exp3,…,expq} (5) A detailed analysis of contextual expressions is given in the next section (see Section 3.3). The policy model has seven other elements (which are related to the above basic elements). These elements are defined formally as follows: Role Hierarchy (RH): RH is a partial order on R to serve as the role hierarchy, which supports the concept of role inheritance. The role is considered in a hierarchical manner in that if a permission assigned to a junior role, then it is also assigned to all the senior roles of that role: RH⊆R×R (6) Resource Hierarchy (ResH): ResH is a partial order on Res to serve as the resource hierarchy, which supports a user’s access to the resources at different granularity levels. The resource is considered in a hierarchical manner in that if a user has the right to access a resource at a higher granularity level, then he also has the right to access that part of resource at a lower granularity levels: ResH⊆Res×Res (7) Operation Assignment (OpA): OpA is a many-to-many operation-to-resource mapping. Each operation could be associated with many resources, and each resource could be manipulated by many operations: OpA⊆Res×Op (8) Permission (P): P represents a set of permissions. The permissions are the approvals to perform certain operations on resources by the users who initiate access requests: P={(resi,opj)∣resi∈Res,opj∈Op} (9) where i={1,2,3,…,o},j={1,2,3,…,p} ⁠, Res is a set of resources, and Op is a set of operations on the resources. The permission (P) is a subset of operation assignment (OpA), P⊆OpA (10) Context-Aware User-Role Assignment (CAURA): CAURA is a context-aware user-role assignment relation, which is a many-to-many mapping between users and roles, when a set of dynamic contextual conditions are satisfied: CAURA⊆U×R×Exp (11) Context-Aware Role-Permission Assignment (CARPA): CARPA is a context-aware role-permission assignment relation, which is a many-to-many mapping between roles and permissions, when a set of dynamic contextual conditions (contextual expressions) are satisfied: CARPA⊆R×P×Exp (12) Policies (Pol): Pol represents a set of context-aware access control policies. It includes the context-aware user-role assignment (CAURA) policies and context-aware role-permission assignment (CARPA) policies: Pol=PolCAURA∪PolCARPA (13) The main concepts that we have introduced in our policy model are the context-aware user-role assignments and context-aware role-permission assignments. They incorporate dynamically changing contextual conditions (in the form of contextual expressions) into RBAC for dynamic user-role and role-permission assignments. In the following sections, we further define and discuss context information, context specification language, CAURA policy specification and CARPA policy specification. 3.3. Context information and context specification language (CSL) 3.3.1. Context information In the context-awareness literature, many researchers have defined the concept of context. According to Dey, context is any information that can be used to characterize the situation of an entity (person, place or object) [2]. For our purpose, however, existing context definitions are not specific enough to specify the different types of entities for access control and the context information characterizing these entities. In our earlier work [19, 21], we define context as any relevant information about the state of an entity relevant to access control or the state of a relevant relationships between persons (as entities). We classify context information into simple context and complex context, i.e. context information (C) is the set of all simple context information (⁠ Cs ⁠) and all complex context information (Cc) ⁠: C=Cs∪Cc (14) A simple context ‘ cs’ (⁠ cs∈Cs ⁠) is an attribute of an entity that directly depends on a raw context fact. It characterizes the state of an entity, based on a single context information source: Cs={cs1,cs2,cs3,…,css} (15) In our application scenario (presented in Section 2), user identity is a simple context that represents a property of the user (resource requester). A complex context ‘ cc’ (⁠ cc∈Cc ⁠) is a combination of context facts. It depends on the values of attributes that characterize the state of one or more entities, based on the one or more context information sources: Cc={cc1,cc2,cc3,…,cct} (16) In our application scenario, interpersonal relationship is a complex context that represents a property which is related to the user and resource owner. The interpersonal relationship between user and owner can be inferred from available context information (e.g. the profile information of the user and owner). 3.3.2. Context specification language Our policy model includes a simple language (context specification language, CSL ⁠) for expressing contextual conditions based on the simple and complex contexts. This language is used to formally specify the constraints in context-aware user-role and role-permission assignment policies. Definition 2 (Simple Context Expression (⁠ Exps ⁠)). Let Ebe the set of context entities, and Csbe the set of simple context information, then we define a simple context expression as a tuple in the form of <e.cs,rel.op,v>,[where,e∈E,cs∈Cs,andrel.op∈{<,≤,>,≥,=,≠}] (17) In the above expression, ‘ e’ denotes a context entity, ‘ cs’ denotes a simple context attribute, ‘ e.cs’ denotes a simple context about an entity (i.e. context attribute of an entity), ‘ rel.op’ denotes a relational operator and ‘ v’ denotes the value assigned to the context attribute ‘ cs’ of context entity ‘ e’. Example 1 A patient or resource owner’s heart rate is less than 65 (or is abnormal), which is represented as exps1≜(Owner.heartRate<65)orexps1≜(Owner.heartRate=“Abnormal”) (18) A simple context expression is a simple contextual constraint in the CSL language. It is possible to construct more complex expressions by logically combining (conjunction (⁠ ∧ ⁠), disjunction (⁠ ∨ ⁠), and negation (⁠ ¬ ⁠)) simple constraints. Definition 3 (Complex Context Expression (⁠ Expc ⁠)). A complex context expression can be defined by performing logical composition on simple or complex context expressions. expc1≜exp1∧exp2expc2≜exp3∨exp4expc3≜¬exp5 (19) where exp1 ⁠, exp2 ⁠, exp3 ⁠, exp4 and exp5 are already defined simple or complex context expressions, and expc1 ⁠, expc2 and expc3 are newly defined complex context expressions. Example 2 Let us consider an access control policy from our application scenario: Mary can play the registered nurse role during her ward duty time and when she is located in the general ward. Using logical composition, the contextual condition of this policy can be represented as expc1≜((User.locationAddress=“GeneralWard”)∧(User.requestTime=“DutyTime”)) (20) Example 3 A registered nurse (who is assigned for a patient) is granted the right to access the patient’s daily medical records when the patient’s health condition is normal. Using logical composition, the contextual condition of this policy can be represented as expc2≜((interRelationship(User,Owner)=“AssignedNurse”)∧(Owner.healthStatus=“Normal”)) (21) Definition 4 (Contextual Expression (⁠ Exp ⁠)). By Definitions2and3, a contextual expression exp (⁠ exp∈Exp ⁠) is either a simple context expression or a complex context expression: exp≜exps∣expc (22) where exps denotes a simple context expression and expc denotes a complex context expression. In the CSL language, the set of relational operators ‘ rel.op’ can be extended to accommodate user-defined operators. For example, the operator ‘included-in’ can be defined using CSL to support spatial inclusions, in the same way as other relational operators. Example 4 A hospital doctor Jane can access a patient Bob’s all health records from the emergency room of the hospital when his health condition is critical. One of the contextual conditions of this policy can be represented as exps2≜(User.locationAddress=“EmergencyRoom”<“Hospital”) (23) In this example, the relational operator ‘ <’ is used to represent the spatial operator ‘included-in’. In the rest of this paper, for simplicity, we do not show the formal representations of spatial inclusions when specifying location contexts. Further details can be found in the ontology-based policy model (see Section 4.4). 3.4. Context-aware user-role assignment (CAURA) policy specification Our policy model extends the concept of user-role assignment in RBAC, by introducing the concept of context-aware user-role assignment (⁠ CAURA ⁠). The traditional RBAC model defines user-role assignment (⁠ URA ⁠) simply as a mapping of users to roles: URA⊆U×R (24) We have extended this URA notion by introducing dynamic contextual expressions (integrating relevant context information). Definition 5 (CAURA). Let Ube the set of users, Rbe the set of roles and Expbe the set of contextual expressions, then CAURA is a many-to-many user-role assignment relation associated with certain contextual expressions: CAURA={(u1,r1,exp1),(u2,r2,exp2),…,(ui,rj,expk)}⊆U×R×Exp (25) where ‘ u’ denotes a user (⁠ u∈U ⁠), ‘ r’ denotes a role (⁠ r∈R ⁠) and ‘ exp’ denotes a contextual expression (exp∈Exp) ⁠. Context-aware user-role assignments can be expressed in tabular form (see Table 3). For example, the second row in Table 3 describes when Mary is present in the general ward and during her ward duty time, she can be assigned to the registered nurse role. Definition 6 (CAURA Policy). Let Ube the set of users, Rbe the set of roles and Expbe the set of contextual expressions. A CAURApolicy (⁠ polCAURA ⁠) is defined as follows:   a user ‘ u’ can be assigned the role ‘ r’   if and only if (u,r,exp)∈CAURA   or alternatively    polCAURA∈CAURAPolicy    ⟺(u,r,exp)∈CAURA   a user ‘ u’ can be assigned the role ‘ r’   if and only if (u,r,exp)∈CAURA   or alternatively    polCAURA∈CAURAPolicy    ⟺(u,r,exp)∈CAURA   a user ‘ u’ can be assigned the role ‘ r’   if and only if (u,r,exp)∈CAURA   or alternatively    polCAURA∈CAURAPolicy    ⟺(u,r,exp)∈CAURA   a user ‘ u’ can be assigned the role ‘ r’   if and only if (u,r,exp)∈CAURA   or alternatively    polCAURA∈CAURAPolicy    ⟺(u,r,exp)∈CAURA where ‘ u’ is a user (⁠ u∈U ⁠), ‘ r’ is a role (⁠ r∈R ⁠), and ‘ exp’ is a contextual expression (⁠ exp∈Exp ⁠) defined in the CSL ⁠. Table 3. Context-aware user-role assignment. User Role Contextual expression Jane EmergencyDoctor (User.locationAddress=“EmergencyRoom”) Mary RegisteredNurse (User.locationAddress=“GeneralWard”)∧(User.requestTime=“DutyTime”) User Role Contextual expression Jane EmergencyDoctor (User.locationAddress=“EmergencyRoom”) Mary RegisteredNurse (User.locationAddress=“GeneralWard”)∧(User.requestTime=“DutyTime”) View Large Table 3. Context-aware user-role assignment. User Role Contextual expression Jane EmergencyDoctor (User.locationAddress=“EmergencyRoom”) Mary RegisteredNurse (User.locationAddress=“GeneralWard”)∧(User.requestTime=“DutyTime”) User Role Contextual expression Jane EmergencyDoctor (User.locationAddress=“EmergencyRoom”) Mary RegisteredNurse (User.locationAddress=“GeneralWard”)∧(User.requestTime=“DutyTime”) View Large Based on the CAURA policy definition (see Definition 6), the rule (shown in Table 4) expresses the context-aware user-role assignment policy, i.e. a User u (⁠ u∈U ⁠) can play a Role r (⁠ r∈R ⁠) under contextual condition exp (⁠ exp∈Exp ⁠). Example 5 Let us consider an access control policy from our application scenario: Mary can play the registered nurse role during her ward shift time and when she is located in the ward. In Table 4, Role ‘ r’ denotes RegisteredNurse role, User ‘ u’ is Mary ⁠, and Contextual Condition ‘ exp’ is the combination of the raw facts of the ward ‘duty time’ and ‘location’ of Mary. The contextual condition is already expressed in Formula (20) in CSL (Section 3.3). Table 4. Context-aware user-role assignment policy. If    CAURAPolicy(caura)∧User(u)∧Role(r)∧ContextualCondition(exp)∧ hasUser(caura,u)∧hasRole(caura,r)∧hasCondition(caura,exp) Then    caura(u,r) If    CAURAPolicy(caura)∧User(u)∧Role(r)∧ContextualCondition(exp)∧ hasUser(caura,u)∧hasRole(caura,r)∧hasCondition(caura,exp) Then    caura(u,r) View Large Table 4. Context-aware user-role assignment policy. If    CAURAPolicy(caura)∧User(u)∧Role(r)∧ContextualCondition(exp)∧ hasUser(caura,u)∧hasRole(caura,r)∧hasCondition(caura,exp) Then    caura(u,r) If    CAURAPolicy(caura)∧User(u)∧Role(r)∧ContextualCondition(exp)∧ hasUser(caura,u)∧hasRole(caura,r)∧hasCondition(caura,exp) Then    caura(u,r) View Large 3.5. Context-aware role-permission assignment (CARPA) policy specification Similar to context-aware user-role assignment, our policy model extends the concept of role-permission assignment in RBAC with contextual expressions, called context-aware role-permission assignment (⁠ CARPA ⁠). Traditional RBAC model defines role-permission assignment (⁠ RPA ⁠) simply as a mapping of roles to permissions: RPA⊆R×P (26) We have extended this RPA notion by introducing dynamic contextual expressions (integrating context information). Definition 7 (CARPA). Let Rbe the set of roles, Expbe the set of contextual expressions, and Pbe the set of permissions, then CARPA is a many-to-many role-permission assignment relation associated with certain contextual expressions: CARPA={(r1,p1,exp1),(r2,p2,exp2),…,(ri,pj,expk)}⊆R×P×Exp (27) where ‘ p’ denotes a permission (⁠ p∈P ⁠), ‘ r’ denotes a role (⁠ r∈R ⁠) and ‘ exp’ denotes a contextual expression (⁠ exp∈Exp ⁠). Definition 8 (CARPA Policy). Let Rbe the set of roles, Pbe the set of permissions, and Expbe the set of contextual expressions. A CARPApolicy (⁠ polCARPA ⁠) is defined as follows:   a role ‘ r’ can be assigned the permission ‘ p’   if and only if (r,p,exp)∈CARPA   or alternatively    polCARPA∈CARPAPolicy    ⟺(r,p,exp)∈CARPA   a role ‘ r’ can be assigned the permission ‘ p’   if and only if (r,p,exp)∈CARPA   or alternatively    polCARPA∈CARPAPolicy    ⟺(r,p,exp)∈CARPA   a role ‘ r’ can be assigned the permission ‘ p’   if and only if (r,p,exp)∈CARPA   or alternatively    polCARPA∈CARPAPolicy    ⟺(r,p,exp)∈CARPA   a role ‘ r’ can be assigned the permission ‘ p’   if and only if (r,p,exp)∈CARPA   or alternatively    polCARPA∈CARPAPolicy    ⟺(r,p,exp)∈CARPA where ‘ r’ is a role (⁠ r∈R ⁠), ‘ p’ is a permission (⁠ p∈P ⁠) and ‘ exp’ is a contextual expression (⁠ exp∈Exp ⁠) defined in the CSL ⁠. Based on the CARPA policy definition, the following rule (shown in Table 5) expresses the context-aware role-permission assignment policy. Example 6 In our application scenario, let us consider an access control policy: A registered nurse, who is assigned for a regular follow-up visit to monitor a patient’s health condition, can access the patient’s daily medical records (DMR) when the patient’s health status is normal. In Table 5, Role ‘ r’ denotes RegisteredNurse role, permission is (DMR, Write) (i.e. Resource ‘ res’ is DMR and Operation ‘ op’ is Write ⁠), and Contextual Condition ‘ exp’ is the combination of the following raw facts: the nurse is ‘assigned’ for the patient and the patient has ‘normal health status’. The contextual condition is already expressed in Formula (21) in the CSL (Section 3.3). Table 5. Context-aware role-permission assignment policy. If    CARPAPolicy(carpa)∧Role(r)∧Resource(res)∧Operation(op)∧ContextualCondition(exp)∧ hasRole(carpa,r)∧hasResource(carpa,res)∧    hasOperation(carpa,op)∧hasCondition(carpa,exp) Then    carpa(r,p) If    CARPAPolicy(carpa)∧Role(r)∧Resource(res)∧Operation(op)∧ContextualCondition(exp)∧ hasRole(carpa,r)∧hasResource(carpa,res)∧    hasOperation(carpa,op)∧hasCondition(carpa,exp) Then    carpa(r,p) View Large Table 5. Context-aware role-permission assignment policy. If    CARPAPolicy(carpa)∧Role(r)∧Resource(res)∧Operation(op)∧ContextualCondition(exp)∧ hasRole(carpa,r)∧hasResource(carpa,res)∧    hasOperation(carpa,op)∧hasCondition(carpa,exp) Then    carpa(r,p) If    CARPAPolicy(carpa)∧Role(r)∧Resource(res)∧Operation(op)∧ContextualCondition(exp)∧ hasRole(carpa,r)∧hasResource(carpa,res)∧    hasOperation(carpa,op)∧hasCondition(carpa,exp) Then    carpa(r,p) View Large 4. ONTOLOGY-BASED POLICY MODEL FOR POLICY SPECIFICATION We have in the last section defined the formal policy model to specify context-aware user-role and role-permission assignment policies. Based on this formal model, in this section, we present an ontology-based policy model for our framework to provide the practical basis for realizing our CAAC framework, as the policy ontology can be directly included in its implementation (see the next section). The main goal of our policy ontology is to specify the two sets of context-aware access control policies by incorporating the dynamically changing context information. 4.1. Design considerations To simplify the management of access control policies, various policy languages have been proposed in the literature. Our goal in this paper is to provide a way in which context-aware access control policies can be specified, which incorporate context information. To be of practical use, it must be expressive enough to specify the policies in an easy and natural manner. Experience from existing research (e.g. [22, 23]) shows that ontologies are very suitable for modelling dynamic information for ubiquitous computing applications. Furthermore, the expressivity of the ontology language OWL [24] can be extended by incorporating SWRL rules [25]. As such, we use the ontology languages OWL and SWRL as the CAAC policy language. Our policy ontology specifies two sets of context-aware access control (CAAC) policies: (i) the context-aware user-role assignment policies and (ii) the context-aware role-permission assignment policies. The basic concepts of these CAAC policies are that users are dynamically assigned to roles by satisfying the relevant contextual conditions, permissions are dynamically assigned to roles by satisfying the relevant contextual conditions, and users acquire resource access permissions by having corresponding roles. Figure 3 shows the top-level conceptual view of our policy ontology. The ontology defines the following concepts under the hierarchy of CAACPolicy, namely CAURAPolicy and CARPAPolicy. The CAURAPolicy models context-aware user-role assignment policies and CARPAPolicy models context-aware role-permission assignment policies. Figure 3. View largeDownload slide The core policy ontology. Figure 3. View largeDownload slide The core policy ontology. 4.2. CAURA policy ontology The CAURA policy ontology, representing context-aware user-role assignment policies, has been designed by answering the following questions. Who is requesting resource/service access (requester or user)? What role does the user play (role)? What is the dynamic context information that is relevant for this user-role assignment (contextual condition)? 4.2.1. Core concepts The CAURA policy ontology, as depicted in Fig. 4, has the following core concepts which are organized into a CAURAPolicy hierarchy: User, Role and ContextualCondition. The ContextualCondition class has the concept ContextInfo, which has two subclasses SimpleContext and ComplexContext. Figure 4. View largeDownload slide The CAURA policy ontology. Figure 4. View largeDownload slide The CAURA policy ontology. For simplicity, we define the CAURA ontology concepts as follows: The basic classes User, Role and ContextualCondition form a CAURAPolicy (see Definition 10). The ContextInfo class has two subclasses: SimpleContext and ComplexContext (see Definition 9). A subclass SimpleContext or ComplexContext can have fewer or equal elements to the basic class ContextInfo. Definition 9 (Subclass). SimpleContext⊆ContextInfo ComplexContext⊆ContextInfo Definition 10 (Basic Class). CAURAPolicy⊆User×Role×ContextualCondition The relationships in CAURAPolicy ontology are represented by two types of properties, i.e. object and data type properties. The domain and the range of object properties are specified in Table 6. Table 6. Domain and range restrictions for CAURA object properties. Object Property Domain Range Description hasCondition CAURAPolicy ContextualCondition A CAURA policy has the contextual conditions hasRole CAURAPolicy Role A CAURA policy has the roles hasUser CAURAPolicy User A CAURA policy has the users hasContext ContextualCondition ContextInfo A contextual condition is formed by the context information which can be either a simple context or a complex context plays User Role A user can play a role Object Property Domain Range Description hasCondition CAURAPolicy ContextualCondition A CAURA policy has the contextual conditions hasRole CAURAPolicy Role A CAURA policy has the roles hasUser CAURAPolicy User A CAURA policy has the users hasContext ContextualCondition ContextInfo A contextual condition is formed by the context information which can be either a simple context or a complex context plays User Role A user can play a role View Large Table 6. Domain and range restrictions for CAURA object properties. Object Property Domain Range Description hasCondition CAURAPolicy ContextualCondition A CAURA policy has the contextual conditions hasRole CAURAPolicy Role A CAURA policy has the roles hasUser CAURAPolicy User A CAURA policy has the users hasContext ContextualCondition ContextInfo A contextual condition is formed by the context information which can be either a simple context or a complex context plays User Role A user can play a role Object Property Domain Range Description hasCondition CAURAPolicy ContextualCondition A CAURA policy has the contextual conditions hasRole CAURAPolicy Role A CAURA policy has the roles hasUser CAURAPolicy User A CAURA policy has the users hasContext ContextualCondition ContextInfo A contextual condition is formed by the context information which can be either a simple context or a complex context plays User Role A user can play a role View Large The class User has userIdentity data property and the Role class has a data property named roleIdentity (see Table 7). Table 7. CAURA data type properties. Data type property Domain userIdentity User roleIdentity Role Data type property Domain userIdentity User roleIdentity Role View Large Table 7. CAURA data type properties. Data type property Domain userIdentity User roleIdentity Role Data type property Domain userIdentity User roleIdentity Role View Large Overall, a CAURA policy captures the 3W dimensions which can be read as follows: a CAURA Policy specifies that a user (userIdentity) can play a role (roleIdentity) by satisfying the relevant contextual conditions. The details of OWL-based CAURA policy specifications can be found in Appendix A. 4.2.2. An example CAURA policy Example 7 Let us consider an access control policy for the registered nurse presented in Section 2: a user Mary can play the registered nurse (RN) role (in order to access a patient’s daily medical records), during her ward duty time (DT) from the general ward (GW) of the hospital, where the patient is located. In this policy, the access decision is based on the following policy constraints: who the user is (user’s identity), what role she can play (role’s identity) and under what contextual conditions (the locations of the user and patient, and the request time of the user). The CAURA policy for the registered nurses in OWL is shown in Table 8. The core policy concepts are specified in Line# 1–6, the user specification is shown in Line# 7–9, the role specification (registered nurse) is shown in Line# 10–12, and the contextual condition (a complex context cc1 ⁠) is specified in Line# 13–15. Table 8. An example CAURA policy for playing registered nurse role. 1 <CAURAPolicy rdf:ID=“ caura1” > 2    < hasUser rdf:resource=“#User_RegisteredNurse_DB”/ > 3    < hasRole rdf:resource=“#Role_RegisteredNurse”/ > 4    < hasCondition rdf:resource=“#ContextualCondition_ContextInfo”/ > 6 </CAURAPolicy > 7 <User rdf:ID=“User_RegisteredNurse_DB” > 8    < userIdentity rdf:datatype=“& xsd;string” > Mary00X </userIdentity > 9 </User > 10 <Role rdf:ID=“Role_RegisteredNurse” > 11    < roleIdentity rdf:datatype=“& xsd;string” > RN00X </roleIdentity > 12 </Role > 13 <ContextualCondition rdf:ID=“ContextualCondition_ContextInfo” > 14    < hasContext rdf:resource=“#ComplexContext_ cc1”/ > 15 </ContextualCondition > 1 <CAURAPolicy rdf:ID=“ caura1” > 2    < hasUser rdf:resource=“#User_RegisteredNurse_DB”/ > 3    < hasRole rdf:resource=“#Role_RegisteredNurse”/ > 4    < hasCondition rdf:resource=“#ContextualCondition_ContextInfo”/ > 6 </CAURAPolicy > 7 <User rdf:ID=“User_RegisteredNurse_DB” > 8    < userIdentity rdf:datatype=“& xsd;string” > Mary00X </userIdentity > 9 </User > 10 <Role rdf:ID=“Role_RegisteredNurse” > 11    < roleIdentity rdf:datatype=“& xsd;string” > RN00X </roleIdentity > 12 </Role > 13 <ContextualCondition rdf:ID=“ContextualCondition_ContextInfo” > 14    < hasContext rdf:resource=“#ComplexContext_ cc1”/ > 15 </ContextualCondition > View Large Table 8. An example CAURA policy for playing registered nurse role. 1 <CAURAPolicy rdf:ID=“ caura1” > 2    < hasUser rdf:resource=“#User_RegisteredNurse_DB”/ > 3    < hasRole rdf:resource=“#Role_RegisteredNurse”/ > 4    < hasCondition rdf:resource=“#ContextualCondition_ContextInfo”/ > 6 </CAURAPolicy > 7 <User rdf:ID=“User_RegisteredNurse_DB” > 8    < userIdentity rdf:datatype=“& xsd;string” > Mary00X </userIdentity > 9 </User > 10 <Role rdf:ID=“Role_RegisteredNurse” > 11    < roleIdentity rdf:datatype=“& xsd;string” > RN00X </roleIdentity > 12 </Role > 13 <ContextualCondition rdf:ID=“ContextualCondition_ContextInfo” > 14    < hasContext rdf:resource=“#ComplexContext_ cc1”/ > 15 </ContextualCondition > 1 <CAURAPolicy rdf:ID=“ caura1” > 2    < hasUser rdf:resource=“#User_RegisteredNurse_DB”/ > 3    < hasRole rdf:resource=“#Role_RegisteredNurse”/ > 4    < hasCondition rdf:resource=“#ContextualCondition_ContextInfo”/ > 6 </CAURAPolicy > 7 <User rdf:ID=“User_RegisteredNurse_DB” > 8    < userIdentity rdf:datatype=“& xsd;string” > Mary00X </userIdentity > 9 </User > 10 <Role rdf:ID=“Role_RegisteredNurse” > 11    < roleIdentity rdf:datatype=“& xsd;string” > RN00X </roleIdentity > 12 </Role > 13 <ContextualCondition rdf:ID=“ContextualCondition_ContextInfo” > 14    < hasContext rdf:resource=“#ComplexContext_ cc1”/ > 15 </ContextualCondition > View Large The contextual condition cc1(registered nurses during ward duty time from the general ward of the hospital) is already expressed in Formula (20), using logical composition (see Section 3.3). The following OWL code shows its ontological definition (see Definition 11). Definition 11 (‘ cc1’ Contextual Condition Definition).    <ComplexContextrdf:ID=“ComplexContext_cc1”>    <User.locationAddressrdf:datatype    =“&xsd;string”>GeneralWard    </User.locationAddress>    <User.requestTimerdf:datatype    =“&xsd;string”>DutyTime    </User.requestTime>    </ComplexContext>    <ComplexContextrdf:ID=“ComplexContext_cc1”>    <User.locationAddressrdf:datatype    =“&xsd;string”>GeneralWard    </User.locationAddress>    <User.requestTimerdf:datatype    =“&xsd;string”>DutyTime    </User.requestTime>    </ComplexContext>    <ComplexContextrdf:ID=“ComplexContext_cc1”>    <User.locationAddressrdf:datatype    =“&xsd;string”>GeneralWard    </User.locationAddress>    <User.requestTimerdf:datatype    =“&xsd;string”>DutyTime    </User.requestTime>    </ComplexContext>    <ComplexContextrdf:ID=“ComplexContext_cc1”>    <User.locationAddressrdf:datatype    =“&xsd;string”>GeneralWard    </User.locationAddress>    <User.requestTimerdf:datatype    =“&xsd;string”>DutyTime    </User.requestTime>    </ComplexContext> 4.3. CARPA policy ontology The CARPA policy ontology, representing context-aware role-permission assignment policies, has been designed by answering the following questions: Who is requesting access by playing what role (role)? What type of object is being requested (resource or service)? What is the dynamic context information that is relevant for this role-permission assignment (contextual condition)? 4.3.1. Core concepts A graphical representation of the ontology is shown in Fig. 5. The ontology has the following core concepts, which are organized into a CARPAPolicy hierarchy, including such concepts as Role, Permission, Resource, Operation, AccessDecision and ContextualCondition. The ContextualCondition class has the concept ContextInfo which in turn has two subclasses SimpleContext and ComplexContext. Figure 5. View largeDownload slide The CARPA policy ontology. Figure 5. View largeDownload slide The CARPA policy ontology. The CARPAPolicy ontology has object and data type properties. The domain and range of object properties are specified in Table 9. Table 9. Domain and range restrictions for CARPA object properties. Object property Domain Range Description hasDecision CARPAPolicy AccessDecision A CARPA policy has the access decision hasPermission CARPAPolicy Permission A CARPA policy has a permission hasOperation Permission Operation A CARPA policy has a permission to access/perform different operations on resource hasResource Permission Resource A CARPA policy has a permission to access resource isOwnedBy Resource Owner A resource is owned by an owner Object property Domain Range Description hasDecision CARPAPolicy AccessDecision A CARPA policy has the access decision hasPermission CARPAPolicy Permission A CARPA policy has a permission hasOperation Permission Operation A CARPA policy has a permission to access/perform different operations on resource hasResource Permission Resource A CARPA policy has a permission to access resource isOwnedBy Resource Owner A resource is owned by an owner View Large Table 9. Domain and range restrictions for CARPA object properties. Object property Domain Range Description hasDecision CARPAPolicy AccessDecision A CARPA policy has the access decision hasPermission CARPAPolicy Permission A CARPA policy has a permission hasOperation Permission Operation A CARPA policy has a permission to access/perform different operations on resource hasResource Permission Resource A CARPA policy has a permission to access resource isOwnedBy Resource Owner A resource is owned by an owner Object property Domain Range Description hasDecision CARPAPolicy AccessDecision A CARPA policy has the access decision hasPermission CARPAPolicy Permission A CARPA policy has a permission hasOperation Permission Operation A CARPA policy has a permission to access/perform different operations on resource hasResource Permission Resource A CARPA policy has a permission to access resource isOwnedBy Resource Owner A resource is owned by an owner View Large The data type properties of the CARPAPolicy ontology are shown in Table 10. Table 10. CARPA data type properties. Data Type Property Domain decision AccessDecision resourceIdentity Resource ownerIdentity Owner action Operation Data Type Property Domain decision AccessDecision resourceIdentity Resource ownerIdentity Owner action Operation View Large Table 10. CARPA data type properties. Data Type Property Domain decision AccessDecision resourceIdentity Resource ownerIdentity Owner action Operation Data Type Property Domain decision AccessDecision resourceIdentity Resource ownerIdentity Owner action Operation View Large A CARPA policy has exactly one access decision value (“Granted” or “Denied”). To specify this cardinality constraint in our CARPA policy ontology (see Fig. 5), we consider a class AccessDecision, and its data type property decision. The possible access decision values are summarized in Table 11. Table 11. Cardinality constraint. Property Possible values Description decision Granted Access request is granted decision Denied Access request is denied Property Possible values Description decision Granted Access request is granted decision Denied Access request is denied View Large Table 11. Cardinality constraint. Property Possible values Description decision Granted Access request is granted decision Denied Access request is denied Property Possible values Description decision Granted Access request is granted decision Denied Access request is denied View Large Overall, a CARPA policy captures the 3W dimensions which can be read as follows: a CARPAPolicy specifies that a user who is playing a role has AccessDecision (“Granted” or “Denied”) to which parts (resourceIdentity) of a Resource for a specific action (“Read” or “Write” Operation) or a range of actions under what contextual conditions. The details of OWL-based CARPA policy specifications can be found in Appendix B. 4.3.2. An example CARPA policy Example 8 Again consider the access control policy for the registered nurses (presented in Section 2): a registered nurse, who is assigned for a regular follow-up visit to monitor a patient’s health condition, can access the patient’s daily medical records (DMR) when the patient’s health status is normal. In this policy, the access decision is based on the following policy constraints: who the user is (user’s role), what resource is being requested (resource’s identity), and under what contextual conditions the user sends the request (the interpersonal relationship between user and resource owner and the health status of the patient). The CARPA policy for the registered nurses in OWL is shown in Table 12. The policy states that the registered nurse (the assigned nurse) can access the patient’s daily medical records when the patient’s health condition is normal. The core policy concepts are specified in Line# 1–6, the role specification (registered nurse) is shown in Line# 7–9, the permission specification (daily medical records on write operation) is shown in Line# 10–19, and the access decision (granted decision) is specified in Line# 20–22. The contextual condition (a complex context cc2 ⁠) is specified in Line# 23–25. Table 12. An example CARPA policy for the registered nurse. 1 <CARPAPolicy rdf:ID=“ carpa1” > 2    < hasRole rdf:resource=“#Role_RegisteredNurse”/ > 3    < hasPermission rdf:resource=“#Permission_DMR_Write”/ > 4    < hasCondition rdf:resource=“#ContextualCondition_ContextInfo”/ > 5    < hasDecision rdf:resource=“#AccessDecision_Granted”/ > 6 </CARPAPolicy > 7 <Role rdf:ID=“Role_RegisteredNurse” > 8    < roleIdentity rdf:datatype=“& xsd;string” > RN00X </roleIdentity > 9 </Role > 10 <Permission rdf:ID=“Permission_DMR_Write” > 11    < hasResource rdf:resource=“#Resource_DMR”/ > 12    < hasOperation rdf:resource=“#Operation_Write”/ > 13 </Permission > 14 <Resource rdf:ID=“Resource_DMR” > 15    < resourceIdentity rdf:datatype=“& xsd;int” > 2 </resourceIdentity > 16 </Resource > 17 <Operation rdf:ID=“Operation_Write” > 18    < action rdf:datatype=“& xsd;string” > Write </action > 19 </Operation > 20 <AccessDecision rdf:ID=“AccessDecision_Granted” > 21    < decision rdf:datatype=“& xsd;string” > Granted </decision > 22 </AccessDecision > 23 <ContextualCondition rdf:ID=“ContextualCondition_ContextInfo” > 24    < hasContext rdf:resource=“#ComplexContext_ cc2”/ > 25 </ContextualCondition > 1 <CARPAPolicy rdf:ID=“ carpa1” > 2    < hasRole rdf:resource=“#Role_RegisteredNurse”/ > 3    < hasPermission rdf:resource=“#Permission_DMR_Write”/ > 4    < hasCondition rdf:resource=“#ContextualCondition_ContextInfo”/ > 5    < hasDecision rdf:resource=“#AccessDecision_Granted”/ > 6 </CARPAPolicy > 7 <Role rdf:ID=“Role_RegisteredNurse” > 8    < roleIdentity rdf:datatype=“& xsd;string” > RN00X </roleIdentity > 9 </Role > 10 <Permission rdf:ID=“Permission_DMR_Write” > 11    < hasResource rdf:resource=“#Resource_DMR”/ > 12    < hasOperation rdf:resource=“#Operation_Write”/ > 13 </Permission > 14 <Resource rdf:ID=“Resource_DMR” > 15    < resourceIdentity rdf:datatype=“& xsd;int” > 2 </resourceIdentity > 16 </Resource > 17 <Operation rdf:ID=“Operation_Write” > 18    < action rdf:datatype=“& xsd;string” > Write </action > 19 </Operation > 20 <AccessDecision rdf:ID=“AccessDecision_Granted” > 21    < decision rdf:datatype=“& xsd;string” > Granted </decision > 22 </AccessDecision > 23 <ContextualCondition rdf:ID=“ContextualCondition_ContextInfo” > 24    < hasContext rdf:resource=“#ComplexContext_ cc2”/ > 25 </ContextualCondition > View Large Table 12. An example CARPA policy for the registered nurse. 1 <CARPAPolicy rdf:ID=“ carpa1” > 2    < hasRole rdf:resource=“#Role_RegisteredNurse”/ > 3    < hasPermission rdf:resource=“#Permission_DMR_Write”/ > 4    < hasCondition rdf:resource=“#ContextualCondition_ContextInfo”/ > 5    < hasDecision rdf:resource=“#AccessDecision_Granted”/ > 6 </CARPAPolicy > 7 <Role rdf:ID=“Role_RegisteredNurse” > 8    < roleIdentity rdf:datatype=“& xsd;string” > RN00X </roleIdentity > 9 </Role > 10 <Permission rdf:ID=“Permission_DMR_Write” > 11    < hasResource rdf:resource=“#Resource_DMR”/ > 12    < hasOperation rdf:resource=“#Operation_Write”/ > 13 </Permission > 14 <Resource rdf:ID=“Resource_DMR” > 15    < resourceIdentity rdf:datatype=“& xsd;int” > 2 </resourceIdentity > 16 </Resource > 17 <Operation rdf:ID=“Operation_Write” > 18    < action rdf:datatype=“& xsd;string” > Write </action > 19 </Operation > 20 <AccessDecision rdf:ID=“AccessDecision_Granted” > 21    < decision rdf:datatype=“& xsd;string” > Granted </decision > 22 </AccessDecision > 23 <ContextualCondition rdf:ID=“ContextualCondition_ContextInfo” > 24    < hasContext rdf:resource=“#ComplexContext_ cc2”/ > 25 </ContextualCondition > 1 <CARPAPolicy rdf:ID=“ carpa1” > 2    < hasRole rdf:resource=“#Role_RegisteredNurse”/ > 3    < hasPermission rdf:resource=“#Permission_DMR_Write”/ > 4    < hasCondition rdf:resource=“#ContextualCondition_ContextInfo”/ > 5    < hasDecision rdf:resource=“#AccessDecision_Granted”/ > 6 </CARPAPolicy > 7 <Role rdf:ID=“Role_RegisteredNurse” > 8    < roleIdentity rdf:datatype=“& xsd;string” > RN00X </roleIdentity > 9 </Role > 10 <Permission rdf:ID=“Permission_DMR_Write” > 11    < hasResource rdf:resource=“#Resource_DMR”/ > 12    < hasOperation rdf:resource=“#Operation_Write”/ > 13 </Permission > 14 <Resource rdf:ID=“Resource_DMR” > 15    < resourceIdentity rdf:datatype=“& xsd;int” > 2 </resourceIdentity > 16 </Resource > 17 <Operation rdf:ID=“Operation_Write” > 18    < action rdf:datatype=“& xsd;string” > Write </action > 19 </Operation > 20 <AccessDecision rdf:ID=“AccessDecision_Granted” > 21    < decision rdf:datatype=“& xsd;string” > Granted </decision > 22 </AccessDecision > 23 <ContextualCondition rdf:ID=“ContextualCondition_ContextInfo” > 24    < hasContext rdf:resource=“#ComplexContext_ cc2”/ > 25 </ContextualCondition > View Large The contextual condition cc2 is already expressed in Formula (21), using logical composition (see Section 3.3). Definition 12 shows its ontological definition. Definition 12 (‘ cc2’ Contextual Condition Definition).    <ComplexContextrdf:ID=“ComplexContext_cc2”>    <interRelationship(User,Owner)    rdf:datatype=“&xsd;string”>AssignedNurse    </interRelationship(User,Owner)>    <Owner.healthStatus    rdf:datatype=“&xsd;string”>    Normal</Owner.healthStatus>    </ComplexContext>    <ComplexContextrdf:ID=“ComplexContext_cc2”>    <interRelationship(User,Owner)    rdf:datatype=“&xsd;string”>AssignedNurse    </interRelationship(User,Owner)>    <Owner.healthStatus    rdf:datatype=“&xsd;string”>    Normal</Owner.healthStatus>    </ComplexContext>    <ComplexContextrdf:ID=“ComplexContext_cc2”>    <interRelationship(User,Owner)    rdf:datatype=“&xsd;string”>AssignedNurse    </interRelationship(User,Owner)>    <Owner.healthStatus    rdf:datatype=“&xsd;string”>    Normal</Owner.healthStatus>    </ComplexContext>    <ComplexContextrdf:ID=“ComplexContext_cc2”>    <interRelationship(User,Owner)    rdf:datatype=“&xsd;string”>AssignedNurse    </interRelationship(User,Owner)>    <Owner.healthStatus    rdf:datatype=“&xsd;string”>    Normal</Owner.healthStatus>    </ComplexContext> 4.4. Representation and reasoning about context information In Section 3.3.2, the context specification language is used to formally specify the contextual conditions using the relational and user-defined operators. In our ontology-based approach, we use the semantic technologies to realize our formal model and provide a practical basis of the CAAC policy framework. We use the OWL ontology language [24] to model the context ontology, representing the context entities and low-level context information. OWL-based reasoning rules are not always sufficient to infer the high-level implicit context information from the low-level information. We use the SWRL rule language [25] and its built-in functions [26] to specify the reasoning rules and infer the high-level context information (e.g. the interpersonal relationships between persons) in our ontology. As such, we codify two categories of reasoning rules: a set of operator-defined rules using the SWRL built-in functions and another set of rules using the user-defined properties (which are the object type properties in our context ontology [19]). Table 13 shows a reasoning rule to derive the implicit information about whether two persons are located in the same place or not. This co-located relationship is inferred using a user-defined property includedIn (object property), which represents the spatial inclusions. In our context ontology, we specify the EmergencyRoom class as a subclass of Hospital class and an object property includedIn links these two classes. The reasoning rule in Table 13 is used to derive the user and patient (resource owner) are “coLocated” in the emergency room of the hospital. Table 13. An example reasoning rule to derive location-centric relationship. User(?u) ∧Owner(?o) ∧Hospital(?hos) ∧EmergencyRoom(?em1) ∧includedIn(?em1, ?hos) ∧EmergencyRoom(?em2) ∧includedIn(?em2, ?hos) ∧locationAddress(?u, ?em1) ∧locationAddress(?o, ?em2) ∧Location-Centric(?rel) ∧hasRelationship(?u, ?rel) ∧hasRelationship(?o, ?rel) →locationCentricRelationship(?rel, “coLocated”) User(?u) ∧Owner(?o) ∧Hospital(?hos) ∧EmergencyRoom(?em1) ∧includedIn(?em1, ?hos) ∧EmergencyRoom(?em2) ∧includedIn(?em2, ?hos) ∧locationAddress(?u, ?em1) ∧locationAddress(?o, ?em2) ∧Location-Centric(?rel) ∧hasRelationship(?u, ?rel) ∧hasRelationship(?o, ?rel) →locationCentricRelationship(?rel, “coLocated”) View Large Table 13. An example reasoning rule to derive location-centric relationship. User(?u) ∧Owner(?o) ∧Hospital(?hos) ∧EmergencyRoom(?em1) ∧includedIn(?em1, ?hos) ∧EmergencyRoom(?em2) ∧includedIn(?em2, ?hos) ∧locationAddress(?u, ?em1) ∧locationAddress(?o, ?em2) ∧Location-Centric(?rel) ∧hasRelationship(?u, ?rel) ∧hasRelationship(?o, ?rel) →locationCentricRelationship(?rel, “coLocated”) User(?u) ∧Owner(?o) ∧Hospital(?hos) ∧EmergencyRoom(?em1) ∧includedIn(?em1, ?hos) ∧EmergencyRoom(?em2) ∧includedIn(?em2, ?hos) ∧locationAddress(?u, ?em1) ∧locationAddress(?o, ?em2) ∧Location-Centric(?rel) ∧hasRelationship(?u, ?rel) ∧hasRelationship(?o, ?rel) →locationCentricRelationship(?rel, “coLocated”) View Large An operator-defined reasoning rule (using a built-in operator swrlb:equal to compare the first and second arguments are the same) to derive the interpersonal relationship between user and patient is specified in Table 14. The interpersonal relationship is inferred from the low-level context information through our context ontology, i.e. from the user’s personal profile and the patient’s social profile information. The reasoning rule in Table 14 is used to determine the user and patient have a “assignedNurse” relationship. Table 14. An example reasoning rule to derive interpersonal or person-centric relationship. User(?u) ∧Role(?rol) ∧hasRole(?u, ?rol) ∧swrlb:equal(?rol, “RegisteredNurse”) ∧Owner(?o) ∧Person-Centric(?rel) ∧hasRelationship(?u, ?rel) ∧hasRelationship(?o, ?rel) ∧PersonalProfile(?pp) ∧hasProfile(?u, ?pp) ∧userIdentity(?pp, ?userID) ∧roleIdentity(?pp, ?roleID) ∧SocialProfile(?sp) ∧hasProfile(?o, ?sp) ∧connectedPeopleIdentity(?sp, ?connID) ∧connectedPeopleRoleIdentity(?sp, ?connRoleID) ∧swrlb:equal(?userID, ?connID) ∧swrlb:equal(?roleID, ?connRoleID) →interRelationship(?rel, “assignedNurse”) User(?u) ∧Role(?rol) ∧hasRole(?u, ?rol) ∧swrlb:equal(?rol, “RegisteredNurse”) ∧Owner(?o) ∧Person-Centric(?rel) ∧hasRelationship(?u, ?rel) ∧hasRelationship(?o, ?rel) ∧PersonalProfile(?pp) ∧hasProfile(?u, ?pp) ∧userIdentity(?pp, ?userID) ∧roleIdentity(?pp, ?roleID) ∧SocialProfile(?sp) ∧hasProfile(?o, ?sp) ∧connectedPeopleIdentity(?sp, ?connID) ∧connectedPeopleRoleIdentity(?sp, ?connRoleID) ∧swrlb:equal(?userID, ?connID) ∧swrlb:equal(?roleID, ?connRoleID) →interRelationship(?rel, “assignedNurse”) View Large Table 14. An example reasoning rule to derive interpersonal or person-centric relationship. User(?u) ∧Role(?rol) ∧hasRole(?u, ?rol) ∧swrlb:equal(?rol, “RegisteredNurse”) ∧Owner(?o) ∧Person-Centric(?rel) ∧hasRelationship(?u, ?rel) ∧hasRelationship(?o, ?rel) ∧PersonalProfile(?pp) ∧hasProfile(?u, ?pp) ∧userIdentity(?pp, ?userID) ∧roleIdentity(?pp, ?roleID) ∧SocialProfile(?sp) ∧hasProfile(?o, ?sp) ∧connectedPeopleIdentity(?sp, ?connID) ∧connectedPeopleRoleIdentity(?sp, ?connRoleID) ∧swrlb:equal(?userID, ?connID) ∧swrlb:equal(?roleID, ?connRoleID) →interRelationship(?rel, “assignedNurse”) User(?u) ∧Role(?rol) ∧hasRole(?u, ?rol) ∧swrlb:equal(?rol, “RegisteredNurse”) ∧Owner(?o) ∧Person-Centric(?rel) ∧hasRelationship(?u, ?rel) ∧hasRelationship(?o, ?rel) ∧PersonalProfile(?pp) ∧hasProfile(?u, ?pp) ∧userIdentity(?pp, ?userID) ∧roleIdentity(?pp, ?roleID) ∧SocialProfile(?sp) ∧hasProfile(?o, ?sp) ∧connectedPeopleIdentity(?sp, ?connID) ∧connectedPeopleRoleIdentity(?sp, ?connRoleID) ∧swrlb:equal(?userID, ?connID) ∧swrlb:equal(?roleID, ?connRoleID) →interRelationship(?rel, “assignedNurse”) View Large Further details of the representation and reasoning about relevant context information can be found in the ontology-based context model, which has been presented in our earlier work [19, 21]. 5. PROTOTYPE ARCHITECTURE This section introduces the policy enforcement architecture (PEA) of our framework and describes its components. PEA extends our previous implementation prototype, which is reported in [19]. 5.1. Prototype Figure 6 gives an overview of the PEA architecture. It includes four main components: Context Repository, CAAC Policies (CAURA and CARPA policies), CAAC PDP (policy decision point) and CAAC PEP (policy enforcement point). Figure 6. View largeDownload slide The policy enforcement architecture. Figure 6. View largeDownload slide The policy enforcement architecture. The Context Repository stores the access control-specific context information in the form of a context ontology, including user-centric context information (e.g. requester profile), resource-centric context information (e.g. resource profile) and environment-centric context information (e.g. user’s location, and interpersonal relationship between user and owner). Consequently, the contextual conditions for the user-role and role-permission assignments are specified in the Context Repository in terms of relevant context information. The CAURA Policy and CARPA Policy ontologies store two sets of policies that show a mapping between users and roles, and roles and permissions, respectively, according to the relevant contextual conditions that are in effect. We have used the Protégé-OWL API [27] to implement the context and policy ontologies. We have used the Jess Rule Engine [28] for executing the SWRL rules (user-defined reasoning rules) [25]. We have implemented the CAAC PDP and CAAC PEP in Java to evaluate the policies for making context-aware access control decisions. Once the CAAC PEP receives the user’s request for resource access, it queries the CAAC PDP for the applicable policies and currently available context information in the ontologies. The CAAC PDP makes the decision according to the policies and context information. Finally, the CAAC PDP informs the CAAC PEP of the decision, and the CAAC PEP enforces the decision by granting or denying the user’s access request. The detailed implementation of the components of our prototype can be found in Section 6.5. 6. THE EVALUATION OF THE ONTOLOGY-BASED POLICY MODEL AND FRAMEWORK In this section, we demonstrate the feasibility of our proposed ontology-based policy framework. We aim to show that the policy ontology model and framework offers complete and correct semantics and shows its efficiency in terms of response time. Our evaluation considers the following factors, namely, the completeness, correctness and consistency of the application of our policy ontology through a healthcare case study, the performance of the CAAC policy framework in terms of response time and the usability of the framework in the laboratory setup. 6.1. Completeness First, we evaluate the completeness of the application of our policy ontology model. As such, we in this section present the patient medical records management (PMRM) application, covering our framework features: contextual conditions, context-aware user role assignment (CAURA) policies and context-aware role-permission assignment (CARPA) policies. The main goal of this PMRM application is to control the users’ access (read or write operation) to different medical records of patients based on the dynamic context information. We present below two test cases (i.e. the emergency and normal cases from our application scenario presented in Section 2) that highlight specific policy requirements of the PMRM application, and demonstrate how the dynamic context information (contextual conditions) is incorporated into the CAURA and CARPA policies. 6.1.1. Revisiting the application scenario—emergency case Consider the scenario when Jane (who is a general physician) wants to access the emergency medical records of patient Bob, an access request is submitted to the CAAC PEP (which is a part of the Policy Enforcement Architecture (PEA)) for evaluation. The CAAC PEP forwards the request to the CAAC PDP, which captures the applicable access control policies in the policy ontology. It also captures the relevant context information in the context repository. For Scene #1, Jane’s resource access request is shown as follows: <user=(Jane),permission=(EMR(Bob),write)> The core policy ontology captures the relevant policy constraints applicable to the user-role assignment: user-centric, resource-centric and environmental context information. The contextual condition cs2 (shown in Table 15) is modeled/captured in our ontology, based on the available context information. It shows that the users can play the emergency doctors role from the emergency room of the hospital. Table 15. ‘ cs2’ contextual condition definition. cs2=(User.locationAddress=“EmergencyRoom”) cs2=(User.locationAddress=“EmergencyRoom”) View Large Table 15. ‘ cs2’ contextual condition definition. cs2=(User.locationAddress=“EmergencyRoom”) cs2=(User.locationAddress=“EmergencyRoom”) View Large Table 16 shows the context-aware user-role assignment (CAURA) policy for emergency doctors. The policy states that the users can play the emergency doctor role when they are present in the emergency room of the hospital. In this policy, the access decision is based on the following policy constraints: who the user is (user’s identity), what role the user can play (role’s identity) and under what contextual condition (the location of the user). The CAURA policy for the emergency doctors is shown in Table 16. The core policy concepts are specified in Line# 1–6, the user specification is shown in Line# 7–8, the role specification (emergency doctor) is shown in Line# 9 and 10, the contextual condition (⁠ cs2 ⁠) is specified in Line# 11 and the context-aware user-role assignment (⁠ caura ⁠) is specified in Line# 12–13. Table 16. An example CAURA policy for the emergency doctors. 1 If 2    CAURAPolicy(caura2)∧ 3    User(u)∧hasUser(caura2,u)∧ 4    Role(r)∧hasRole(caura2,r)∧ 5    ContextualCondition(exp)∧ 6    hasCondition(caura2,exp)∧ 7    has(u,userIdentity)∧ 8    equal(userIdentity,“doctorIdentity”)∧ 9    has(r,roleIdentity)∧ 10    equal(roleIdentity,“ED00X”)∧ 11    equal(exp,“cs2”) 12 Then 13    caura(u,r) 1 If 2    CAURAPolicy(caura2)∧ 3    User(u)∧hasUser(caura2,u)∧ 4    Role(r)∧hasRole(caura2,r)∧ 5    ContextualCondition(exp)∧ 6    hasCondition(caura2,exp)∧ 7    has(u,userIdentity)∧ 8    equal(userIdentity,“doctorIdentity”)∧ 9    has(r,roleIdentity)∧ 10    equal(roleIdentity,“ED00X”)∧ 11    equal(exp,“cs2”) 12 Then 13    caura(u,r) View Large Table 16. An example CAURA policy for the emergency doctors. 1 If 2    CAURAPolicy(caura2)∧ 3    User(u)∧hasUser(caura2,u)∧ 4    Role(r)∧hasRole(caura2,r)∧ 5    ContextualCondition(exp)∧ 6    hasCondition(caura2,exp)∧ 7    has(u,userIdentity)∧ 8    equal(userIdentity,“doctorIdentity”)∧ 9    has(r,roleIdentity)∧ 10    equal(roleIdentity,“ED00X”)∧ 11    equal(exp,“cs2”) 12 Then 13    caura(u,r) 1 If 2    CAURAPolicy(caura2)∧ 3    User(u)∧hasUser(caura2,u)∧ 4    Role(r)∧hasRole(caura2,r)∧ 5    ContextualCondition(exp)∧ 6    hasCondition(caura2,exp)∧ 7    has(u,userIdentity)∧ 8    equal(userIdentity,“doctorIdentity”)∧ 9    has(r,roleIdentity)∧ 10    equal(roleIdentity,“ED00X”)∧ 11    equal(exp,“cs2”) 12 Then 13    caura(u,r) View Large The policy ontology also captures the relevant policy constraints applicable to the role-permission assignment. Table 17 expresses the contextual condition (⁠ cs3 ⁠) according to the relevant context information (the health status of the patient). Table 17. ‘ cs3’ contextual condition definition. cs3=(Owner.healthStatus=“Critical”) cs3=(Owner.healthStatus=“Critical”) View Large Table 17. ‘ cs3’ contextual condition definition. cs3=(Owner.healthStatus=“Critical”) cs3=(Owner.healthStatus=“Critical”) View Large Table 18 presents the context-aware role-permission assignment (CARPA) policy for emergency doctors. It states that the emergency doctors can access the patient’s emergency medical records when the patient’s health condition is critical. In this policy, the access decision is based on the following policy constraints: who the user is (user’s role), what resource is being requested (resource’s identity) and under what contextual condition the user sends the request (the health status of the patient). The CARPA policy for the emergency doctors is shown in Table 18. The core policy concepts are specified in Line# 1–7, the role specification (emergency doctor) is shown in Line# 8 and 9, the permission specification (emergency medical records on write operation) is shown in Line# 10–14, the contextual condition (⁠ cs3 ⁠) is specified in Line# 15 and the context-aware role-permission assignment (⁠ carpa ⁠) is specified in Line# 16 and 17. Table 18. An example CARPA policy for the emergency doctors. 1 If 2    CARPAPolicy(carpa2)∧ 3    Role(r)∧hasRole(carpa2,r)∧ 4    Permission(p)∧ 5    hasPermission(carpa2,p)∧ 6    ContextualCondition(exp)∧ 7    hasCondition(carpa2,exp)∧ 8    has(r,roleIdentity)∧ 9    equal(roleIdentity,“ED00X”)∧ 10    Resource(res)∧hasResource(p,res)∧ 11    Operation(op)∧hasOperation(p,op)∧ 12    has(res,resourceIdentity)∧ 13    equal(resourceIdentity,1)∧ 14    has(op,action)∧equal(action,“write”)∧ 15    equal(exp,“cs3”) 16 Then 17    carpa(r,p) 1 If 2    CARPAPolicy(carpa2)∧ 3    Role(r)∧hasRole(carpa2,r)∧ 4    Permission(p)∧ 5    hasPermission(carpa2,p)∧ 6    ContextualCondition(exp)∧ 7    hasCondition(carpa2,exp)∧ 8    has(r,roleIdentity)∧ 9    equal(roleIdentity,“ED00X”)∧ 10    Resource(res)∧hasResource(p,res)∧ 11    Operation(op)∧hasOperation(p,op)∧ 12    has(res,resourceIdentity)∧ 13    equal(resourceIdentity,1)∧ 14    has(op,action)∧equal(action,“write”)∧ 15    equal(exp,“cs3”) 16 Then 17    carpa(r,p) View Large Table 18. An example CARPA policy for the emergency doctors. 1 If 2    CARPAPolicy(carpa2)∧ 3    Role(r)∧hasRole(carpa2,r)∧ 4    Permission(p)∧ 5    hasPermission(carpa2,p)∧ 6    ContextualCondition(exp)∧ 7    hasCondition(carpa2,exp)∧ 8    has(r,roleIdentity)∧ 9    equal(roleIdentity,“ED00X”)∧ 10    Resource(res)∧hasResource(p,res)∧ 11    Operation(op)∧hasOperation(p,op)∧ 12    has(res,resourceIdentity)∧ 13    equal(resourceIdentity,1)∧ 14    has(op,action)∧equal(action,“write”)∧ 15    equal(exp,“cs3”) 16 Then 17    carpa(r,p) 1 If 2    CARPAPolicy(carpa2)∧ 3    Role(r)∧hasRole(carpa2,r)∧ 4    Permission(p)∧ 5    hasPermission(carpa2,p)∧ 6    ContextualCondition(exp)∧ 7    hasCondition(carpa2,exp)∧ 8    has(r,roleIdentity)∧ 9    equal(roleIdentity,“ED00X”)∧ 10    Resource(res)∧hasResource(p,res)∧ 11    Operation(op)∧hasOperation(p,op)∧ 12    has(res,resourceIdentity)∧ 13    equal(resourceIdentity,1)∧ 14    has(op,action)∧equal(action,“write”)∧ 15    equal(exp,“cs3”) 16 Then 17    carpa(r,p) View Large Based on these CAURA and CARPA policies (Tables 16 and 18), the CAAC PDP (Fig. 6) determines whether the request is “granted” or “denied” for the submitted access request, and returns the access decision to the CAAC PEP. Finally, the CAAC PEP enforces the context-aware access control decision, based on the applicable policies and the relevant contextual conditions. If the decision is “granted”, the requested resource is sent to the user; otherwise, a “denied” response is sent to the user. For the application example (Scene #1), Jane’s resource access permission (“EMR_write”) is granted ⁠. This case study for the test scenario shows that our policy framework is able to successfully make access control decisions through context-aware user-role and role-permission assignments. In this scenario, Jane is not an emergency doctor, but he can play the emergency doctor role from the emergency room of the hospital and is allowed to access Bob’s emergency medical records in such a critical situation. On the other hand, when the context changes (e.g. Jane leaves the emergency room, or Bob’s health condition changes from critical to normal), the system will not grant Jane the access to the requested resource. In general, at each time of an access request or when context changes, the CAAC PEP sends automated request to the CAAC PDP for the applicable access control policies and the relevant context information. 6.1.2. Revisiting the application scenario—normal case For Scene #2 in our application scenario, where a registered nurse Mary wants to access Bob’s daily medical records (DMR), an access request is submitted to the CAAC PEP for evaluation. Mary’s resource access request is shown as follows: <user=(Mary),permission=(DMR(Bob),write)> Table 19 shows the CAURA policy to play the registered nurse role. The policy states that a user having a nurse identity can play the registered nurse role from the general ward of the hospital during her ward shift time. The specification of the contextual condition associated with this policy, named cc1 (during ward duty time from the general ward of the hospital), is expressed in Formula (20), using logical composition (see Section 3.3). Table 19. CAURA policy for the registered nurses. 1 If 2    CAURAPolicy(caura1)∧ 3    User(u)∧hasUser(caura1,u)∧ 4    Role(r)∧hasRole(caura1,r)∧ 5    ContextualCondition(exp)∧ 6    hasCondition(caura1,exp)∧ 7    has(u,userIdentity)∧ 8    equal(userIdentity,“nurseIdentity”)∧ 9    has(r,roleIdentity)∧ 10    equal(roleIdentity,“RN00X”)∧ 11    equal(exp,“cc1”) 12 Then 13    caura(u,r) 1 If 2    CAURAPolicy(caura1)∧ 3    User(u)∧hasUser(caura1,u)∧ 4    Role(r)∧hasRole(caura1,r)∧ 5    ContextualCondition(exp)∧ 6    hasCondition(caura1,exp)∧ 7    has(u,userIdentity)∧ 8    equal(userIdentity,“nurseIdentity”)∧ 9    has(r,roleIdentity)∧ 10    equal(roleIdentity,“RN00X”)∧ 11    equal(exp,“cc1”) 12 Then 13    caura(u,r) View Large Table 19. CAURA policy for the registered nurses. 1 If 2    CAURAPolicy(caura1)∧ 3    User(u)∧hasUser(caura1,u)∧ 4    Role(r)∧hasRole(caura1,r)∧ 5    ContextualCondition(exp)∧ 6    hasCondition(caura1,exp)∧ 7    has(u,userIdentity)∧ 8    equal(userIdentity,“nurseIdentity”)∧ 9    has(r,roleIdentity)∧ 10    equal(roleIdentity,“RN00X”)∧ 11    equal(exp,“cc1”) 12 Then 13    caura(u,r) 1 If 2    CAURAPolicy(caura1)∧ 3    User(u)∧hasUser(caura1,u)∧ 4    Role(r)∧hasRole(caura1,r)∧ 5    ContextualCondition(exp)∧ 6    hasCondition(caura1,exp)∧ 7    has(u,userIdentity)∧ 8    equal(userIdentity,“nurseIdentity”)∧ 9    has(r,roleIdentity)∧ 10    equal(roleIdentity,“RN00X”)∧ 11    equal(exp,“cc1”) 12 Then 13    caura(u,r) View Large The CARPA policy for the registered nurses is shown in Table 20. The policy states that a registered nurse, who is assigned for a regular follow-up visit to monitor a patient’s health condition, can access the patient’s daily medical records (resource identity is 2) when the patient’s health condition is normal. The specification of the contextual condition cc2 (the nurse is assigned for the patient and the patient’s health status is normal) is expressed in Formula (21) in Section 3.3. Table 20. CARPA policy for the registered nurses. 1 If 2    CARPAPolicy(carpa1)∧ 3    Role(r)∧hasRole(carpa1,r)∧ 4    Permission(p)∧ 5    hasPermission(carpa1,p)∧ 6    ContextualCondition(exp)∧ 7    hasCondition(carpa1,exp)∧ 8    has(r,roleIdentity)∧ 9    equal(roleIdentity,“RN00X”)∧ 10    Resource(res)∧hasResource(p,res)∧ 11    Operation(op)∧hasOperation(p,op)∧ 12    has(res,resourceIdentity)∧ 13    equal(resourceIdentity,2)∧ 14    has(op,action)∧equal(action,“write”)∧ 15    equal(exp,“cc2”) 16 Then 17    carpa(r,p) 1 If 2    CARPAPolicy(carpa1)∧ 3    Role(r)∧hasRole(carpa1,r)∧ 4    Permission(p)∧ 5    hasPermission(carpa1,p)∧ 6    ContextualCondition(exp)∧ 7    hasCondition(carpa1,exp)∧ 8    has(r,roleIdentity)∧ 9    equal(roleIdentity,“RN00X”)∧ 10    Resource(res)∧hasResource(p,res)∧ 11    Operation(op)∧hasOperation(p,op)∧ 12    has(res,resourceIdentity)∧ 13    equal(resourceIdentity,2)∧ 14    has(op,action)∧equal(action,“write”)∧ 15    equal(exp,“cc2”) 16 Then 17    carpa(r,p) View Large Table 20. CARPA policy for the registered nurses. 1 If 2    CARPAPolicy(carpa1)∧ 3    Role(r)∧hasRole(carpa1,r)∧ 4    Permission(p)∧ 5    hasPermission(carpa1,p)∧ 6    ContextualCondition(exp)∧ 7    hasCondition(carpa1,exp)∧ 8    has(r,roleIdentity)∧ 9    equal(roleIdentity,“RN00X”)∧ 10    Resource(res)∧hasResource(p,res)∧ 11    Operation(op)∧hasOperation(p,op)∧ 12    has(res,resourceIdentity)∧ 13    equal(resourceIdentity,2)∧ 14    has(op,action)∧equal(action,“write”)∧ 15    equal(exp,“cc2”) 16 Then 17    carpa(r,p) 1 If 2    CARPAPolicy(carpa1)∧ 3    Role(r)∧hasRole(carpa1,r)∧ 4    Permission(p)∧ 5    hasPermission(carpa1,p)∧ 6    ContextualCondition(exp)∧ 7    hasCondition(carpa1,exp)∧ 8    has(r,roleIdentity)∧ 9    equal(roleIdentity,“RN00X”)∧ 10    Resource(res)∧hasResource(p,res)∧ 11    Operation(op)∧hasOperation(p,op)∧ 12    has(res,resourceIdentity)∧ 13    equal(resourceIdentity,2)∧ 14    has(op,action)∧equal(action,“write”)∧ 15    equal(exp,“cc2”) 16 Then 17    carpa(r,p) View Large Based on the above CAURA and CARPA policies (Tables 19 and 20), we can observe that Mary can play the registered nurse role if she is located in the general ward during her ward shift time and consequently, she is authorized to access the daily medical records of patient Bob, who is hosted in that ward in his normal health condition. For the same scenario (Scene #2), let us consider another access control policy: a registered nurse, who is assigned to monitor the patient’s health condition, can access the patient’s private medical records (PMR) if she is present with the patient. Mary’s resource access request is shown as follows: <user=(Mary),permission=(PMR(Bob),read)> The same CAURA policy specified in Table 19 can be used for the user-role assignment. It states that Mary can play the registered nurse role from the general ward of the hospital during her ward duty time. The CARPA policy for the registered nurse is shown in Table 21. The policy states that a registered nurse can access the patient’s private medical records (resource identity is 3), satisfying the contextual condition cc3 ⁠. The specification of cc3 (the nurse is assigned to monitor the patient’s health condition, and they both are co-located and the patient’s health status is normal) is expressed in Table 22. Table 21. CARPA policy for the registered nurses. 1 If 2    CARPAPolicy(carpa3)∧ 3    Role(r)∧hasRole(carpa1,r)∧ 4    Permission(p)∧ 5    hasPermission(carpa1,p)∧ 6    ContextualCondition(exp)∧ 7    hasCondition(carpa1,exp)∧ 8    has(r,roleIdentity)∧ 9    equal(roleIdentity,“RN00X”)∧ 10    Resource(res)∧hasResource(p,res)∧ 11    Operation(op)∧hasOperation(p,op)∧ 12    has(res,resourceIdentity)∧ 13    equal(resourceIdentity,3)∧ 14    has(op,action)∧equal(action,“read”)∧ 15    equal(exp,“cc3”) 16 Then 17    carpa(r,p) 1 If 2    CARPAPolicy(carpa3)∧ 3    Role(r)∧hasRole(carpa1,r)∧ 4    Permission(p)∧ 5    hasPermission(carpa1,p)∧ 6    ContextualCondition(exp)∧ 7    hasCondition(carpa1,exp)∧ 8    has(r,roleIdentity)∧ 9    equal(roleIdentity,“RN00X”)∧ 10    Resource(res)∧hasResource(p,res)∧ 11    Operation(op)∧hasOperation(p,op)∧ 12    has(res,resourceIdentity)∧ 13    equal(resourceIdentity,3)∧ 14    has(op,action)∧equal(action,“read”)∧ 15    equal(exp,“cc3”) 16 Then 17    carpa(r,p) View Large Table 21. CARPA policy for the registered nurses. 1 If 2    CARPAPolicy(carpa3)∧ 3    Role(r)∧hasRole(carpa1,r)∧ 4    Permission(p)∧ 5    hasPermission(carpa1,p)∧ 6    ContextualCondition(exp)∧ 7    hasCondition(carpa1,exp)∧ 8    has(r,roleIdentity)∧ 9    equal(roleIdentity,“RN00X”)∧ 10    Resource(res)∧hasResource(p,res)∧ 11    Operation(op)∧hasOperation(p,op)∧ 12    has(res,resourceIdentity)∧ 13    equal(resourceIdentity,3)∧ 14    has(op,action)∧equal(action,“read”)∧ 15    equal(exp,“cc3”) 16 Then 17    carpa(r,p) 1 If 2    CARPAPolicy(carpa3)∧ 3    Role(r)∧hasRole(carpa1,r)∧ 4    Permission(p)∧ 5    hasPermission(carpa1,p)∧ 6    ContextualCondition(exp)∧ 7    hasCondition(carpa1,exp)∧ 8    has(r,roleIdentity)∧ 9    equal(roleIdentity,“RN00X”)∧ 10    Resource(res)∧hasResource(p,res)∧ 11    Operation(op)∧hasOperation(p,op)∧ 12    has(res,resourceIdentity)∧ 13    equal(resourceIdentity,3)∧ 14    has(op,action)∧equal(action,“read”)∧ 15    equal(exp,“cc3”) 16 Then 17    carpa(r,p) View Large Table 22. ‘ cc3’ contextual condition definition. cc3=((Owner.healthStatus=“Normal”)∧     (interRelationship(User,Owner) =“AssignedNurse”)∧     (locationCentricRelationship(User,Owner)   =“Colocated”)) cc3=((Owner.healthStatus=“Normal”)∧     (interRelationship(User,Owner) =“AssignedNurse”)∧     (locationCentricRelationship(User,Owner)   =“Colocated”)) View Large Table 22. ‘ cc3’ contextual condition definition. cc3=((Owner.healthStatus=“Normal”)∧     (interRelationship(User,Owner) =“AssignedNurse”)∧     (locationCentricRelationship(User,Owner)   =“Colocated”)) cc3=((Owner.healthStatus=“Normal”)∧     (interRelationship(User,Owner) =“AssignedNurse”)∧     (locationCentricRelationship(User,Owner)   =“Colocated”)) View Large Based on the CAURA and CARPA policies (Tables 19 and 21), we can observe that Mary can play the registered nurse role if she is located in the general ward during her ward shift time and consequently, she is authorized to access the private medical records of patient Bob, who is hosted in that ward in his normal health condition (as she is assigned to regularly monitor the health condition of the patient Bob). 6.1.3. Discussion In the above-mentioned case study, we consider the dynamic user-role and role-permission associations based on the relevant contextual conditions, which is one of the key contributions of this paper. In the application scenario (Scene #2), Mary, a registered nurse who is assigned to look after Bob, can access his daily medical records during her ward duty time when she is present with Bob in the general ward of the hospital. When the context changes (e.g. Mary leaves the general ward), decisions on further access requests by Mary to Bob’s daily medical records may change accordingly (i.e. access permission is denied). That is, Mary only can play the assigned nurse role only when she is co-located with Bob in the general ward of the hospital. However, she still can play the registered nurse role to do her usual duties. The case study for the two test scenarios guarantees the completeness of the application of our policy ontology model. We observe that the CAAC policies for the two application scenarios are successfully specified by instantiating the domain-specific ontologies with the core policy ontology. Thus, the completeness of the policy ontology through presenting a case study from the healthcare domain shows the applicability of our policy framework. 6.2. Correctness Second, we assess the correctness of the policy ontology [29] against the healthcare case study. As such, we add some new domain-specific concepts into the ontology and specify the relevant context-aware access control policies. Also, we delete some ontology concepts. To identify the relevant changes, we execute some SQWRL queries [30]. Finally, we verify these query results to evaluate the semantic correctness of the policy ontology. We have added some domain-specific concepts (individuals and attribute values) into the ontology and specified relevant CAAC policy rules (i.e. CAURA and CARPA policies). Then, we have executed some SQWRL queries to retrieve the query results starting with the empty query. For example, we have added a new Role named GuestResearcher (simply, GR) and an individual named Tom (who is an instance of GuestResearcher) to the role ontology. The researchers are not directly healthcare members but they may need to access some of the patient information. The details of role ontology can be found in our earlier work [19]. Also, we have specified the relevant CAAC policies for guest researchers. The user-role and role-permission policy specifications are already discussed in Section 6.1. Table 23 shows a SQWRL query to retrieve knowledge from policy ontology and Table 24 shows the query result. The result shows that Tom is authorized to access (read permission) the patient’s medical records. For simplicity, the relevant contextual conditions and other policy constraints are not shown in Tables 23 and 24. Table 23. Query 1. User(?user) ∧ Role(?role) ∧ Operation(?action) ∧ AccessDecision(?decision) →sqwrl:select(?user, ?role, ?action, ?decision) User(?user) ∧ Role(?role) ∧ Operation(?action) ∧ AccessDecision(?decision) →sqwrl:select(?user, ?role, ?action, ?decision) View Large Table 23. Query 1. User(?user) ∧ Role(?role) ∧ Operation(?action) ∧ AccessDecision(?decision) →sqwrl:select(?user, ?role, ?action, ?decision) User(?user) ∧ Role(?role) ∧ Operation(?action) ∧ AccessDecision(?decision) →sqwrl:select(?user, ?role, ?action, ?decision) View Large Table 24. Query 1 result. ?user role ?action ?decision Tom GR Read Granted ?user role ?action ?decision Tom GR Read Granted View Large Table 24. Query 1 result. ?user role ?action ?decision Tom GR Read Granted ?user role ?action ?decision Tom GR Read Granted View Large We have also deleted some domain-specific concepts from the ontology and executed some SQWRL queries to verify the changes. For example, all the RegisteredNurse instances are deleted from the ontology. Tables 25 and 26 show one of the relevant SQWRL queries and the query result respectively. The result shows no output, that is there are no applicable CAAC policies for RegisteredNurse. When any concept has been deleted from the ontology, the implemented ontology-based policy framework automatically removes the redundant access control policies accordingly. The query results in the above two tables demonstrate that our policy ontology contains correct semantic knowledge to instantiate the core ontology into its domain-specific ontologies. Table 25. Query 2. User(?user) ∧ Role(?role) ∧ Operation(?action) ∧ AccessDecision(?decision) →sqwrl:select(?user, ?role, ?action, ?decision) User(?user) ∧ Role(?role) ∧ Operation(?action) ∧ AccessDecision(?decision) →sqwrl:select(?user, ?role, ?action, ?decision) View Large Table 25. Query 2. User(?user) ∧ Role(?role) ∧ Operation(?action) ∧ AccessDecision(?decision) →sqwrl:select(?user, ?role, ?action, ?decision) User(?user) ∧ Role(?role) ∧ Operation(?action) ∧ AccessDecision(?decision) →sqwrl:select(?user, ?role, ?action, ?decision) View Large Table 26. Query 2 result. ?user ?role ?action ?decision – – – – ?user ?role ?action ?decision – – – – View Large Table 26. Query 2 result. ?user ?role ?action ?decision – – – – ?user ?role ?action ?decision – – – – View Large 6.3. Consistency verification Third, we assess the possible consistency of our policy ontology concepts. To this extent, we check the policy constraints. We model role in a hierarchical manner in order to facilitate fine-grained control of the different components of a resource (e.g. daily medical records, past medical history) for different roles of users. The following example illustrates the use of our policy ontology for verifying a policy constraint. Example 9 Consider a healthcare user u1 (Mary), who is a registered nurse and three healthcare roles r1 (NursingProfessional), r2 (RegisteredNurse) and r3 (NurseManager) in which r2 and r3 roles are junior to r1 role. In our ontology, we model this in a way that r1 is a superclass and r2 and r3 are the subclasses of r1 (see Fig. 7). This superclass–subclass hierarchy in the role ontology facilitates in a way similar to RBAC’s senior–junior role concept [5], which supports the concept of role inheritance as well. That is, if a user is assigned to a senior role, then she is also authorized to play all the junior roles of that role. However, she should fulfill the relevant contextual conditions. Consequently, if a permission is assigned to a senior role, then it also be assigned to all the junior roles of that role, by satisfying the relevant contextual conditions. Let us consider that r2 and r3 are two conflicting healthcare roles. That is, the RegisteredNurse and NurseManager roles cannot be assigned to the same user at the same time. However, based on the senior–junior role concept, the role NursingProfessional is superior to RegisteredNurse and NurseManager roles. That is, any user is assigned to NursingProfessional role means she is also authorized to play both the RegisteredNurse and NurseManager roles, by satisfying the relevant contextual conditions. Therefore, an access controller needs to check such user-role association constraints when enabling user-role assignments, including the above-mentioned inconsistency issue due to possible role conflict. Our context-aware user-role assignment policy deals with this issue of possible role conflict. For example, in our application scenario (Scene #2), Mary can play the NurseManager role when she is located in the hospital and during her duty time. Mary also can play the RegisteredNurse role and consequently can access the daily medical records of patient Bob as she is assigned to look after Bob but when she is co-located with him and during her ward duty time. On the other hand, Mary can play the NurseManager role only when she is not assigned to look after any patients and during her duty time when she is located in the hospital. Consequently, she can do her usual duties by playing such role. That is, Mary by playing NurseManager role always has a denied access to medical records of patient Bob. Towards this end, we specify a cardinality constraint in our policy ontology, where we consider a class AccessDecision and a data type property decision. An instance of AccessDecision class has “Granted” or “Denied” decision value (see Fig. 5 and Table 11). Figure 7. View largeDownload slide A part of the role hierarchy. Figure 7. View largeDownload slide A part of the role hierarchy. The above verification shows the reachability analysis of our policy ontology. It ensures the possible consistency that is required for a role-based access control framework to manage the different components of a resource in a fine-grained manner for different roles of users. In this paper, we do not show all the domain-specific ontologies for our healthcare application on the basis of the core ontology. A part of the role ontology is shown in Fig. 12 (see Section 6.5). Figure 12. View largeDownload slide A part of the role ontology. Figure 12. View largeDownload slide A part of the role ontology. 6.4. Performance In addition to the completeness, correctness and consistency, we assess the performance of our policy framework, where we measure the query response time to provide resource access permissions to users. We have conducted two sets of experiments with our framework as applied to the PMRM application on a Windows 8.1 operating system running on Intel(R) Core(TM) i7 @ 3.0 GHz processor with 8 GB of memory. Test 1: The first test focuses on measuring the response time of context-aware user-role assignments (CAURA) in the light of increasing the number of policy rules. We first codify 50 policy rules that are attached to 20 different health professionals roles (EmergencyDoctor, RegisteredNurse) according to the contextual conditions. Then, the number of policies is varied from 50 to 500 in increment of 50 with 138 different health professional roles [20]. In the case study section (see Section 6), we have already codified several CAURA policy rules. To measure the response time of CAURA assignments, the average value of the 10 execution runs is used for the analysis. The test results in Fig. 8 show that the average response time varies from 0.7 to 2.9 s approximately, as the number of CAURA policy rules changes and the size of the ontology KB (the context and policy ontologies) varies from 293 to 1738 kb, respectively. We can see that the response time seems to be linear, relative to the number of policies. Figure 8. View largeDownload slide Response time vs. number of policies. Figure 8. View largeDownload slide Response time vs. number of policies. Test 2: In this test, we have evaluated the response time of context-aware role-permission assignments (CARPA) when the number of policy rules increased. Similar to Test 1, first, we have selected 50 CARPA policy rules with respect to 20 different health professional roles, then, we have varied the number of policies up to 500 in increment of 50 with the same 138 roles [20]. Each of these variations is executed 10 times for the analysis. In the case study section, we have already codified several CARPA policy rules. The test results in Fig. 9 show that the response time increases when the number of policy rules increases. It varies between 0.8 and 3.2 s approximately, where the ontology KB size varies from 318 to 1926 kb, respectively. Similar to Test 1, in Fig. 9, we can see that the response time seems to be linear with respect to the number of policies. Figure 9. View largeDownload slide Response time vs. number of policies. Figure 9. View largeDownload slide Response time vs. number of policies. Discussion: In order to evaluate the performance of our proposed CAAC framework with respect to context changes, we have specified 1000 policy rules, including both the CAURA and CARPA policies and shown the different breakdowns of the performance. Upon receiving a resource access request from a user, our access controller captures and derives the relevant contextual conditions and consequently selects and executes the applicable access control policies. Figure 10 shows the main breakdowns of the performance: the context reasoning time and the policy evaluation time. The context reasoning time is the time taken to capture and derive the relevant contextual conditions. The access controller needs to re-evaluate the access control decisions when there are dynamic changes to the context. The policy evaluation time is the time taken to select and execute the applicable access control policies. The access controller does not need to re-evaluate all the steps for policy evaluation when any context changes. It only needs to execute the applicable access control policies that are selected before. The test results in Fig. 10 show that the context reasoning time is the main contributor in our approach. That is, the performance would be affected by this context reasoning time when any context changes. In such a case, the user (or requester) needs to wait for this period of time to receive a response when any context changes. Figure 10. View largeDownload slide Main breakdowns of the performance. Figure 10. View largeDownload slide Main breakdowns of the performance. In the above sets of experiments, the computational overhead increases at a linear rate due to increasing the ontology kb sizes with respect to different numbers of policies. At the point where we have specified 1000 policy rules, it takes approximately 6 s to process a user’s request to access the information resources, in which our access controller takes almost 1 s to re-evaluate the whole process when any context changes (see Fig. 10). We consider that the performance is acceptable in such a setup with limited computing resources. It can be improved by using more powerful machines. Overall, we can say that our framework has acceptable response time in supporting users’ access to information resources in a context-aware manner. 6.5. Usability This section demonstrates the usability testing of our CAAC policy framework in the laboratory setup and with real users. We first explain the steps for achieving the context-aware access control requirements in the experiment setup. Then, we analyse the access control requests for different users and the responses as well with respect to different types of contextual conditions. 6.5.1. Desktop-based implementation The experiment setup consists of client-side (e.g. development of application interface) and middleware (e.g. development of rule base) layers. We have developed our prototype in Java 2 Platform Standard Edition (J2SE) [31] along with the widely supported open source tools. Given that our CAAC proposal mainly relies on the context-aware user-role and role-permission assignments based on the relevant contextual conditions, semantic ontology languages such as OWL and SWRL are found to be the suitable technologies to demonstrate a working prototype in this experiment setup. An overview of the tools and technologies that are used to implement the software components of the prototype is described in the following steps. Development of ontologies: Underlying the tool support at the back-end, context information representation and reasoning need to be carried out using some formalism. We have used Protégé-OWL graphical editor [27] to develop the context and policy ontologies, used SWRL rule language [25] to codify the reasoning rules and used Jess Rule Engine [28] to facilitate reasoning tasks for executing the reasoning rules. In the previous sections, we have already presented the core context and policy ontologies, in order to represent the context information and context-aware access control policies. Figure 11 shows a snapshot of the context ontology development, where the concepts and the relationships among concepts are described. The tree on the left shows the class hierarchy diagram, including the ContextEntity and the ContextInfo hierarchies. The access control related general context entities and context information representing these entities are defined in the ContextEntity and ContextInfo hierarchies, respectively. Using these general concepts, we have developed the domain-specific concepts. For example, Fig. 12 shows a snapshot of the domain-specific role ontology. The tree on the left shows the role hierarchy, including the InDomainUser and the OutDomainUser hierarchies. The InDomainUser roles are modeled, relying on the Australian Standard Classification of Occupations (ASCO) of the Health Professionals [20]. For example, the NursingProfessional, MedicalPractitioner and OtherProfessional roles are the subclasses of InDomainUser. Similar to the role ontology development, we have used the Protégé-OWL to implement the other domain-specific ontologies. For example, we formulate the stricture of the resource ontology, following the health level seven standard [32]. Figure 11. View largeDownload slide A part of the context ontology. Figure 11. View largeDownload slide A part of the context ontology. Development of Rule Base: To derive high-level implicit information from the available information at runtime, we have used the SWRL rule language [25] and integrated the SWRLTab plug-in [33] to the Protégé-OWL. The SWRL rules directly use OWL knowledge from the ontology. The SWRLTab editor in Protégé-OWL checks syntax and provides built-in functions for mathematical computations (e.g. add, subtract, power), comparisons (e.g. equal, not equal, greater than, less than), and so on [26]. Development of Context Providers: We have implemented a number of context providers in Java which receive raw data from the data sources (sensors) and generates the context information (contextual conditions). For example, a context provider (LocationSensor java class) receives raw data (locationCoordinates: latitude and longitude) from the Google Map API and generates the context information (locationAddresses) based on our ontology concepts and the associated information about the location from the database. Similarly, another context provider (TimeSensor java class) receives raw context data (the systemTime is “12:33:17”) and generates the context information (the requestTime is “DutyTime”) based on our policy ontology concepts. Development of Context Reasoner: In order to execute SWRL rules, we have implemented the context reasoner (i.e. inference engine). It uses the SWRL rules and OWL instances and infers the implicit information. We have used both the Jess Rule Engine [28] and Java to implement the context reasoner. We have selected the Jess rule engine because of its rule management capability. Figure 13 shows two Java functions. The first function executes the SWRL reasoning rules using Jess rule engine and consequently derives the implicit context information from the basic information through the context ontology. The second function transfers derived information to the context ontology. Figure 13. View largeDownload slide A part of the implementation of our inference engine: a Java code snapshot in eclipse. Figure 13. View largeDownload slide A part of the implementation of our inference engine: a Java code snapshot in eclipse. Development of Access Control Manager: As a part of the access control manager, we have implemented the CAAC policy enforcement point (PEP) and policy decision point (PDP) in Java. The CAAC PEP receives the access requests from users. The CAAC PDP determines whether the access request is “Granted” or “Denied” according to the applicable context-aware access control policies and the necessary contextual conditions. In order to check who can access what resources at runtime, we have used the SQWRL [30] query language. Specifically, in order to codify the access queries, we have integrated the SQWRLQueryTab plug-in [34] to the Protégé-OWL. Figure 14 shows a Java function, which executes an access query and checks the CAAC decision. Figure 14. View largeDownload slide A Java code snapshot in eclipse for context-aware access control decision. Figure 14. View largeDownload slide A Java code snapshot in eclipse for context-aware access control decision. Development of Application Interface: We have used Web technologies to build an application interface for our prototype which is used by users (resource requesters) under different contexts (e.g. from different locations). Users normally communicate by sending requests and getting responses through this interface. We have used Java to realize the communication among various functional components of our prototype. 6.5.2. Mobile-based implementation In this section, we demonstrate the functionality of our CAAC framework using mobile-based setup. In particular, we evaluate our proposed CAAC framework using several case scenarios from the healthcare domain. We first explain the implementation of the mobile-based prototype and then, we analyse the access control requests for different users with respect to different contextual conditions (e.g. location addresses, request times and interpersonal relationships). The experiment setup consists of server-side (e.g. relational database using SQLite) and client-side (e.g. login interface) layers. We have already described our desktop-based implementation in the previous section. In this mobile-based setup, we have used our same policy ontology to enforce the relevant CAAC policies, including the context ontology to derive the relevant contextual conditions. Figure 15 illustrates the development environment of our prototype, which has mainly the database, middleware (i.e. our CAAC) and user interface parts. We actually limit the users’ access to data (i.e. patients’ health records) according to their roles and the associated contextual conditions, especially based on the relevant CAAC policies. We have implemented our prototype in Android Studio IDE along with relevant widely supported open source tools. We have used XML technologies to build the mobile interfaces for this prototype. In particular, we have developed a mobile-based CAAC application for healthcare, named mHealthcare. The access control requests from different users have been originated through this login interface and the users have been received the relevant responses via different interfaces. Figure 15. View largeDownload slide Development environment for our mobile prototype. Figure 15. View largeDownload slide Development environment for our mobile prototype. Figure 16 presents an screenshot from our healthcare application using mobile-based prototype. It shows the access control decision for a doctor’s request. In this scenario, Jim, who is a doctor, can see different patients’ list who are admitted into the hospital and can access a patient James’ health records by satisfying the following contextual conditions: when Jim is located in the hospital, James is admitted under the treatment of Jim and Jim’s access request is originated during his medical duty time. On the other hand, Fig. 17 shows another scenario in which Amanda, who is a nurse and assigned to take care of a patient James, only can access certain medical records of James. In particular, Amanda has limited access to James’ health information during her ward shift time and when they both are co-located in the ward of the hospital. She has no access to a patient’s previous medical history. Figure 16. View largeDownload slide Jim’s (who is a Doctor) request to access James’ health records. Figure 16. View largeDownload slide Jim’s (who is a Doctor) request to access James’ health records. Figure 17. View largeDownload slide Amanda’s (who is a Nurse) request to access James’ health records. Figure 17. View largeDownload slide Amanda’s (who is a Nurse) request to access James’ health records. 6.5.3. Analysis Table 27 shows the contextual conditions that are used in our research prototypes. The different types of conditions are involved in this list. Our CAAC access controller exploits such conditions when making access control decision. For example, the location addresses of the users and patients can be obtained directly from the context sources through our implemented context providers, whereas the interpersonal relationships between the users and patients cannot be obtained directly but can be derived from the necessary low-level information. Figure 18 shows an example reasoning rule, which is codified in Java. This rule uses the required context information about user’s personal profile and patient’s social profile using our context model, and derives the interpersonal relationship between user and resource owner through our implemented context reasoner. For the application scenario presented in Section 2, based on our context ontology, this rule can determine that Jane and Bob has a “nonTreatingPhysician” relationship, because Jane is not assigned as a treating physician of patient Bob. Figure 18. View largeDownload slide An example reasoning rule in Java. Figure 18. View largeDownload slide An example reasoning rule in Java. Table 27. Contextual conditions. Contextual condition Description interRelationship The interpersonal relationship between health professional and patient locationCentric-Relationship The co-located relationship between persons healthStatus The health status of a patient locationAddress The location of a person requestTime The request time of a user Contextual condition Description interRelationship The interpersonal relationship between health professional and patient locationCentric-Relationship The co-located relationship between persons healthStatus The health status of a patient locationAddress The location of a person requestTime The request time of a user View Large Table 27. Contextual conditions. Contextual condition Description interRelationship The interpersonal relationship between health professional and patient locationCentric-Relationship The co-located relationship between persons healthStatus The health status of a patient locationAddress The location of a person requestTime The request time of a user Contextual condition Description interRelationship The interpersonal relationship between health professional and patient locationCentric-Relationship The co-located relationship between persons healthStatus The health status of a patient locationAddress The location of a person requestTime The request time of a user View Large We have considered several locations (e.g. general ward, emergency room) in our prototype and used the relational database to store the location coordinates. For any location, we have used the boundary coordinates (e.g. geographic boundaries of general ward) and stored them into the database. In particular, we have simulated such location addresses in our laboratory setup (e.g. University campus area as hospital, BG building as general ward and so on). We first evaluate our prototype in response to the access requests from users with several Windows machines in different locations through our implemented desktop-based interface. With two general practitioners (⁠ GPs ⁠) and two registered nurses (⁠ RNs ⁠) involved in this study, two users GP1 and RN1 (e.g. Jane and Mary) are provided with two Windows computers and asked to send their requests to access the different types of medical records of a patient (e.g. Bob) from different locations. The other two users GP2 and RN2 (e.g. same Jane and Mary) are provided with a Windows computer and asked to send their requests to access Bob’s medical records when they all are in the same location. In particular, they are asked to read or write the medical records under different contexts. We have recorded the access decisions accordingly. In this study, we have also asked users to send their feedbacks (i.e. complaints) if they are not satisfied with the access decisions (i.e. responses). We have analyzed users’ complaints in relation to their access requests, and noted that some “Denied” decisions may need to change to “Granted” in the right contextual conditions and also need to specify the new access control policies or refine the existing policies accordingly. We have collected 50 access control attempts from GP1 and RN1 ⁠, and 50 attempts from GP2 and RN2 (see Table 28). Actually, these are the repeated requests on the different set of contextual conditions (e.g. access requests from the same or different locations). We have also recorded the complaints from them (as shown in Table 28) when they are not satisfied with the decisions. In total, out of the 100 access requests for this study, GP1 and RN1 have received 40 “Denied” responses, whereas GP2 and RN2 have received 15 “Denied” responses. In terms of “Denied” decisions, GP1 and RN1 have complained 25 times, whereas GP2 and RN2 have complained 8 times. Table 28. Requests, responses and complaints. User Role Request Granted Denied Complaint Jane GP1 25 10 15 10 Mary RN1 25 0 25 15 Jane GP2 25 20 5 3 Mary RN2 25 15 10 5 User Role Request Granted Denied Complaint Jane GP1 25 10 15 10 Mary RN1 25 0 25 15 Jane GP2 25 20 5 3 Mary RN2 25 15 10 5 View Large Table 28. Requests, responses and complaints. User Role Request Granted Denied Complaint Jane GP1 25 10 15 10 Mary RN1 25 0 25 15 Jane GP2 25 20 5 3 Mary RN2 25 15 10 5 User Role Request Granted Denied Complaint Jane GP1 25 10 15 10 Mary RN1 25 0 25 15 Jane GP2 25 20 5 3 Mary RN2 25 15 10 5 View Large We have evaluated such issues when the users have complained that they should have had access. In particular, we have played the role of a security/policy administrator to follow up their complaints with respect to relevant policies and the contextual conditions that are stored into the ontology. We have realized that some of the complaints are valid as our ontology does not have applicable policies. In such cases, we have specified the relevant CAAC policies. We have also realized that some of the complaints are not valid when the contextual values have changed. In such cases, we have sent “access is stopped” response to the users when the contextual values are not identical to policy constraints. We need further study to investigate how this complaint resolution process can be handled at runtime, including an automated security administrator to dynamically evaluate users’ complaints and consequently model or update the relevant CAAC policies and the ontology. These variations of “Denied” responses and users’ complaints are confirmed that the first set of access requests are originated from different locations where Bob is not located. Actually, Mary only can access Bob’s medical records if Bob or Jane is co-located with her and also under satisfying other relevant contextual conditions. In particular, Table 29 shows the context-aware access control (CAAC) decisions in terms of Mary and Jane’s requests to access different medical records of patient Bob. We can observe that Mary (with RN1 role) has “Denied” access to daily medical records (DMR) of patient Bob when they are not co-located, whereas Jane has “Granted” access to emergency medical records (EMR) of patient Bob from different locations to save his life. Table 29. CAAC decisions (desktop prototype). User Role Resource Operation Decision Mary RN1 DMR Read Denied Jane GP1 EMR Write Granted User Role Resource Operation Decision Mary RN1 DMR Read Denied Jane GP1 EMR Write Granted View Large Table 29. CAAC decisions (desktop prototype). User Role Resource Operation Decision Mary RN1 DMR Read Denied Jane GP1 EMR Write Granted User Role Resource Operation Decision Mary RN1 DMR Read Denied Jane GP1 EMR Write Granted View Large We also evaluate our proposed CAAC framework in response to different requests from users through our implemented mobile prototype. The same nurses and doctors are also involved in this study. They are asked to send their requests to access different medical records of patients from different locations (e.g. from the inside or outside of Latrobe University campus). We have analysed their access requests with respect to different contextual conditions, such as their location addresses, duty times and relationships with patients. In particular, we have evaluated the context-sensitive access control decisions when there are dynamic changes to the context. In the previous section (see Figs 16 and 17), we have already demonstrated two mobile-based case scenarios for the doctor and nurse. In order to access the patients’ medical records, Table 30 shows the CAAC decisions in terms of Jim and Amanda’s requests along with the relevant contextual conditions. In particular, we can observe that Amanda, who is a nurse, has “Denied” access to James’ health records (HR) outside of her duty times (see Record #1 in Table 30). The scenario is also shown in the left side of Fig. 17, which shows Amanda is not allowed to access James’ health records outside of her ward shift time. She can access James’ health records (HR) by satisfying all three contextual conditions (see Record #2 in Table 30), however, she is not allowed to access James’ previous medical history (PMH) by satisfying all these contextual conditions (see Record #3 in Table 30). On the other hand, Jim, who is a doctor, can access James’ HR and PMH as he is a treating doctor for the patient James and when his access request originates from the inside of the hospital during his duty time (see Record #5 in Table 30). Table 30. CAAC decisions (mobile prototype). User (role) Resource (decision) Location Time Relationship Amanda (nurse) HR (denied) Hospital Non-duty time Assigned nurse Amanda (nurse) HR (granted) Hospital Duty time Assigned nurse Amanda (nurse) PMH (denied) Hospital Duty time Assigned nurse Amanda (nurse) HR (denied) Outside hospital Duty time Assigned Nurse Jim (doctor) HR + PMH (granted) Hospital Duty time Treating doctor Jim (doctor) PMH (denied) Hospital Duty time Non-treating doctor User (role) Resource (decision) Location Time Relationship Amanda (nurse) HR (denied) Hospital Non-duty time Assigned nurse Amanda (nurse) HR (granted) Hospital Duty time Assigned nurse Amanda (nurse) PMH (denied) Hospital Duty time Assigned nurse Amanda (nurse) HR (denied) Outside hospital Duty time Assigned Nurse Jim (doctor) HR + PMH (granted) Hospital Duty time Treating doctor Jim (doctor) PMH (denied) Hospital Duty time Non-treating doctor View Large Table 30. CAAC decisions (mobile prototype). User (role) Resource (decision) Location Time Relationship Amanda (nurse) HR (denied) Hospital Non-duty time Assigned nurse Amanda (nurse) HR (granted) Hospital Duty time Assigned nurse Amanda (nurse) PMH (denied) Hospital Duty time Assigned nurse Amanda (nurse) HR (denied) Outside hospital Duty time Assigned Nurse Jim (doctor) HR + PMH (granted) Hospital Duty time Treating doctor Jim (doctor) PMH (denied) Hospital Duty time Non-treating doctor User (role) Resource (decision) Location Time Relationship Amanda (nurse) HR (denied) Hospital Non-duty time Assigned nurse Amanda (nurse) HR (granted) Hospital Duty time Assigned nurse Amanda (nurse) PMH (denied) Hospital Duty time Assigned nurse Amanda (nurse) HR (denied) Outside hospital Duty time Assigned Nurse Jim (doctor) HR + PMH (granted) Hospital Duty time Treating doctor Jim (doctor) PMH (denied) Hospital Duty time Non-treating doctor View Large We have tested our proposed CAAC framework on both the desktop and mobile-based settings with regards to different types of contextual conditions. The contextual conditions such as locations, request times and relationships are used in our experiments, i.e. in this laboratory setup. For example, we have asked our participants to send their requests to access different medical records of patients from different locations (e.g. Latrobe University campus) at different times. We have evaluated the CAAC framework in our testbed for a duration of two weeks, by involving participants from our research students and faculty members. We have selected such persons who have knowledge of the access control systems. In future, we will conduct a usability study of our proposed CAAC framework with participants from different backgrounds in relation to our both prototypes and obtain users’ feedback that may result in concrete suggestions for context-sensitive access control decisions. In summary, while our prototype is tested on many attempts from different users with respect to different contextual conditions, the implementation as a whole provides an efficient infrastructure support for building CAAC applications in today’s dynamic environments. 6.6. Lesson learnt This section summarizes our experience to build new CAAC applications in today’s dynamic world. The following are several issues and technical challenges that are found in this real setup: (L1) Difficulties to model domain-specific roles and resources: We have used the classification of ASCO health professionals [20] and the HL7 standard [32] to model the required roles (healthcare users) and resources (patients’ health related information and medical records). In a real setup like healthcare environment, this is really a big challenge to model the domain-specific roles and information resources. (L2) Obtaining real context information is a challenging task: The acquisition of real context information is always a challenging job. In our real setup, we have used Google map API to capture real location coordinates and identify the location addresses with finer-granularities from them. Actually, we have mapped all hospital coordinates (i.e. latitudes and longitudes) from Google API and stored into relational database. In this aspect, the authenticity of the location coordinates generated from the API is another key issue to be explored in the future explore (i.e. the trustworthiness of the sensor data). (L3) Need a security administrator to follow-up users’ complaints: During the usability study, users are asked to send their complaint files. However, there is a need to identify where they encounter problems and experience confusions for future auditing purposes. Also, our research prototype requires a security administrator in the loop to specify new CAAC policies or refine existing policies based on the users’ complaints along with the associated contextual conditions. This may be done dynamically at runtime. Towards this goal, we may need an automated security administrator (i.e. a software component) to dynamically analyse such complaint files in relation to users’ access requests and consequently specify the new policies or refine the existing policies. (L4) What happens when contextual conditions change: In general, at each time of an access request comes from a user or when context changes, the CAAC PEP sends a request to the CAAC PDP for the applicable policies and the relevant context information. Based on the applicable policies and the relevant contextual conditions, once a user’s access decision is granted, then the requested resource is sent to the user. In our current setup, when any context changes while the access is being performed by a user, the CAAC PDP normally evaluates the access request by collecting the current contextual values from the sensors and checks the applicable policies against the contextual conditions. Consequently, the CAAC PEP sends the “access is stopped” response to the user if any of the current contextual value is not identical to policy constraints. (L5) How other relevant technologies can be used to build the CAAC applications: In our current implementation, we have used the semantic ontology languages OWL [24] and SWRL [25] for representing and reasoning about the different types of contextual conditions. We have used the OWL ontology to capture the low-level simple context information. Also, we have used the SWRL language, SWRL Built-Ins [26] and Jess rule engine [28] together to derive the implicit context information from the low-level information. Towards this end, we have used the user-defined reasoning rules to derive the implicit information (e.g. see the reasoning rules in Section 4.4). We have also used SQL relational database to store necessary information. On the other hand, other relevant technologies have been used by different research communities. For example, the Oracle VPD security model [35] has successfully been used by the database research community to create security policies and control relational database access, preventing the users from accessing data and information that are not relevant to them. It provides security policies on database objects such as the policies to a relational table. It is possible to implement the fine-grained access control systems, by incorporating the contextual conditions into Oracle VPD model and taking into account the context of location, time, user’s role as dynamic conditions [36]. However, first, the Oracle VPD security model is not adequate to support the reasoning capability to derive the high-level implicit context information from the low-level information. For example, the VPD model is not sufficient to derive the relationship between parent instances, i.e. the children whose parents are married. This reasoning capability normally improves the access control to information resources at different granularity levels by using the implicit contextual conditions [19]. Second, it is possible to incorporate the context of users’ roles into VPD security policies as pre-conditions. However, the VPD security model does not support RBAC’s senior–junior role and role inheritance concepts, which simplify the specification of access control policies for a large number of roles. In essence, we can use our context representation and reasoning approach and the Oracle VPD security model together for capturing and reasoning about the simple and implicit contextual conditions, and consequently we can incorporate such conditions into the RBAC policies for context-specific decision making at different granularity levels. 7. RELATED WORK AND COMPARATIVE ANALYSIS In this section, we review the existing literature on role-based access control approaches in the context of the dynamically changing information (e.g. the location of the requesters) [2, 3]. Traditional role-based access control approaches [4, 5] exploit user identity/role information to determine the set of access permissions, whereas the dynamic context information can further limit the applicability of the available permissions. Our review includes the context-dependent role-based access control approaches that incorporate different types of context information into the traditional role-based access control (RBAC) process. We distinguish five different categories of access control approaches: Temporal role-based access control. Spatial role-based access control. Spatio-temporal role-based access control. Context-aware role-based access control. Other access control. 7.1. Temporal role-based access control approaches The temporal role-based access control approaches [10, 11] extend the basic role-based access control (RBAC) approaches [4, 5] by taking into account the temporal information (e.g. request times of users). Bertino et al. [10] have proposed the temporal RBAC (TRBAC) approach, which extends the traditional RBAC approach to support temporal constraints on enabling roles. To describe temporal constraints, TRBAC introduces a concept named role enabling base (REB), which is composed of periodic events and role triggers. For example, the periodic events and role triggers in the REB state that the doctor-on-night-duty role should be enabled during the night, whereas the role doctor-on-day-duty should be enabled during the day. TRBAC considers the temporal-aware user-role assignments, however, this approach does not provide adequate functionalities to integrate context information for role-permission assignments. On the other hand, Joshi et al. [11] have extended the TRBAC approach proposed in [10]. They proposed a generalized temporal role-based access control (GTRBAC) model that allows specification of a comprehensive set of time-based access control policies, incorporating the temporal constraints in both user-role and role-permission assignments. These approaches take into account the temporal information when enforcing access control policies. However, they do not provide ontology-based implementation to realize the formal approaches, what we have in our policy framework. In our application scenario (presented in Section 2), Mary should not assign to nurse role and consequently a nurse should not have access to medical records of the patients other than satisfying some contextual conditions (during ward duty time, from the hospital location, relationship between them are assigned nurse, etc.). Other than the temporal information, we also consider other relevant context information for user-role and role-permission assignments. 7.2. Spatial role-based access control approaches The spatial role-based access control approaches [12, 37] extend the basic role-based access control (RBAC) approaches [4, 5] by taking into account the spatial information (e.g. locations of users). The GEO-RBAC [12] approach proposes the spatial extent (i.e. geographical location) of role, extending the traditional RBAC approach with the concept of spatial role. A spatial role represents a geographically bounded organizational function. The boundary specifies the spatial extent in which the user is located and enabled to play such a role. The GEO-RBAC approach provides spatial-aware user-role assignment and allows access to resources based on the spatial role the user holds within the spatial boundary. Zhang et al. [37] have proposed a location-aware RBAC approach, named LRBAC. Like GEO-RBAC, LRBAC introduces the concept of spatial role. The roles are automatically activated/deactivated by the locations of the users. In LRBAC, both the activated roles of the users and their locations are taken into account for role-permission assignments, in order to evaluate the access control policies. These approaches take into account the spatial information when enforcing RBAC policies. Similar to above-mentioned temporal RBAC approaches, however, they do not consider other relevant context information for user-role and role-permission assignments. Compared with these location-aware approaches, we have presented an ontology-based policy model in order to provide the practical basis for realizing the formal model. 7.3. Spatio-temporal role-based access control approaches The spatio-temporal role-based access control approaches [13, 38] extend the basic role-based access control (RBAC) approaches [4, 5] by taking into account both the spatial and temporal information. Chandran and Joshi [13] have extended the GTRBAC approach proposed in [11]. They have proposed a location and time-based RBAC approach, named LoT-RBAC [13]. It considers temporal and spatial context information as contextual conditions. It adopts and extends the concept of role activation from the GTRBAC approach, by incorporating the temporal and spatial context information. In particular, a role is activated by a user from the location l at time t. LoT-RBAC allows access to resources if the location and temporal information of a user associated with the role activation is satisfied. Bhatti et al. [38] have proposed a spatio-temporal access control approach, named X-GTRBAC. It adopts the temporal-aware user-role and role-permission assignment policies from the GTRBAC approach, and incorporates spatial context information in these assignments. These access control approaches consider the spatial and temporal information when enforcing RBAC policies. They have similar drawbacks in considering only the specific types (temporal and spatial) of context information for user-role and role-permission assignments. Also, they lack in providing a practical approach to incorporate the relevant context information into RBAC process. 7.4. Context-aware role-based access control approaches Over the last few years, there are several research works extend the basic role-based access control (RBAC) approaches [4, 5], where authorizations to access resources are based on the user assigned role and the relevant context information. Kulkarni and Tripathi [15] have proposed a context-aware role-based access control (CA-RBAC) model for pervasive computing applications. Using this model, they also present a programming framework for building context-aware access control applications. They consider user and resource-centric attributes as the context conditions in role-permission assignments. A user having a role and by fulfilling those conditions can access the resources. In contrast to the CA-RBAC model, the mapping of users to roles in our model is dynamically performed in accordance with the relevant context information. Different from this model, we also present a formal model to specify two sets of context-aware access control policies. In addition, our model includes a language to express contextual conditions based on the simple and complex context information. Wang et al. [39] have proposed a context-aware environment-role-based access control (CERBAC) approach for web services. They consider subject roles and environment roles as the access conditions. The policy rules are executed at runtime to grant or deny access based on both the subject roles and the environment roles. As such, access control decisions in CERBAC not only depend on the subject roles but also on environment roles. In CERBAC, the environment conditions are specified and modeled by the context information and they are used to define the environment roles. The unification of all relevant states (subject and environment states) into a single concept (roles) makes access control policies significantly easier to define and implement. However, the approach is not suitable for context-aware environments, because of the many roles (especially, contextual or environment roles) making the system very hard to maintain. In addition, it does not consider the context-aware user-role assignments. A dynamic role-based access control (DRBAC) approach that incorporates the required credentials of users as context information when making user-role and role-permission assignments [40]. DRBAC only presents the concepts and requirements of the dynamic access control, without providing context and policy modelling supports. Compared with this work, we have presented both the formal and ontology-based policy models for our context-aware access control framework with an implementation (software) architecture and prototype. He et al. [14] have considered access control for web service based on the user role and presented a policy model. This model is limited to considering specific types of contexts as policy constraints. Similar to the above approaches, this model has limitation in considering dynamic user-role and role-permission assignments in accordance with basic RBAC process. Schefer-Wenzl and Strembeck [16] have proposed an approach to context-aware role-based access control in ubiquitous environments. They propose a formal meta model that extends the UML, to integrate context attributes into the basic RBAC process. In this approach, the context attributes represent a certain properties of the environment such as time and location. It allows access to resources if this environment context information of a user associated with the role-permission assignments are satisfied. However, this context-aware role-based access control approach does not provide adequate functionalities to specify context-aware user-role assignments. In addition, the approach has limitation in providing a formal policy model to specify the two sets of context-aware (user-role and role-permission) access control policies. Kayes et al. [19, 21] have proposed an ontology-based approach to context-aware access control for information resources. They propose a context model for capturing and reasoning about access control-specific dynamic contexts, and a policy model for specifying and enforcing context-aware access control (CAAC) policies. This policy model extends the basic RBAC model, including the dynamic assignments of permissions to users based on the relevant contexts. However, this approach does not consider the context-aware user-role assignments. Also, it lacks in providing a formal policy model to specify and incorporate the relevant context information into both the user-role and role-permission assignments. Different from this approach, our policy framework also includes a simple language named context specification language for expressing contextual conditions based on the simple and complex context information. Another recent ontological framework for situation-aware access control of software services has been proposed by Kayes et al. [41, 42]. The framework includes a situation model for identifying the relevant purpose-oriented situations and a policy model for specifying and enforcing situation-aware access control policies. The access control policies are specified in accordance with the possible situations. This policy model extends the concept of common role-permission assignment in RBAC, incorporating the concept of purpose-oriented situation. However, the framework does not provide adequate concepts to model both the context-aware user-role and role-permission assignment policies. Also, it lacks in providing a language to specify the different types of context expressions based on the simple and complex contexts. Recently, Hosseinzadeh et al. [17] and Trnka and Cerný [18] have proposed the context-aware role-based access control models. In [17], roles are assigned to the users by the administrators and at runtime, users can access the resources based on the roles and the context information. The context of location and time are taken into account in deciding the restrictions. For example, in the healthcare domain, a doctor is restricted to read the medical history of the patients after office time or outside the hospital. In [18], the access control decisions are based on the context information (e.g. the range of IP addresses and times of the day) in addition to traditional roles in RBAC. In these models, instead of considering two sets of context-aware user-role and role-permission assignment policies, they consider the static user-role assignment policies created by the administrator and the role-permission assignment policies in accordance with the context information. They also lack in providing a formal context-aware access control policy model. Bonatti et al. [43, 44] have introduced an event-driven extension of the temporal RBAC model [10], named ERBAC. They provide an implementation of role-based access control in which access control is managed by means of context information (location, time, an event such as “surgery in progress”). They also include a comparative analysis of the existing literature on context-aware access control approaches based on some interesting features (such as approaches that do not include any formal semantics of the policy models, system-oriented or programming-framework oriented approaches) in [44]. In ERBAC [43, 44], roles are defined by considering the context information in order to support the dynamic role activation and revocation. However, an access controller still needs to check the relevant contextual conditions that a user can satisfy to activate and play such a dynamic context-specific role. To this respect, in our CAAC policy framework, we introduce the context-aware user-role associations based on the relevant contextual conditions. Our framework also introduces the context-aware role-permission assignment policies, incorporating some further (relevant) contextual conditions into the role-permission associations. Thus, the main contributions of our paper are the formal definition of contextual conditions, context-aware user-role and role-permission associations, implementation and evaluation against a case study in a real setup. 7.5. Other access control approaches Ni et al. [45] have introduced a privacy-aware role-based access control (P-RBAC) framework in order to enforce access control to data. They formally define the notion of privacy-aware permission assignments in which the relevant pre-conditions (e.g. data owner’s consent, parent’s consent for kids) are introduced. The framework also supports the high-level specification of P-RBAC privacy policies to control (privacy-sensitive) personally identifiable information. However, the P-RBAC model is not context-aware, thus making it difficult to handle situations requiring the dynamic user-role and role-permission assignments based on the relevant context information which has dynamically changing nature. XACML (eXtensible Access Control Markup Language) is an XML-based general purpose access control policy language [46]. The specification and enforcement of XACML policies are based on the attributes of subjects, objects and environments. Similar to spatio-temporal RBAC approaches [13, 38], the environment conditions such as location and time can be incorporated into the XACML policies as the pre-conditions [47, 48]. The RBAC role concept [5] has been used in the specification of XACML policies. However, in XACML, roles are expressed as attributes to subjects. As such, it does not support the concepts of RBAC’s senior–junior role and role inheritance. Its setup is also similar to P-RBAC model as it does not provide the context-awareness capability. Even though P-RBAC and XACML approaches introduce the management of access control policies by specifying user-role and role-permission assignments, these approaches do not provide adequate functionality to incorporate and adapt to the dynamic contextual conditions. For example, a hospital nurse can only access the medical records of a patient while on duty and only when she is present in the general ward of the hospital where the patient is located. However, she should not access such health records of a patient when she leaves the location where the patient is located (e.g. while she is on the bus heading home). In the literature, the Oracle Virtual Private Database (VPD) security model [35] has also been used for enforcing context-aware access control policies (e.g. [49, 50]). Colombo and Ferrari [49, 50] have introduced a context-aware access control approach by using the dynamic conditions of Oracle VPD and integrated the relevant context information into the relational tables to control database resources. However, the proposed access control approach is not adequate to support all the general requirements and technical challenges of developing context-aware access control applications that are identified in Section 2. The main design considerations in our CAAC framework include three aspects: (i) users are authorized to play the roles by satisfying the relevant contextual conditions, (ii) permissions (resource access permissions) are dynamically assigned to roles based on the relevant contextual conditions and (iii) users can access resources by having corresponding roles. In order to support context-aware RBAC using Oracle VPD, we can consider the role as the context information about user (i.e. an attribute of user). However, Oracle VPD is not adequate to support RBAC’s senior–junior roles, what we model as role hierarchies (i.e. role ontology) in our CAAC policy framework. This feature normally simplifies the administration of role-based access control policies in large-scale authorization management [8], as the senior–junior role concept provides significantly simple and easier to define and model a large number of roles. For example, in RBAC and our CAAC framework, a user is assigned to a senior role means she is also authorized to play all the junior roles of that senior role. It is only required to specify the policies for assigning users to senior roles, not necessary to specify policies for assignment of users to other junior roles. Similarly, we only need to specify the policies for assigning permissions to senior roles. Our framework also supports to obtain the relevant context information from raw data and to derive the high-level context information from the available context information. As ontologies are suitable for modelling dynamic (context) information for pervasive context-aware applications because of its considered trade-off between computational complexity of reasoning and expressiveness [23], we use the OWL [24] ontology language and SWRL [25] rule language to capture and derive the relevant context information. The reasoning capability is another important feature in our policy framework, which derives the high-level implicit contextual conditions. It improves the control over access to relevant resources through automated inference of implicit contextual conditions from the low-level contextual conditions. For example, we use a reasoning rule (specified in Table 14) to derive the high-level implicit information about the interpersonal relationship between a resource requester and a resource owner, and use the Jess rule engine [28] to fire and execute such reasoning rules. Similarly, the information about whether the doctors, nurses and patients are co-located in the same place or not is derived by using the reasoning rules. Further details of context information modelling can be found in our earlier work [19]. Using Oracle VPD, the low-level information such as context of location and time can be taken into account as dynamic conditions, whereas, it is not adequate to support such reasoning capability to infer implicit context information from low-level information. 7.6. Comparative analysis and discussion This section presents the comparative analysis of the existing context-dependent RBAC approaches. The comparison is carried out in two groups: (i) Context-aware RBAC approaches and (ii) our earlier context/situation-aware RBAC approaches, with respect to the policy framework presented in this paper. Our analysis focuses primarily on the following key features/aspects of our policy framework. We provide (i) a formal policy model to represent how to mapping between user and role and mapping between role and permission in accordance with the relevant contextual conditions (CAURA and CARPA policy models). To this end, we introduce a context specification language (CSL) to specify the contextual conditions using the relevant simple and complex context information. We also introduce (ii) an ontology-based policy model (CAURA and CARPA ontologies) and a software prototype to realize the formal model. We demonstrate (iii) the evaluation of the framework by considering the completeness, correctness, consistency, performance and usability of our CAAC policy ontology concepts. Tables 31 and 32 show all the analysis results in which we use “YES” when a feature is available/implemented in the approach, “P/A” when a feature is partially available in the approach and “N/A” when a feature is not available in the approach. Table 31. Comparative analysis of the context-aware RBAC approaches. RBAC frameworks Formal model Implementation model Evaluation CAURA policy CARPA policy CSL CAURA ontology CARPA ontology Software prototype Completeness Correctness Consistency Performance Usability CA-RBAC [15] N/A P/A N/A N/A N/A N/A N/A N/A N/A N/A N/A CERBAC [39] N/A P/A N/A N/A N/A N/A N/A N/A N/A N/A N/A DRBAC [40] N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A Access Control for Web Service [14] N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A Context-Aware RBAC [16] N/A P/A N/A N/A N/A N/A N/A N/A N/A N/A N/A Context-Aware RBAC [17] N/A P/A N/A N/A N/A N/A N/A N/A N/A N/A N/A Context-Aware RBAC [18] N/A P/A N/A N/A N/A N/A N/A N/A N/A N/A N/A Event-Driven RBAC [43, 44] P/A N/A YES N/A N/A YES YES YES YES YES N/A Access Control with VPD [49, 50] N/A P/A P/A N/A N/A YES P/A N/A N/A YES N/A Our CAAC Policy Framework YES YES YES YES YES YES YES YES YES YES YES RBAC frameworks Formal model Implementation model Evaluation CAURA policy CARPA policy CSL CAURA ontology CARPA ontology Software prototype Completeness Correctness Consistency Performance Usability CA-RBAC [15] N/A P/A N/A N/A N/A N/A N/A N/A N/A N/A N/A CERBAC [39] N/A P/A N/A N/A N/A N/A N/A N/A N/A N/A N/A DRBAC [40] N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A Access Control for Web Service [14] N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A Context-Aware RBAC [16] N/A P/A N/A N/A N/A N/A N/A N/A N/A N/A N/A Context-Aware RBAC [17] N/A P/A N/A N/A N/A N/A N/A N/A N/A N/A N/A Context-Aware RBAC [18] N/A P/A N/A N/A N/A N/A N/A N/A N/A N/A N/A Event-Driven RBAC [43, 44] P/A N/A YES N/A N/A YES YES YES YES YES N/A Access Control with VPD [49, 50] N/A P/A P/A N/A N/A YES P/A N/A N/A YES N/A Our CAAC Policy Framework YES YES YES YES YES YES YES YES YES YES YES View Large Table 31. Comparative analysis of the context-aware RBAC approaches. RBAC frameworks Formal model Implementation model Evaluation CAURA policy CARPA policy CSL CAURA ontology CARPA ontology Software prototype Completeness Correctness Consistency Performance Usability CA-RBAC [15] N/A P/A N/A N/A N/A N/A N/A N/A N/A N/A N/A CERBAC [39] N/A P/A N/A N/A N/A N/A N/A N/A N/A N/A N/A DRBAC [40] N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A Access Control for Web Service [14] N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A Context-Aware RBAC [16] N/A P/A N/A N/A N/A N/A N/A N/A N/A N/A N/A Context-Aware RBAC [17] N/A P/A N/A N/A N/A N/A N/A N/A N/A N/A N/A Context-Aware RBAC [18] N/A P/A N/A N/A N/A N/A N/A N/A N/A N/A N/A Event-Driven RBAC [43, 44] P/A N/A YES N/A N/A YES YES YES YES YES N/A Access Control with VPD [49, 50] N/A P/A P/A N/A N/A YES P/A N/A N/A YES N/A Our CAAC Policy Framework YES YES YES YES YES YES YES YES YES YES YES RBAC frameworks Formal model Implementation model Evaluation CAURA policy CARPA policy CSL CAURA ontology CARPA ontology Software prototype Completeness Correctness Consistency Performance Usability CA-RBAC [15] N/A P/A N/A N/A N/A N/A N/A N/A N/A N/A N/A CERBAC [39] N/A P/A N/A N/A N/A N/A N/A N/A N/A N/A N/A DRBAC [40] N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A Access Control for Web Service [14] N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A Context-Aware RBAC [16] N/A P/A N/A N/A N/A N/A N/A N/A N/A N/A N/A Context-Aware RBAC [17] N/A P/A N/A N/A N/A N/A N/A N/A N/A N/A N/A Context-Aware RBAC [18] N/A P/A N/A N/A N/A N/A N/A N/A N/A N/A N/A Event-Driven RBAC [43, 44] P/A N/A YES N/A N/A YES YES YES YES YES N/A Access Control with VPD [49, 50] N/A P/A P/A N/A N/A YES P/A N/A N/A YES N/A Our CAAC Policy Framework YES YES YES YES YES YES YES YES YES YES YES View Large Table 32. Comparative analysis of our earlier context/situation-aware RBAC approaches. RBAC frameworks Formal model Implementation model Evaluation CAURA policy CARPA policy CSL CAURA ontology CARPA ontology Software prototype Completeness Correctness Consistency Performance Usability CAAC [21] N/A P/A N/A N/A P/A P/A N/A N/A N/A N/A N/A OntCAAC [19] N/A P/A N/A N/A P/A P/A P/A N/A N/A P/A N/A PO-SAAC [41] N/A P/A N/A N/A P/A P/A P/A N/A N/A P/A N/A Ontological SAAC Framework [42] N/A P/A N/A N/A P/A P/A P/A N/A N/A P/A N/A Our CAAC Policy Framework YES YES YES YES YES YES YES YES YES YES YES RBAC frameworks Formal model Implementation model Evaluation CAURA policy CARPA policy CSL CAURA ontology CARPA ontology Software prototype Completeness Correctness Consistency Performance Usability CAAC [21] N/A P/A N/A N/A P/A P/A N/A N/A N/A N/A N/A OntCAAC [19] N/A P/A N/A N/A P/A P/A P/A N/A N/A P/A N/A PO-SAAC [41] N/A P/A N/A N/A P/A P/A P/A N/A N/A P/A N/A Ontological SAAC Framework [42] N/A P/A N/A N/A P/A P/A P/A N/A N/A P/A N/A Our CAAC Policy Framework YES YES YES YES YES YES YES YES YES YES YES View Large Table 32. Comparative analysis of our earlier context/situation-aware RBAC approaches. RBAC frameworks Formal model Implementation model Evaluation CAURA policy CARPA policy CSL CAURA ontology CARPA ontology Software prototype Completeness Correctness Consistency Performance Usability CAAC [21] N/A P/A N/A N/A P/A P/A N/A N/A N/A N/A N/A OntCAAC [19] N/A P/A N/A N/A P/A P/A P/A N/A N/A P/A N/A PO-SAAC [41] N/A P/A N/A N/A P/A P/A P/A N/A N/A P/A N/A Ontological SAAC Framework [42] N/A P/A N/A N/A P/A P/A P/A N/A N/A P/A N/A Our CAAC Policy Framework YES YES YES YES YES YES YES YES YES YES YES RBAC frameworks Formal model Implementation model Evaluation CAURA policy CARPA policy CSL CAURA ontology CARPA ontology Software prototype Completeness Correctness Consistency Performance Usability CAAC [21] N/A P/A N/A N/A P/A P/A N/A N/A N/A N/A N/A OntCAAC [19] N/A P/A N/A N/A P/A P/A P/A N/A N/A P/A N/A PO-SAAC [41] N/A P/A N/A N/A P/A P/A P/A N/A N/A P/A N/A Ontological SAAC Framework [42] N/A P/A N/A N/A P/A P/A P/A N/A N/A P/A N/A Our CAAC Policy Framework YES YES YES YES YES YES YES YES YES YES YES View Large 7.6.1. Comparative analysis of the context-aware RBAC approaches Table 31 shows a comparative analysis of the existing context-specific RBAC approaches [14, 15–18, 39, 40, 43, 44, 49, 50] with respect to our CAAC policy framework. In general, the existing context-aware RBAC approaches support the specification of access control policies in terms of specific types of context information, each of them having different goals and they are highly domain-specific. However, there is still a need for a context-aware access control (CAAC) framework to incorporate the relevant context information into the basic RBAC processes. To fill this gap, in this paper, we have introduced both the formal and ontology-based policy models to specify context-aware user-role assignments (CAURA) and context-aware role-permission assignments (CARPA) policies. Using these models, we provide the architecture and (software) prototype implementation for building CAAC applications that enforces CAURA and CARPA policies. We present the evaluation results of the policy ontology model and framework through the prototype and the results demonstrate the completeness, correctness and consistency of the ontology model concepts/semantics, the efficiency in terms of response time, and its usability in a real setup with real users as well. 7.6.2. Comparative analysis of our earlier context/situation-aware RBAC approaches Table 32 shows a comparative analysis of our earlier work on context/situation-aware access control [19, 21, 41, 42] with respect to our CAAC policy framework. The CAAC policy framework presented in this paper extends our earlier work on access control in the following ways. In general, our previous context/situation-aware access control approaches support the specification and enforcement of RBAC policies in terms of relevant context information. However, these access control approaches and their associated policy models are still limited in representing and modelling the two sets of context-aware access control policies (namely the context-aware user-role and role-permission assignments policies). As a consequence, they are not able to offer the advantages of context-aware user-role and role-permission assignments in accordance with the relevant contextual conditions. To this end, we introduce a formal policy model to specify the two sets of policies. The formal model also includes a simple language to express contextual conditions based on the simple and complex context information. In addition, in this paper, we extend our previous software architecture and prototype [19, 42] for building CAAC applications, providing mechanisms and tool support for modelling and enforcing CAURA and CARPA policies. Furthermore, this paper justifies the feasibility of the policy ontology model by demonstrating its completeness, correctness, consistency, efficiency and usability, whereas our earlier access control approaches demonstrate the feasibility in terms of the case study and performance overhead. 8. CONCLUSION AND FUTURE WORK A general policy framework is presented in this paper for context-aware access control (CAAC) following the basic role-based access control mechanism. Our CAAC framework significantly differs from the existing access control frameworks in that it considers context-aware user-role and role-permission assignments by leveraging the dynamically changing contextual conditions. In particular, it has the capability of making context-sensitive access control decisions when there are dynamic changes to the context. It supports context-specific access control to information resources and dynamically re-evaluates the access control decisions when context changes. We have presented a formal model for specifying the context-aware access control policies in our framework. By introducing the concepts of context-aware user-role and role-permission assignments, the association of users to roles can be achieved dynamically based on the relevant context information, and these users can access the resources through the further dynamic association of context-dependent roles to permissions. Based on the formal model, we have developed an ontology-based policy framework for modelling and enforcing the two sets of access control policies: the context-aware user-role and role-permission assignment policies. The first set of policies specifies that users can play a particular role when certain contextual conditions are satisfied. The second set of policies specifies that users having roles are allowed to carry out an operation on resources when some further contextual conditions are satisfied. When a user wants to access resources at runtime, policy enforcement determines whether or not an access request is granted or denied. We have demonstrated the feasibility of the proposed CAAC framework by considering factors like the completeness, correctness and consistency of the application of our policy model through healthcare case studies, the performance of the policy framework, and the usability in a real setup using desktop and mobile-based prototypes. The evaluation results show that the core ontology with its domain-specific ontologies not only deliver complete, correct and consistent access control policies but also demonstrate the efficiency of the policy framework in terms of query response time and usability study. There are different ways to ensure the completeness, correctness and consistency of the ontology semantics. In this paper, we have evaluated these factors against case studies from the healthcare domain. In particular, we have evaluated the policy ontology in order to show the “case-based proof of the applicability of the ontology concepts”, instead of showing the “proof of the validity of the underlying formalization of the ontology concepts”. However, while it is beyond the scope of this paper, further investigation to justify the feasibility of the underlying formalization of the ontology concepts and formal semantics is required in the future. FUNDING The student is partially supported by the Korea Ministry of ICT and Future Planning grant to Gachon University National Program of Excellence in Software. The statements made herein are solely the responsibility of the authors. ACKNOWLEDGEMENTS We acknowledge the contributions of our internship student, Youmin Kim from Gachon University, South Korea, for the development of our healthcare application. REFERENCES 1 Kayes , A.S.M. , Han , J. and Colman , A. ( 2013 ) A Semantic Policy Framework for Context-Aware Access Control Applications. TrustCom, pp. 753–762. 2 Dey , A.K. ( 2001 ) Understanding and using context . Personal Ubiquitous Comput. , 5 , 4 – 7 . Google Scholar Crossref Search ADS 3 Dey , A.K. , Abowd , G.D. and Salber , D. ( 2001 ) A conceptual framework and a toolkit for supporting the rapid prototyping of context-aware applications . Hum Comput. Interact. , 16 , 97 – 166 . Google Scholar Crossref Search ADS 4 Ferraiolo , D. and Kuhn , R. ( 1992 ) Role-based access control. In 15th NIST-NCSC National Computer Security Conference, pp. 554–563. 5 Sandhu , R.S. , Coyne , E.J. , Feinstein , H.L. and Youman , C.E. ( 1996 ) Role-based access control models . IEEE Comput. , 29 , 38 – 47 . Google Scholar Crossref Search ADS 6 Sandhu , R.S. and Samarati , P. ( 1994 ) Access control: principle and practice . Commun. Mag. IEEE , 32 , 40 – 48 . Google Scholar Crossref Search ADS 7 O’Connor , A.C. and Loomis , R.J. ( 2010 ) Economic analysis of role-based access control. NIST report 4. 8 Ferraiolo , D.F. , Sandhu , R. , Gavrila , S. , Kuhn , D.R. and Chandramouli , R. ( 2001 ) Proposed nist standard for role-based access control . ACM Trans. Inf. Syst. Secur. , 4 , 224 – 274 . Google Scholar Crossref Search ADS 9 Corradi , A. , Montanari , R. and Tibaldi , D. ( 2004 ) Context-Based Access Control for Ubiquitous Service Provisioning. COMPSAC, pp. 444–451. 10 Bertino , E. , Bonatti , P.A. and Ferrari , E. ( 2001 ) Trbac: a temporal role-based access control model . ACM Trans. Inf. Syst. Secur. , 4 , 191 – 233 . Google Scholar Crossref Search ADS 11 Joshi , J. , Bertino , E. , Latif , U. and Ghafoor , A. ( 2005 ) A generalized temporal role-based access control model . IEEE Trans. Knowl. Data Eng. , 17 , 4 – 23 . Google Scholar Crossref Search ADS 12 Bertino , E. , Catania , B. , Damiani , M.L. and Perlasca , P. ( 2005 ) GEO-RBAC: A Spatially Aware RBAC. SACMAT, pp. 29–37. 13 Chandran , S.M. and Joshi , J.B.D. ( 2005 ) LoT-RBAC: A Location and Time-Based RBAC Model. WISE, pp. 361–375. 14 He , Z. , Wu , L. , Li , H. , Lai , H. and Hong , Z. ( 2011 ) Semantics-based access control approach for web service . JCP , 6 , 1152 – 1161 . 15 Kulkarni , D. and Tripathi , A. ( 2008 ) Context-Aware Role-Based Access Control in Pervasive Computing Systems. SACMAT, pp. 113–122. 16 Schefer-Wenzl , S. and Strembeck , M. ( 2013 ) Modelling context-aware rbac models for mobile business processes . IJWMC , 6 , 448 – 462 . Google Scholar Crossref Search ADS 17 Hosseinzadeh , S. , Virtanen , S. , Rodríguez , N.D. and Lilius , J. ( 2016 ) A Semantic Security Framework and Context-Aware Role-Based Access Control Ontology for Smart Spaces. SBD@SIGMOD, pp. 1–6. 18 Trnka , M. and Cerný , T. ( 2016 ) On Security Level Usage in Context-Aware Role-Based Access Control. SAC, pp. 1192–1195. 19 Kayes , A.S.M. , Han , J. and Colman , A. ( 2015 ) Ontcaac: an ontology-based approach to context-aware access control for software services . Comput. J. , 58 , 3000 – 3034 . Google Scholar Crossref Search ADS 20 ASCO ( 2017 ). Australian Standard Classification of Occupations: Health Professionals, http://www.abs.gov.au/. 21 Kayes , A.S.M. , Han , J. and Colman , A. ( 2013 ) An Ontology-Based Approach to Context-Aware Access Control for Software Services. WISE, pp. 410–420. 22 Bettini , C. , Brdiczka , O. , Henricksen , K. , Indulska , J. , Nicklas , D. , Ranganathan , A. and Riboni , D. ( 2010 ) A survey of context modelling and reasoning techniques . Pervasive Mobile Comput. , 6 , 161 – 180 . Google Scholar Crossref Search ADS 23 Riboni , D. and Bettini , C. ( 2011 ) Owl 2 modeling and reasoning with complex human activities . Pervasive Mobile Comput. , 7 , 379 – 395 . Google Scholar Crossref Search ADS 24 OWL ( 2017 ). Web Ontology Language, http://www.w3.org/2007/owl/. 25 SWRL ( 2017 ). Semantic Web Rule Language, http://www.w3.org/submission/swrl/ . 26 SWRL-Built-Ins ( 2017 ). SWRL Built-Ins for Comparisons, Strings, Boolean Values, Date, Time, Duration, URLs, Lists, and Math Built-Ins, http://www.daml.org/2004/04/swrl/builtins.html. 27 Protégé ( 2017 ). Protégé-OWL API, http://protege.stanford.edu/. 28 Jess ( 2017 ). Jess Rule Engine, http://herzberg.ca.sandia.gov/jess/. 29 Fudholi , D.H. , Rahayu , J.W. and Pardede , E. ( 2015 ) A data-driven dynamic ontology . J. Inf. Sci. , 41 , 383 – 398 . Google Scholar Crossref Search ADS 30 O’Connor , M.J. and Das , A.K. ( 2009 ) Sqwrl: A Query Language for Owl. OWLED. 31 J2SE ( 2017 ). Java 2 Platform Standard Edition, http://www.oracle.com/technetwork/java/javase/downloads. 32 HL7 ( 2017 ). Health Level Seven Standard for Healthcare Resources, http://www.hl7.org.au/. 33 Protégé-OWLSWRLTab ( 2017 ). https://protegewiki.stanford.edu/wiki/swrltab. 34 O’Connor , M. ( 2017 ). Protégé-OWL SWRL Query Tab, https://protege.stanford.edu/conference/2007/presen-tations/08.01_oconnor.pdf. 35 OracleVPD ( 2017 ) Using Oracle Virtual Private Database to Control Data Access, http://docs.oracle.com/cd/B28359_01/network.111/b28531/vpd.htm. ORACLE Database Security Guide. 36 Rizvi , S. , Mendelzon , A. , Sudarshan , S. and Roy , P. ( 2004 ) Extending Query Rewriting Techniques for Fine-Grained Access Control. Proc. 2004 ACM SIGMOD Int. Conf. Management of Data, pp. 551–562. ACM. 37 Zhang , H. , He , Y. and Shi , Z. ( 2006 ) Spatial Context in Role-Based Access Control. ICISC, pp. 166–178. 38 Bhatti , R. , Ghafoor , A. , Bertino , E. and Joshi , J. ( 2005 ) X-gtrbac: an xml-based policy specification framework and architecture for enterprise-wide access control . ACM Trans. Inf. Syst. Secur. , 8 , 187 – 227 . Google Scholar Crossref Search ADS 39 Wang , C.-D. , Li , T. and Feng , L.-C. ( 2008 ) Context-Aware Environment-Role-Based Access Control Model for Web Services. MUE, pp. 288–293. 40 Zheng , J. , Zhang , K.Q. , Zheng , W.S. and Tan , A.Y. ( 2011 ) Dynamic role-based access control model . JSW , 6 , 1096 – 1102 . 41 Kayes , A.S.M. , Han , J. and Colman , A. ( 2014 ) PO-SAAC: A Purpose-Oriented Situation-Aware Access Control Framework for Software Services. CAiSE, pp. 58–74. 42 Kayes , A.S.M. , Han , J. and Colman , A.W. ( 2015 ) An ontological framework for situation-aware access control of software services . Inf. Syst. , 53 , 253 – 277 . Google Scholar Crossref Search ADS 43 Bonatti , P. , Galdi , C. and Torres , D. ( 2013 ) ERBAC: Event-Driven RBAC. Proc. 18th ACM Sympos. Access Control Models and Technologies, pp. 125–136. ACM. 44 Bonatti , P. , Galdi , C. and Torres , D. ( 2015 ) Event-driven rbac . J. Comput. Secur. , 23 , 709 – 757 . Google Scholar Crossref Search ADS 45 Ni , Q. , Bertino , E. , Lobo , J. , Brodie , C. , Karat , C.-M. , Karat , J. and Trombeta , A. ( 2010 ) Privacy-aware role-based access control . ACM Trans. Inf. Syst. Secur. (TISSEC) , 13 , 24 . Google Scholar Crossref Search ADS 46 Moses , T. ( 2005 ) Extensible Access Control Markup Language (XACML), https://www.oasis-open.org/committees/xacml/. OASIS Standard. 47 Anderson , A. ( 2005 ) Core and Hierarchical Role Based Access Control (RBAC) Profile of XACML v2.0, http://docs.oasis-open.org/xacml/2.0/access_control-xacml-2.0-rbac-profile1-spec-os.pdf. OASIS Standard. 48 Rissanen , E. ( 2014 ) XACMLv3.0 Core and Hierarchical Role Based Access Control (RBAC) Profile Version 1.0, http://http://docs.oasis-open.org/xacml/3.0/rbac/v1.0/xacml-3.0-rbac-v1.0.html. OASIS Standard. 49 Colombo , P. and Ferrari , E. ( 2016 ) Fine-grained access control within nosql document-oriented datastores . Data Sci. Eng. , 1 , 127 – 138 . Google Scholar Crossref Search ADS 50 Colombo , P. and Ferrari , E. ( 2016 ) Towards Virtual Private Nosql Datastores. 2016 IEEE 32nd Int. Conf. Data Engineering (ICDE), pp. 193–204. IEEE. Appendix 1 CAURA POLICY SPECIFICATION The following code fragment in OWL (see Definition 13) shows the definition of all basic classes of CAURA policy: CAURAPolicy, ContextualCondition, ContextInfo, User and Role (see CAURAPolicy ontology in Fig. 4 in Section 4.2). Definition 13 (Definitions of Basic Classes).    <owl:Classrdf:ID=“CAURAPolicy”>    <owl:Classrdf:ID=“ContextualCondition”>    <owl:Classrdf:ID=“ContextInfo”>    <owl:Classrdf:ID=“User”>    <owl:Classrdf:ID=“Role”>    <owl:Classrdf:ID=“CAURAPolicy”>    <owl:Classrdf:ID=“ContextualCondition”>    <owl:Classrdf:ID=“ContextInfo”>    <owl:Classrdf:ID=“User”>    <owl:Classrdf:ID=“Role”>    <owl:Classrdf:ID=“CAURAPolicy”>    <owl:Classrdf:ID=“ContextualCondition”>    <owl:Classrdf:ID=“ContextInfo”>    <owl:Classrdf:ID=“User”>    <owl:Classrdf:ID=“Role”>    <owl:Classrdf:ID=“CAURAPolicy”>    <owl:Classrdf:ID=“ContextualCondition”>    <owl:Classrdf:ID=“ContextInfo”>    <owl:Classrdf:ID=“User”>    <owl:Classrdf:ID=“Role”> Definition 14 shows the class CAURAPolicy has an object property hasUser ⁠, which is used to link the classes CAURAPolicy and User. Definition 14 (‘hasUser’ Object Property Definition).    <owl:ObjectPropertyrdf:ID=“hasUser”>     <rdfs:domainrdf:resource=“#CAURAPolicy”/>     <rdfs:rangerdf:resource=“#User”/>    </owl:ObjectProperty>    <owl:ObjectPropertyrdf:ID=“hasUser”>     <rdfs:domainrdf:resource=“#CAURAPolicy”/>     <rdfs:rangerdf:resource=“#User”/>    </owl:ObjectProperty>    <owl:ObjectPropertyrdf:ID=“hasUser”>     <rdfs:domainrdf:resource=“#CAURAPolicy”/>     <rdfs:rangerdf:resource=“#User”/>    </owl:ObjectProperty>    <owl:ObjectPropertyrdf:ID=“hasUser”>     <rdfs:domainrdf:resource=“#CAURAPolicy”/>     <rdfs:rangerdf:resource=“#User”/>    </owl:ObjectProperty> Similar to Definition 14, we define two other object properties hasRole and hasCondition ⁠. The property hasRole is used to link the classes CAURAPolicy and Role (see Definition 15), and the property hasCondition links the classes CAURAPolicy and ContextualCondition (see Definition 16). Definition 15 (‘hasRole’ Object Property Definition).    <owl:ObjectPropertyrdf:ID=“hasRole”>     <rdfs:domainrdf:resource=“#CAURAPolicy”/>     <rdfs:rangerdf:resource=“#Role”/>    </owl:ObjectProperty>    <owl:ObjectPropertyrdf:ID=“hasRole”>     <rdfs:domainrdf:resource=“#CAURAPolicy”/>     <rdfs:rangerdf:resource=“#Role”/>    </owl:ObjectProperty>    <owl:ObjectPropertyrdf:ID=“hasRole”>     <rdfs:domainrdf:resource=“#CAURAPolicy”/>     <rdfs:rangerdf:resource=“#Role”/>    </owl:ObjectProperty>    <owl:ObjectPropertyrdf:ID=“hasRole”>     <rdfs:domainrdf:resource=“#CAURAPolicy”/>     <rdfs:rangerdf:resource=“#Role”/>    </owl:ObjectProperty> Definition 16 (‘hasCondition’ Object Property Definition).    <owl:ObjectPropertyrdf:ID=“hasCondition”>     <rdfs:domainrdf:resource=“#CAURAPolicy”/>     <rdfs:rangerdf:resource=“#ContextualCondition”/>    </owl:ObjectProperty>    <owl:ObjectPropertyrdf:ID=“hasCondition”>     <rdfs:domainrdf:resource=“#CAURAPolicy”/>     <rdfs:rangerdf:resource=“#ContextualCondition”/>    </owl:ObjectProperty>    <owl:ObjectPropertyrdf:ID=“hasCondition”>     <rdfs:domainrdf:resource=“#CAURAPolicy”/>     <rdfs:rangerdf:resource=“#ContextualCondition”/>    </owl:ObjectProperty>    <owl:ObjectPropertyrdf:ID=“hasCondition”>     <rdfs:domainrdf:resource=“#CAURAPolicy”/>     <rdfs:rangerdf:resource=“#ContextualCondition”/>    </owl:ObjectProperty> Definition 17 shows that the class User has a data type property userIdentity ⁠, which is xsd:string type, while Definition 18 shows that the class Role has a xsd:string type property, named roleIdentity ⁠. Definition 17 (‘userIdentity’ Data Type Property Definition).    <owl:DatatypePropertyrdf:ID=“userIdentity”>     <rdfs:domainrdf:resource=“#User”/>     <rdfs:rangerdf:resource=“&xsd;string”/>    </owl:DatatypeProperty>    <owl:DatatypePropertyrdf:ID=“userIdentity”>     <rdfs:domainrdf:resource=“#User”/>     <rdfs:rangerdf:resource=“&xsd;string”/>    </owl:DatatypeProperty>    <owl:DatatypePropertyrdf:ID=“userIdentity”>     <rdfs:domainrdf:resource=“#User”/>     <rdfs:rangerdf:resource=“&xsd;string”/>    </owl:DatatypeProperty>    <owl:DatatypePropertyrdf:ID=“userIdentity”>     <rdfs:domainrdf:resource=“#User”/>     <rdfs:rangerdf:resource=“&xsd;string”/>    </owl:DatatypeProperty> Definition 18 (‘roleIdentity’ Data Type Property Definition).    <owl:DatatypePropertyrdf:ID=“roleIdentity”>     <rdfs:domainrdf:resource=“#Role”/>     <rdfs:rangerdf:resource=“&xsd;string”/>    </owl:DatatypeProperty>    <owl:DatatypePropertyrdf:ID=“roleIdentity”>     <rdfs:domainrdf:resource=“#Role”/>     <rdfs:rangerdf:resource=“&xsd;string”/>    </owl:DatatypeProperty>    <owl:DatatypePropertyrdf:ID=“roleIdentity”>     <rdfs:domainrdf:resource=“#Role”/>     <rdfs:rangerdf:resource=“&xsd;string”/>    </owl:DatatypeProperty>    <owl:DatatypePropertyrdf:ID=“roleIdentity”>     <rdfs:domainrdf:resource=“#Role”/>     <rdfs:rangerdf:resource=“&xsd;string”/>    </owl:DatatypeProperty> Definition 19 shows the class ContextualCondition has an object property hasContext ⁠, which is used to link the classes ContextualCondition and ContextInfo. Definition 19 (‘hasContext’ Object Property Definition).    <owl:ObjectPropertyrdf:ID=“hasContext”>     <rdfs:domainrdf:resource=“#ContextualCondition”/>     <rdfs:rangerdf:resource=“#ContextInfo”/>    </owl:ObjectProperty>    <owl:ObjectPropertyrdf:ID=“hasContext”>     <rdfs:domainrdf:resource=“#ContextualCondition”/>     <rdfs:rangerdf:resource=“#ContextInfo”/>    </owl:ObjectProperty>    <owl:ObjectPropertyrdf:ID=“hasContext”>     <rdfs:domainrdf:resource=“#ContextualCondition”/>     <rdfs:rangerdf:resource=“#ContextInfo”/>    </owl:ObjectProperty>    <owl:ObjectPropertyrdf:ID=“hasContext”>     <rdfs:domainrdf:resource=“#ContextualCondition”/>     <rdfs:rangerdf:resource=“#ContextInfo”/>    </owl:ObjectProperty> Definition 20 shows that the class ContextInfo has two subclasses SimpleContext and ComplexContext. Definition 20 (ContextInfo Class and Its Two Subclasses).    <owl:Classrdf:ID=“SimpleContext”>     <rdfs:subClassOfrdf:resource=“#ContextInfo”/>    </owl:Class>    <owl:Classrdf:ID=“ComplexContext”>     <rdfs:subClassOfrdf:resource=“#ContextInfo”/>    </owl:Class>    <owl:Classrdf:ID=“SimpleContext”>     <rdfs:subClassOfrdf:resource=“#ContextInfo”/>    </owl:Class>    <owl:Classrdf:ID=“ComplexContext”>     <rdfs:subClassOfrdf:resource=“#ContextInfo”/>    </owl:Class>    <owl:Classrdf:ID=“SimpleContext”>     <rdfs:subClassOfrdf:resource=“#ContextInfo”/>    </owl:Class>    <owl:Classrdf:ID=“ComplexContext”>     <rdfs:subClassOfrdf:resource=“#ContextInfo”/>    </owl:Class>    <owl:Classrdf:ID=“SimpleContext”>     <rdfs:subClassOfrdf:resource=“#ContextInfo”/>    </owl:Class>    <owl:Classrdf:ID=“ComplexContext”>     <rdfs:subClassOfrdf:resource=“#ContextInfo”/>    </owl:Class> Appendix 2 CARPA POLICY SPECIFICATION The following code fragment in OWL (see Definition 21) shows the definition of all basic classes of CARPA policy: CARPAPolicy, Permission, Operation, Resource, Owner and AccessDecision (see CARPAPolicy ontology in Fig. 5 in Section 4.3). Note that we have already defined the classes Role, ContextualCondition, ContextInfo, SimpleContext, and ComplexContext in Appendix A. Definition 21 (Definition of Basic Classes).    <owl:Classrdf:ID=“CARPAPolicy”>    <owl:Classrdf:ID=“Permission”>    <owl:Classrdf:ID=“Operation”>    <owl:Classrdf:ID=“Resource”>    <owl:Classrdf:ID=“Owner”>    <owl:Classrdf:ID=“AccessDecision”>    <owl:Classrdf:ID=“CARPAPolicy”>    <owl:Classrdf:ID=“Permission”>    <owl:Classrdf:ID=“Operation”>    <owl:Classrdf:ID=“Resource”>    <owl:Classrdf:ID=“Owner”>    <owl:Classrdf:ID=“AccessDecision”>    <owl:Classrdf:ID=“CARPAPolicy”>    <owl:Classrdf:ID=“Permission”>    <owl:Classrdf:ID=“Operation”>    <owl:Classrdf:ID=“Resource”>    <owl:Classrdf:ID=“Owner”>    <owl:Classrdf:ID=“AccessDecision”>    <owl:Classrdf:ID=“CARPAPolicy”>    <owl:Classrdf:ID=“Permission”>    <owl:Classrdf:ID=“Operation”>    <owl:Classrdf:ID=“Resource”>    <owl:Classrdf:ID=“Owner”>    <owl:Classrdf:ID=“AccessDecision”> Each AccessDecision class instance has exactly one decision attribute value, which means the value of the decision attribute may be “Granted” or “Denied”. As such, it is not possible for the decision attribute to have both “Granted” and “Denied” values for an access policy. Definition 22 specifies the cardinality of the class AccessDecision on the property decision ⁠. Definition 22 (Cardinality Constraint Definition of a Property ‘decision’).    <owl:Classrdf:ID=“AccessDecision”>    <owl:Restriction>    <owl:onPropertyrdf:resource=“#decision”/>    <owl:cardinalityrdf:datatype=    “&xsd;nonNegativeInteger”>1    </owl:cardinality>    </owl:Restriction>    </owl:Class>    <owl:Classrdf:ID=“AccessDecision”>    <owl:Restriction>    <owl:onPropertyrdf:resource=“#decision”/>    <owl:cardinalityrdf:datatype=    “&xsd;nonNegativeInteger”>1    </owl:cardinality>    </owl:Restriction>    </owl:Class>    <owl:Classrdf:ID=“AccessDecision”>    <owl:Restriction>    <owl:onPropertyrdf:resource=“#decision”/>    <owl:cardinalityrdf:datatype=    “&xsd;nonNegativeInteger”>1    </owl:cardinality>    </owl:Restriction>    </owl:Class>    <owl:Classrdf:ID=“AccessDecision”>    <owl:Restriction>    <owl:onPropertyrdf:resource=“#decision”/>    <owl:cardinalityrdf:datatype=    “&xsd;nonNegativeInteger”>1    </owl:cardinality>    </owl:Restriction>    </owl:Class> The following OWL code shows that the object property hasDecision links the classes CARPAPolicy and AccessDecision (see Definition 23). Definition 23 (‘hasDecision’ Object Property Definition).    <owl:ObjectPropertyrdf:ID=“hasDecision”>     <rdfs:domainrdf:resource=“#CARPAPolicy”/>     <rdfs:rangerdf:resource=“#AccessDecision”/>    </owl:ObjectProperty>    <owl:ObjectPropertyrdf:ID=“hasDecision”>     <rdfs:domainrdf:resource=“#CARPAPolicy”/>     <rdfs:rangerdf:resource=“#AccessDecision”/>    </owl:ObjectProperty>    <owl:ObjectPropertyrdf:ID=“hasDecision”>     <rdfs:domainrdf:resource=“#CARPAPolicy”/>     <rdfs:rangerdf:resource=“#AccessDecision”/>    </owl:ObjectProperty>    <owl:ObjectPropertyrdf:ID=“hasDecision”>     <rdfs:domainrdf:resource=“#CARPAPolicy”/>     <rdfs:rangerdf:resource=“#AccessDecision”/>    </owl:ObjectProperty> The class Permission links to the classes Resource and Operation using two object properties hasResource and hasOperation ⁠, respectively (see Definitions 24 and 25). Definition 24 (‘hasResource’ Object Property Definition).    <owl:ObjectPropertyrdf:ID=“hasResource”>     <rdfs:domainrdf:resource=“#Permission”/>     <rdfs:rangerdf:resource=“#Resource”/>    </owl:ObjectProperty>    <owl:ObjectPropertyrdf:ID=“hasResource”>     <rdfs:domainrdf:resource=“#Permission”/>     <rdfs:rangerdf:resource=“#Resource”/>    </owl:ObjectProperty>    <owl:ObjectPropertyrdf:ID=“hasResource”>     <rdfs:domainrdf:resource=“#Permission”/>     <rdfs:rangerdf:resource=“#Resource”/>    </owl:ObjectProperty>    <owl:ObjectPropertyrdf:ID=“hasResource”>     <rdfs:domainrdf:resource=“#Permission”/>     <rdfs:rangerdf:resource=“#Resource”/>    </owl:ObjectProperty> Definition 25 (‘hasOperation’ Object Property Definition).    <owl:ObjectPropertyrdf:ID=“hasOperation”>     <rdfs:domainrdf:resource=“#Permission”/>     <rdfs:rangerdf:resource=“#Operation”/>    </owl:ObjectProperty>    <owl:ObjectPropertyrdf:ID=“hasOperation”>     <rdfs:domainrdf:resource=“#Permission”/>     <rdfs:rangerdf:resource=“#Operation”/>    </owl:ObjectProperty>    <owl:ObjectPropertyrdf:ID=“hasOperation”>     <rdfs:domainrdf:resource=“#Permission”/>     <rdfs:rangerdf:resource=“#Operation”/>    </owl:ObjectProperty>    <owl:ObjectPropertyrdf:ID=“hasOperation”>     <rdfs:domainrdf:resource=“#Permission”/>     <rdfs:rangerdf:resource=“#Operation”/>    </owl:ObjectProperty> The Operation class has a data type property action (xsd:string type) in order to capture the operation on the resource. The following OWL code shows the property definition (see Definition 26). Definition 26 (‘action’ Data Type Property Definition).    <owl:DatatypePropertyrdf:ID=“action”>     <rdfs:domainrdf:resource=“#Operation”/>     <rdfs:rangerdf:resource=“&xsd;string”/>    </owl:DatatypeProperty>    <owl:DatatypePropertyrdf:ID=“action”>     <rdfs:domainrdf:resource=“#Operation”/>     <rdfs:rangerdf:resource=“&xsd;string”/>    </owl:DatatypeProperty>    <owl:DatatypePropertyrdf:ID=“action”>     <rdfs:domainrdf:resource=“#Operation”/>     <rdfs:rangerdf:resource=“&xsd;string”/>    </owl:DatatypeProperty>    <owl:DatatypePropertyrdf:ID=“action”>     <rdfs:domainrdf:resource=“#Operation”/>     <rdfs:rangerdf:resource=“&xsd;string”/>    </owl:DatatypeProperty> The class Resource links to the Owner class using an object property isOwnerBy (see Definition 27). Definition 27 (‘isOwnedBy’ Object Property Definition).    <owl:ObjectPropertyrdf:ID=“isOwnedBy”>     <rdfs:domainrdf:resource=“#Resource”/>     <rdfs:rangerdf:resource=“#Owner”/>    </owl:ObjectProperty>    <owl:ObjectPropertyrdf:ID=“isOwnedBy”>     <rdfs:domainrdf:resource=“#Resource”/>     <rdfs:rangerdf:resource=“#Owner”/>    </owl:ObjectProperty>    <owl:ObjectPropertyrdf:ID=“isOwnedBy”>     <rdfs:domainrdf:resource=“#Resource”/>     <rdfs:rangerdf:resource=“#Owner”/>    </owl:ObjectProperty>    <owl:ObjectPropertyrdf:ID=“isOwnedBy”>     <rdfs:domainrdf:resource=“#Resource”/>     <rdfs:rangerdf:resource=“#Owner”/>    </owl:ObjectProperty> The class Resource has a data type property resourceIdentity ⁠, which is of xsd:string type (see Definition 28), and the class Owner has a property ownerIdentity of xsd:string type (see Definition 29). Definition 28 (‘resourceIdentity’ Data Type Property Definition).    <owl:DatatypePropertyrdf:ID=“resourceIdentity”>     <rdfs:domainrdf:resource=“#Resource”/>     <rdfs:rangerdf:resource=“&xsd;string”/>    </owl:DatatypeProperty>    <owl:DatatypePropertyrdf:ID=“resourceIdentity”>     <rdfs:domainrdf:resource=“#Resource”/>     <rdfs:rangerdf:resource=“&xsd;string”/>    </owl:DatatypeProperty>    <owl:DatatypePropertyrdf:ID=“resourceIdentity”>     <rdfs:domainrdf:resource=“#Resource”/>     <rdfs:rangerdf:resource=“&xsd;string”/>    </owl:DatatypeProperty>    <owl:DatatypePropertyrdf:ID=“resourceIdentity”>     <rdfs:domainrdf:resource=“#Resource”/>     <rdfs:rangerdf:resource=“&xsd;string”/>    </owl:DatatypeProperty> Definition 29 (‘ownerIdentity’ Data Type Property Definition).    <owl:DatatypePropertyrdf:ID=“ownerIdentity”>     <rdfs:domainrdf:resource=“#Owner”/>     <rdfs:rangerdf:resource=“&xsd;string”/>    </owl:DatatypeProperty>    <owl:DatatypePropertyrdf:ID=“ownerIdentity”>     <rdfs:domainrdf:resource=“#Owner”/>     <rdfs:rangerdf:resource=“&xsd;string”/>    </owl:DatatypeProperty>
TI - A Policy Model and Framework for Context-Aware Access Control to Information Resources
JF - The Computer Journal
DO - 10.1093/comjnl/bxy065
DA - 2019-05-01
UR - https://www.deepdyve.com/lp/oxford-university-press/a-policy-model-and-framework-for-context-aware-access-control-to-LZ47ClmW64
SP - 670
VL - 62
IS - 5
DP - DeepDyve
ER -