Context Delegation for Context-Based Access Control

Abstract

The capability to delegate access privileges is an essential component of access control policies. We present an ontology-based context delegation approach for context-based access control. Our approach provides a dynamic and adaptive context delegation capability. The delegation does not cause any change to the underlying access control policy. We use Description logic (DL) and Logic Programming (LP) technologies for modeling contexts, delegation and CBAC privileges. We show how semantic-based techniques can be used to support adaptive and dynamic context delegation for CBAC policies. We provide the formal framework of the approach and show that it is decidable and consistent.

1 Introduction

Delegation of the privileges is an important mechanism to support dynamic and adaptive access control in real world applications. There is a significant previous work on Context-Based Access Control (CBAC) [1,2,3,4,5,6, 10, 15]. However, support to delegate CBAC privileges is limited. For example, approaches described in [1,2,3,4, 15] do not provide any delegation services. Most of the existing delegation methods are based on traditional access control models, such as Role-Based Access Control (RBAC) models [6, 7]. Methods such as attribute-based delegation [8, 9] and capability-based delegation [10, 11] require that the underlying access control policy is changed. Moreover, none of the methods address the issue of context delegation when the access authorization is a context-dependent.

We propose a context delegation approach for CBAC policies. Our approach is grounded in semantic web technologies, specifically, Web Ontology Language (OWL) ontologies [17, 18], Semantic Web Rule Language (SWRL) [12] and Pellet reasoner [13]. The main advantages of using OWL-based technologies to represent access control are as follows: OWL ontologies provide formal framework since they are based on Description Logics. XML documents [14], for example, lack the formal semantics. OWL ontologies can encompass any XML representation or a Resource Description Framework (RDF) ontology. Finally, OWL-DL ontologies have the expressivity of DLs and the properties of completeness and decidability. OWL-DL reasoning can be provided by open-source reasoners, such as Pellet [13]. Using SWRL rules permits the use of dynamic variables that can not be determined during ontological policy specification. In our approach, SWRL rules are used to instantiate and validate the value of these variables at runtime.

The main contributions of our approach are: (1) Our method provides dynamic and adaptive context delegation that does not modify the original access control policy. (2) Our approach can be adopted by existing CBAC systems which do not provide delegation services. (3) Our semantic-based delegation model supports capabilities such as checking the access control and delegation policies for conflict and consistency, explaining inferences and helping to instantiate and validate the variables in dynamic environments.

The remainder of this paper is organized as follows: in Sect. 2, we present the context-based access control system modeling. Section 3 is dedicated to semantic-based context delegation, and in Sect. 4 we conclude with suggestions for future work.

2 Context-Based Access Control System Modeling

In this section, we give a brief overview of the Context-Based access control.

“Context" has been defined by Dey et al. [16] as “any information that is useful for characterizing the state or the activity of an entity or the world in which this entity operates." In CBAC, the system administrator (or resource owner) specifies a set of contexts and defines for each context the set of applicable privileges. When an entity (a user) operates under a certain context, (s)he acquires the set of privileges (if any) that are associated with the active context. When (s)he changes the active context, the previous privileges are automatically revoked, and the new privileges acquired [5]. Hence, the Context plays a crucial role in evaluating the access privileges.

2.1 Context-Based Access Control Model

Access requests are evaluated based on the contexts associated with the subject and the requested. The request is matched with context metadata that specify and activate the policy rule that to be enforced. We use rule-based Logic Programming (LP) to encode context and policy rules.

(Access Control Policy (ACP) Rules): Access control policy rule is given as a 6-tuple $\langle s, sc, r, rc, p, ac\rangle$, where $s\in \mathbf {Subject}$, $r \in \mathbf {Resource}$, sc, rc $\in \mathbf {Context}$, where sc is the subject’s context and rc is the resource context, $p\in$ $\mathbf {Permission}$=$\{``Deny",``Permit"\}$, and ac $\in$ $\mathbf {Action}=\{read, write,delegate, revoke\}$. Each rule is instantiated by an access request, using the model ontologies and rules, and is evaluated at runtime to reach a decision.

(Access Request (AR)): Access request is given as a triple $\langle s,r,ac\rangle$, where $s \in \mathbf {Subject}$, $r \in \mathbf {Resource}$, $ac \in \mathbf {Action}$.

For example, an access request denoted as $ar=\langle s,r,``read"\rangle$, represents the case when subject s is requesting a “read" access to a resource r. The policy engine requests the contexts of s and r, and evaluates the permission p for the request ar. Assume the contexts of s and r are sc and rc, respectively. If using the contexts sc and rc, the policy engine can derive a permission, i.e., p is $+$, and there is no conflict, it grants the access permission for the request. Otherwise, it denies the request.

2.2 Ontology-Based Context Model

To model the context, we adopt a Description Logic (DL)-based method that partially resembles the method adopted by Bellavista and Montanari [15]. However, our context representation differs than that adopted by [15]. They have tightly coupled the subject’s context (they call it the requestor context), the resource’s context, the environmental context and the time context in one context (protection context). In our model, the subject’s context and resource’s context are separated. To support context delegation, we modify the subject’s context only. We represent our model using the OWL-DL ontologies, the reader is referred to [17] and [18] for additional description on the current OWL standard.

Our context model is built around the concept of contextual attribute, information which models contextual attributes of the physical/logical environment such as location and temperature. Specific context subclasses can be represented under Generic Concept Context. Each subcontext class consists of attribute values and constants. In our model, the generic context of the subject is given by the following DL axiom:

A context of OnDutyNurse, is represented as follows:

$$\begin{aligned}&OnDutyNurse\equiv Context \sqcap (User\sqcap \exists hasID.IDentity\sqcap \exists hasRole\\&.Role\{Nurse\}\sqcap \exists hasGroup.Group\{InShiftNurses\}) \sqcap \\&(Environment\{WorkingEnvironment\}\sqcap \exists hasLocation.Location\\&\{Hospital\})\sqcap (TElement\{WorkingTime\}\sqcap \exists hasTime\{xsd:dateTime\\&[\ge 2018-04-06T09:00:00,\le 2018-04-06T17:00:00]\})\sqcap \exists hasID.\{0\} \end{aligned}$$

Note that the concept OnDutyNurse includes all the characteristics specifications of the generic concept SContext. We call this context a reference context. It holds the high-level context of an entity which will be used later as a reference when we need to instantiate the active context of that entity. The active context holds the entity context at a specific instant of time. For example, when an entity requests an access to a resource. Active contexts are similar to their reference contexts counterparts. However, they differ in that they do not have range values in their definitions. Active context reflects a real snapshot of an entity’s context at a specific time instant. For example, the following DL axiom describes a certain user context at 2018-04-06T14:23:00, which represents 2:23 pm on April 6, 2018:

$$\begin{aligned}&OnDutyNurse\{Ann\}\equiv Context \sqcap (User\{Ann\}\sqcap \exists hasID.IDentity\{Nurse505\}\\&\sqcap \exists hasRole.Role\{Nurse\}\sqcap \exists hasGroup.Group\{InShiftNurses\})\sqcap \\&(Environment\{WorkingEnvironment\}\sqcap \exists hasLocation.Location \{Hospital\})\\ {}&\sqcap (TElement\{WorkingTime\}\sqcap \exists hasTime.Time\_Instance\{xsd:dateTime\\&[2018-04-06T14:23:00]\})\sqcap \exists hasID.\{0\} \end{aligned}$$

This concept states that Ann is OnDutyNurse at time 2:23 pm on April 6, 2018, if she is a user, has a role of Nurse, belongs to a group that is called InShiftNurses, within a WorkingEnvironment, at location Hospital and during the WorkingTime.

The context ontology is flexible. It can be extended or shrinked by adding or removing subcontexts or by adding or removing contextual attributes to the subcontexts.

3 Semantic-Based Context Delegation

The purpose of delegation is to grant/transfer access privileges from one entity, the delegator, to another entity, the delegatee. We require that the delegator must have the access privilege that is associated with context to be delegated. Delegating a subset of contextual attributes may result in a number of problems. These problems:

• Colluding [8], i.e., two entities may satisfy a policy that they could not if they acted individually. We do not address this problem in this paper.

• Inconsistent policy, i.e., the delegated privileges are conflicting the user’s original privileges. Our approach avoids inconsistent policies by evaluating delegator’s context together with the delegatee’s context.

At the time of delegation, the delegator must have the context c that is to be delegated to the delegatee. After the delegation is successfully completed, delegatee can use the delegated context and the privilege(s) associated with it to access to a resource r Our approach imposes constrains on context delegation. The constraints may be specified by the delegator or the system security officer. These constraints further restrict the delegation. Intuitively, if the delegatee’s context satisfies the constraints, then the delegation is permitted. Otherwise, the delegation will be aborted. Our model architecture is shown in Fig. 1.

Fig. 1.

The proposed system architecture.

(Delegation Request (DR)): Delegation request is given as a 6-tuple $\langle s_1,s_2,r,ac, \mathbf {DCs}, \mathbf {Par}\rangle$, where $s_1$, $s_2$ $\in \mathbf {Subject}$ and they represent the delegator and delegatee, respectively. $r \in \mathbf {Resource}$, the resource to make the delegation over, $ac \in \mathbf {Action}$, the action and must be equal to “delegate", $\mathbf {DCs} \subseteq \mathbf {Constraint}$ represents the set of constraints imposed by the delegator on delegatee’s context, and $\mathbf {Par}$ is a finite set of delegation parameters, other than the delegation constraints, which are specified by the delegator. Delegation parameters, $\mathbf {Par}$, are given by:

$$\begin{aligned} \mathbf {Par}=(n_1, v_1),...,(n_m, v_m) \end{aligned}$$

(1)

where $n_i$ represents the parameter $name_i$ and $v_i$ is the value of this parameter.

The $\mathbf {DCs}$ are represented as a set of pairs:

$$\begin{aligned} \mathbf {DCs}=(CA_1, Cons_1),...(CA_n, Cons_n) \end{aligned}$$

(2)

where $CA_i$ represents an attribute i and $Cons_i$ is the delegation constraints set i (if any) that is imposed over CA by the delegator and must be satisfied by the delegatee’s contextual attributes.

3.1 Delegation Policies

Every delegation operation is subject to predefined delegation policies. Delegation policies are rules that restrict the delegation. We represent our delegation policies in a predicate form as follows:

$can\_delegate(s_1, c_1, s_2, c_2, Grant, \mathbf {DCs})$: subject $s_1$ can delegate context $c_1$ to subject $s_2$ if $s_2$’s context satisfies delegation constraints $\mathbf {DCs}$.

$can\_delegate(s_1, c_1, s_2, c_2, Transfer, \mathbf {DCs})$: subject $s_1$ can delegate context $c_1$ to subject $s_2$ if $s_2$’s context (the reference context) satisfies delegation constraints $\mathbf {DCs}$.

$can\_revoke(s_1$, $s_2$, $c_1$, casCaded): subject $s_1$ can revoke the delegated context $c_1$ from $s_2$ if $s_1$ is authorized to do so, i.e., it was the delegator of $c_1$. Note that, the issue of cascading revoke has been studied extensively and we do not address this issue in this paper.

3.2 Delegation Operations

We assume that each delegation operation delegates only one context at a time. If the delegator has multiple contexts (one is the instantiated context and the others may be gained by previous delegations) and (s)he wishes to delegate more than one context to the same delegatee, (s)he can do that in multiple delegation operations. The delegation operation takes the form $delegate(s_1, c_1, s_2, c_2, Grant, \mathbf {Par})$.

Figure 1 shows our approach architecture. Delegator $s_1$ delegates context $c_1$ to delegatee $s_2$. After checking delegation constraints satisfaction as we have illustrated in the previous subsection, the delegation algorithm (see Algorithm 1.) creates a delegation instance with an identifier $del_{id}$. The delegation instance gets part of its values from the delegation request, namely from $\mathbf {Par}$ and $\mathbf {DCs}$. We define the following parameters, MaxDepth is the depth of the delgation. It specifies the number of times the context can be delegated. This value is set by the first delegator ($isSoA=true$, see Fig. 3). The isDelegatable is a Boolean value that determines whether the context is delegatable. If $isDelegatable=false$, then the algorithm automatically sets MaxDepth to 0.

3.3 Delegation Constraints

We represent delegation constraints, denoted as Cons, using Semantic Web Rule Language safe rules (SWRL-safe). SWRL combines OWL ontologies with Horn Logic rules, extending the set of OWL axioms to include Horn-like rules. SWRL rules have the syntax $\mathbf {Antecedent} \mathbf {->} \mathbf {Consequent}$, where each $\mathbf {Antecedent}$ and $\mathbf {Consequent}$ consists of atoms. These atoms can be of the form C(x), P(x, y), sameAs(x, y) or differentFrom(x, y), where C is an OWL class, P is an OWL property, and x, y are either variables, OWL individuals or OWL data values. The $\mathbf {Consequent}$ atom will be true if all atoms in the $\mathbf {Antecedent}$ are true.

For example, suppose that Ann has OnDutyNurse as a reference context as has been shown in Sect. 2.2. Now suppose Ann wants to set delegation constraint on the time contextual attribute before delegating her context (her reference context) to another user, Alice. Alice is a lab analyst and she has the following reference context:

$$\begin{aligned}&OnDutyAnalyst\equiv Context \sqcap (User\sqcap \exists hasID.IDentity\sqcap \exists hasRole\\&.Role\{LabAnalyst\}\sqcap \exists hasGroup.Group\{InShiftAnalysts\}) \sqcap \\&(Environment\{WorkingEnvironment\}\sqcap \exists hasLocation.Location\\&\{Lab\})\sqcap (TElement\{WorkingTime\}\sqcap \exists hasTime\{xsd:dateTime\\&[\ge 2018-04-06T09:00:00,\le 2018-04-06T17:00:00]\})\sqcap \exists hasID.\{0\} \end{aligned}$$

The delegation constraint is $(01:00{pm}\ge {time}\ge {10:00am})$, that is, it can only be delegated between 10:00 am and 01:00 pm. At the time of delegation, Alice has an active context as shown below:

$$\begin{aligned}&OnDutyAnalyst\{Alice\}\equiv Context \sqcap (User\{Alice\}\sqcap \exists hasID.IDentity\{Analyst705\}\\&\sqcap \exists hasRole.Role\{LabAnalyst\}\sqcap \exists hasGroup.Group\{InShifAnalyst\})\sqcap \\&(Environment\{WorkingEnvironment\}\sqcap \exists hasLocation.Location \{Lab\})\\ {}&\sqcap (TElement\{WorkingTime\}\sqcap \exists hasTime.Time\_Instance\{xsd:dateTime\\&[2018-04-06T12:30:11]\})\sqcap \exists hasID.\{0\} \end{aligned}$$

The policy engine checks, then, if the delegation constraints are satisfied or not. The policy engine uses the following SWRL rule to check the time constraint:

$$\begin{aligned}&\qquad TimeCons(?t_3) \wedge notBefore(?t_3,?cons1) \wedge swrlb:greater\\&ThanOrEqual(?cons1,10:00) \wedge notAfter(?t_3,cons2) \wedge swrlb:\\&lessThanOrEqual(?cons2, 01:00) -> satisfied(?t_3), \end{aligned}$$

where $t_3=Time\_Instance$ is extracted from Alice’s active context and is equal to 12 : 30 : 11 pm (on April 6, 2018), and the constraints $cons1=10:00~am$ and $cons2=01:00~pm$ from the delegation constraints set by Ann.

3.4 Processing Delegation Request

Algorithm 1. illustrates the process of context delegation. The approach proceeds as follows:

• The delegator prepares a delegation request and sends it to the policy engine.

• The policy engine parses the request and starts the delegation process.

• The policy engine extracts the delegation constraints, asks the context manager for the delegator’s context, and checks if the delegator has the delegation right.

• If the delegator is authorized, the policy engine asks the context manager for the delegatee’s ($s_2$) context and checks for satisfiability of the delegation.

• If the delegation is satisfiable, the policy engine creates a delegation instance, see Fig. 2, using the delegation ontology and the parameters specified in the delegator’s delegation request.

• The policy engine sends a request to the context manager, accompanied with a delegation identifier, $del_{id}$, to construct a generated context for $s_2$. This context is a copy of the delegator reference context but it is associated with the delegatee.

• The context manager creates the generated context for $s_2$ and associates it with the identifier $del_{id}$ provided by the policy engine with the request.

• The delegatee has two contexts, the instantiated context and the generated context.

Fig. 2.

Delegation ontology.

Fig. 3.

Delegation instance for Bob.

Example. Suppose that we have the following policy rule: $\langle s$ ,$c_1$, “Ann Health Record", Nil, $+$, $``read"\rangle$ and that $c_1$ is given by the DL axiom:

$$\begin{aligned}&\qquad c_1 \equiv User(Alice) \sqcap \exists hasRole(Analyst) \sqcap \exists hasTime(t_1) \sqcap \exists hasLocation\\&(HosptialLab) \sqcap \exists hasActivity(Working) \end{aligned}$$

Assume also that the contextual attribute $t_1$ has a constraint, $\mathbf {Constraint}$, $(08:0~am\le t_1\le 05:0~pm)$ and Alice’s context satisfies this constraint. Assume now Alice intends to delegate her context $c_1$ to Bob from 10:00 am to 01:00 pm and this context is not delegatable. Bob has the following context:

$$\begin{aligned}&\quad c_2 \equiv User(Bob) \sqcap \exists hasRole(Doctor) \sqcap \exists hasTime(t_2) \sqcap \exists \\&hasLocation(Hosptial) \sqcap \exists hasActivity(Working) \end{aligned}$$

The contextual attribute $t_2$ has the constraint $(09:0 AM\le t_2\le 03:0 PM)$. To delegate context $c_1$ to Bob, Alice prepares a delegation request which has the form:

$\langle Alice$,Bob,$Ann's$ Health Record,“delegate", $\langle Time$, $(10:0 AM\le t_3\le 01:0 PM)\rangle \rangle$

Alice sends the delegation request to the policy engine. The policy engine asks the context manager for Bob’s context and checks for satisfiability of the delegation. If the delegation is satisfiable, the policy engine creates a delegation instance $del_1$ with the entities shown in Fig. 3. The new context is similar to Alice’s context except that it is associated with Bob.

4 Conclusion and Future Work

In this paper we have proposed an approach for context delegation for context-based access control policies. The approach provides dynamic and adaptive mechanism for privilege delegation and does not cause any change to the underlying access control policy. The approach presented in this paper is modeled using semantic-based technologies and can be used by existing CBAC systems which do not provide delegation capability. We have implemented the model using real networks. We are working on extending our model by using RESTful web services with Java (Jersey/JAX-RS). The ontologies and some related preliminary coding can be found on (https://github.com/Mouiad1975/Context-Delegation).