Temporal Context-Based Delegation

ABSTRACT

In this paper, we put forward a dynamic delegation model based on a temporal context. Delegation is the process of granting a specific authorization from a user to another user of the same system to carry out some functions on his behalf. Despite the importance of delegation, it is formalized in very little security policies because of its complexity. Indeed delegation provides resiliency and flexibility regarding the management procedure. Our goal consists of redefining delegation for OrBAC using temporal nonmonotonic description logic. OrBAC is an access control model; it provides the mean to specify contextual authorizations, which facilitates modeling delegation features such as temporary delegation, multiple delegation, revocation, etc. The description logic that we use for the re-formalization process is TDL_δε. This logic gives the mean to specify nonmonotonic authorizations and a better representation of the temporal aspects specific to a given delegation. The motivation behind this new representation is to augment the expressivity of the new model to offer a better way to represent and to manage the delegation’s characteristics.

Introduction

Delegation of access rights is a very important function in the business world, this fact forces organizations to rethink their security policies and reevaluate their efficiencies. Organizations establish a set of security policies that regulate how information and resources should be managed in a dynamic environment. To reach these requirements, we present a delegation approach as a process for supporting organizational flexibility in information systems and ensuring delegation of authority in access control system. However, only few works were done in this field (Barka and Sandhu 2000), (Barka and Sandhu 2004), (Barka and Sandhu 2007), (Ben-Ghorbel-Talbi et al. 2010), (Crampton and Khambhammettu 2008), (Ye, Wu, and Fu 2006), (Zidong, Weiqing, and Mansoor 2013). In fact the majority was dedicated to RBAC Model (Sandhu et al. 1996), RBAC is a role-based access control model, the shortcoming of this model is the lack of expressiveness, therefore it is not adequate enough to deal with all delegation requirements such as permanence, level of delegation, revocation, etc. To overcome this expressiveness problem RBAC was extended to OrBAC (Abou El Kalam et al. 2003), by adding new types of roles and permissions. A work managing the delegation in OrBAC was performed (Ben-Ghorbel-Talbi et al. 2010), the authors propose a flexible and complete approach for OrBAC to deal with various security requirements including the delegation characteristics. Delegation, as the term is used in this paper, is motivated by a situation in which users are temporarily unable to perform one or more of their tasks, because they are too busy, or away from their job due to illness or vacation. The user who normally has certain permissions, called the delegator, grants one or more of these permissions (or a role) to a delegatee. It is characterized by being temporary and can be accompanied by a time limit. The problem with OrBac is first-order-based logic. In this paper, our goal is to present a new delegation model. This is performed by a redefinition of the delegation rules of OrBAC. For this purpose, we define a new type of description logic TDL_δε (Bettaz, Boustia, and Mokhtari 2013a) which is temporal and nonmonotonic. This approach provides a better expressivity than the delegation model of OrBAC while maintaining the same complexity. The improved expressivity of our model compared to OrBAC is translated by the fact that it provides the possibility to represent an exception of a context and an exception of an exception of a context, and so on, in the definition of delegation’s permission. In addition, the utilization of the temporal components of TDL_δε (Bettaz, Boustia, and Mokhtari 2013a) allows a better representation of the temporal aspects proper to a given delegation, and also a better management of the delegation characteristics, where time is an important factor. We first extend the access control model OrBAC with temporal elements (Bettaz, Boustia, and Mokhtari 2014). This is done by a re-formalization using the temporal nonmonotonic description logic TDL_δε. The purpose behind this process is to represent a temporal context for the sake of representing temporal authorizations, and thus providing the possibility to deal with temporal access queries. Our paper is based on the technical report (Bettaz, Boustia, and Mokhtari 2013b). We will refer frequently to this report for the details that we will not spread here for space issues. We start in section 2 with a preface divided into two parts: the first part is about access control; in which we talk about OrBAC, AdOrBAC and its delegation process, and the second part is in relation to description logic, where we talk about nonmonotonic description logic and temporal description logic. In section 3 we provide the definition of TDL_δε. In section 4 we present our temporal access control model TDL-OrBAC_δε with its TBox and ABox. In section 5 we propose a new definition of AdOrBAC the administration model of OrBAC and we present our new delegation model. Section 6 is about related works, and we conclude in section 7.

Table 1. Syntax of TDL_δε.

C, D → P	(Atomic concept)
|⊤	(Universal Concept)
|⊥	(Bottom concept)
| ¬P	(Atomic negation)
| C ⊓ D	(Intersection)
| Min u	(u is a real number)
| Max u	(u is a real number)
| ONE-OF{I1,…In}	(Concept in extension)
| R FILLS {I1,…In}	(Subset of value for R)
| R AT-LEAST n	Cardinality for R (minimum)
| R AT-MOST n	Cardinality for R (maximum)
| ∀ R.C	(Universal quantifier)
| δ C	(Concept C by default)
| C^ε	(Exception to the concept C)
| C@X	(Temporal Qualifier)

Preamble

Before proceeding we will need to make a preface about OrBAC with its administration part, and provide a slight state of the art about description logic to better understand the contribution of our work.

Access Control (OrBAC, AdOrBAC and Delegation)

OrBAC is an organization-based access control model (Abou El Kalam et al. 2003). It is an enhancement of RBAC Role-based access control (Sandhu et al. 1996) in which static authorizations are granted to users depending on their Roles. However in some situations, some conditions must be satisfied to activate security rules, these conditions whether temporal, spatial or others were defined in OrBAC as the notion of context (Cuppens and Cuppes-Boulahia 2008), (Cuppens and Miège 2003). In this model, authorizations are granted to users depending on their roles in the organization and also on the context. OrBAC is therefore a dynamic access control model. The formalization of OrBAC is first-order-based logic. For instance, permissions are expressed as follows: Permission (X, Doctor, Consult, MedicalRecord, Emergency). This indicates that the hospital X grants doctors permission to consult any medical record in emergency context.

OrBac was re-formalized using the nonmonotonic description logic JClassic_δε that uses δ (Default) and ε (Exception) in the definition of concepts (Boustia and Mokhtari 2012b), the new model was then called DL–OrBAC_δε, the major goal behind developing this model was to provide the possibility to express authorizations in a context by default and also in a context by exception, this accomplishment enabled to augment the expressivity of the new model and at the same time maintaining a polynomial complexity. In this work we dealt with another type of context, namely the temporal one to extend DL–OrBAC_δε model furthermore to be able to take into consideration temporal authorizations, our model is called TDL–OrBAC_δε (Bettaz, Boustia, and Mokhtari 2014), we performed this by the use of TDL_{δε .}This is presented later in this paper. In fact the temporal context is represented as an argument in the predicate permission inside OrBAC Permission as stated above. The problem with this approach is that first-order logic is semi-decidable, plus the fact that we cannot represent an exception and an exception of an exception for the context, and so on. The other point is that the conjunction or disjunction of contexts; which allows the use of more than one context at once, is used as arguments inside the predicate; this makes the decidability even more complex. AdOrBAC (Cuppens and Miège 2004a) is the administration model for OrBAC. It uses the concept of views to define the administration tasks. The language rules used to define permission to administer the policy is completely similar to the rest of OrBAC. The two administrative views used in AdOrBAC are Role AssignmentView and LicenseView (Ben-Ghorbel-Talbi et al. 2010). They are, respectively, used to manage the security policy and to assign a user to a role. In OrBAC, delegation allows giving specific user privileges without giving this privilege to all people with the same role as him (Ben-Ghorbel-Talbi et al. 2010). The delegation is modeled by the use of the notion of contexts and administrative views as defined in AdOrBAC. Two types of views are denoted: the License–Delegation View to delegate rights (partial delegation), and the Role–Delegation View to delegate roles (total delegation). The management of delegation policy consists of defining which grantor (role or user) have an access to these views and in which context (Ben-Ghorbel-Talbi et al. 2010). The delegation characteristics are Permanence, Monotonicity, Multiple delegation, Level of delegation and Revocation, we consider them in detail in the upcoming sections with their new formalization. In this paper we present the re-formalization of the delegation model of OrBAC with the use of TDL_δε (Bettaz, Boustia, and Mokhtari 2016), this is performed after the presentation of the access control model TDL–OrBAC_δε(Bettaz, Boustia, and Mokhtari 2014).

Description Logics (DLs)

We will use for the formalization of our new delegation model the temporal nonmonotonic description logic TDL_δε that we defined previously (Bettaz, Boustia, and Mokhtari 2013a). Before presenting TDL_δε, we outline first the nonmonotonic description logic and the temporal description logic to show how it emerged.

Nonmonotonic Description Logic

Classical forms of description logics do not permit to represent neither default nor exception facts about concepts. The impossibility of representing this kind of information leaves the knowledge base partially defined. The solution to represent such kind of knowledge is to rely on nonmonotonic reasoning. Many approaches were proposed in the literature: (Baader and Hollunder 1992), (Padgham and Nebel 1993), Padgham and Zhang 1993), (Quantz and Royer 1992). The problem with these approaches is that they use a limited form of default reasoning, where concepts are defined only by using strict properties. Considering the fact that most of the concepts can’t be just defined by the use of strict properties, that will leave the knowledge base inevitably partially defined, consequently the classification process won’t be complete. The approach that overcomes this problem was proposed by (Coupey and Fouqueré 1997). In fact they developed a new nonmonotonic description logic named AL_δε that permitted the introduction of the notion of default and exception in concepts definition: (δ) to represent default facts and (ε) to represent exception facts. This language was improved by the addition of connectors from C-classic which permitted to augment its expressivity and thus make it usable from a practical point of view. This new language was called JClassic_δε (Boustia and Mokhtari 2012a) and renamed here DL_δε. Using this description logic we can define the concept Tree as having by default branches and always having a trunk and roots: Tree ≡δWith–branches ⊓ With–trunk ⊓ With–roots. If we define the concept Scion as being a tree that is by default one-year old and exceptionally has branches we write it: Scion ≡ δOne–year–old ⊓ Tree ⊓ With–branches^ε.

Temporal Description Logic (TDL)

Temporal Logics are designed for representing and reasoning about information qualified in term of time. They have been widely used in several domains such as databases, natural language processing, planning, etc. In the research field on temporal description logic (Artale and Franconi 2000), (Artale and Franconi 2005), (Baader et al. 2008), (Bouzid et al. 2006) two approaches for modeling the notion of time were considered: the modal and the reified temporal logic (Ma and Knight 2001). In modal temporal logic the connectors □ and ◊ represents, respectively, the notion of (always in the future) and (sometimes in the future). The flow of time can be taken from two different angles, we can consider time as a set of points (instances) or as a set of intervals. In (Artale and Franconi 2000), (Artale and Franconi 2005), (Baader et al. 2008), (Bouzid et al. 2006), the different approaches on temporal logic based on points and intervals have been widely spread. Concerning the interval-based approach, many studies were undertaken. Artale and Franconi (Artale and Franconi 2000), (Artale and Franconi 2005) put into evidence a TDL inspired by Schmiedel’s approach (Schmiedel 1990), that they restricted by discarding the □ operator for decidability matters. Example (Artale and And Lutz 1999): ◊(X Y)(Y starts X).(Student@ X ⊓ Bachelor–student @Y). Here we have two intervals X and Y, where X and Y start at the same time but Y is ended before X. So, the described persons are students during the interval X and they are specifically Bachelor students for the initial sub-interval Y of X. TDL_δε was modeled with the modal approach. The aim behind this orientation is that the modal approach uses the notion of connectors for time representation, as it is the case in nonmonotonic logic where connectors are used to represent the notion of default and exception, TDL_δεis based on intervals for the purpose of defining the specific interval at which a concept is valid. The temporal part TL that we used for the conception of TDL_δε is the one used in the TDL defined by Artale and Franconi (Artale and Franconi 2000), (Artale and Franconi 2005).

TDL_δε

For the purpose of our work, we will use TDL_δε(Bettaz, Boustia, and Mokhtari 2013a), to define our delegation model. TDL_δε is a temporal nonmonotonic description logic. We developed this DL to permit a better management of the time aspect in a variety of domains such as reasoning about actions and plans, enhancing natural languages comprehension and also allowing the improvement of access control. TDL_δε allows representing temporal concepts while having default knowledge. Differing from the existing temporal description logics where temporal components are added to classical description logics. We present in this section the interpretation of the connectors and constants from TDL_δε, and show how our approach augments the expressivity of the model while maintaining the same complexity; it actually permits to represent an exception and an exception of an exception for the context, which is not possible in OrBAC, and the use of temporal aspects allows a better representation of the delegation parameters. We then present in the upcoming sections TDL–OrBAC_δεand its delegation model. We will just describe the part of the syntax in Table 1 (Bettaz, Boustia, and Mokhtari 2013a) of TDL_δε that we will be needing for our work, it consists of: a set of atomic concepts P and atomic roles R, the two constants ⊤ (Top) and ⊥ (Bottom) that represents, respectively, the universal and the bottom concept, a set of individuals I called ‘classic individuals’, the concepts C and D, the unary connectives δ (Default) and ε (Exception), the binary conjunction ⊓, the quantifier ∀ that enables universal quantification on role values, and the temporal qualifier @ to represent the interval ‘X’ at which a concept C applies, u is a real number, n is an integer, Ii Are ‘classic individuals’.

Using this description logic, we can represent temporal aspects, the properties: default, exception, exception of exception, and so on. For instance, in the case of access control in the medical domain, we can define the concept Doctor as being a Staff member that Exercises officially his function by default and that has the right to Access the medical database records of patients during Working hours.

$\begin{array}{rl}& Doctor\equiv Staff-Member\sqcap \delta Exercise\sqcap Access-Mdb\\ & -Records@\left(workingHours\right).\end{array}$

Now we can define the concept Resident as a Doctor that exceptionally doesn’t Exercise officially since he is still a student: $Resident\equiv Doctor\sqcap Exercis{e}^{\epsilon }$

Here the concept Resident will inherit the property Staff Member and the right to Access the medical database records during working hours but not the property Exercise since it is an exception for the concept Resident. In the case where we have a context of Emergency another exception on the concept Exercise is applied for Resident: $Resident\sqcap Emergency\equiv Doctor\sqcap {\left(Exercis{e}^{\epsilon }\right)}^{\epsilon }$

In this case, the exception over an exception omits the exception, therefore in an emergency context Resident has the right to Exercise. We just point here to the fact that OrBAC does not allow the representation of an exception of exception regarding a concept definition.

The specificity of this logic is the use of an algebraic-based semantics (Bettaz, Boustia, and Mokhtari 2013b) unlike the classical practice where the semantics is based rather on a first-order logic interpretation. The deductive study is realized following this algebraic framework, which allows endowing TDL_δε with an intentional semantic and it includes new algorithms of subsumption calculation and inheritance that are both correct, complete and of temporal and special polynomial complexity. In (Bettaz, Boustia, and Mokhtari 2013b) all the algorithms are defined with proves of their tractability.

TDL–OrBAC_δε

Before coming to our initial goal which is about the conception of a dynamic delegation model based on a temporal context, we present in this section TDL–OrBAC_δε, which is a re-formalization of OrBAC with TDL_δε, in fact we upgrade the dynamic access control model DL–OrBAC_δε with the temporal context (we remind here that DL–OrBAC_δε is a redefinition of OrBAC with the use of the nonmonotonic description logic DL_δε), to this end we add the temporal aspect to the TBox, ABox and to the definition of the different inference mechanisms namely subsumption and inheritance.

TBox for TDL–OrBAC_δε

The alphabet of TDL–OrBAC_δε knowledge base requires the addition of the temporal context among the axiom for permission definition of DL–OrBAC_δε. The Axioms for Role Attribution, View Definition, Activity Definition are defined in (Boustia and Mokhtari 2012a), (Boustia and Mokhtari 2012b).

Axiom for Permission Attribution

This axiom defines the relation between Role, Activity, View, inside an organization. Permission by default is granted to a role R in an organization Or on a view V to perform an activity Av, it is expressed as follows:

$\begin{array}{c}\delta Permission⊑PermissionAv.Activity\sqcap PermissionR.Role\sqcap PermissionV\\ .View\sqcap PermissionOr.Organization\end{array}$

Here δ represents a context by default, PermissionAv, PermissionR, PermissionV, PermissionOr are binary relationships that link respectively the concepts Activity, Role, View and Organization to Permission.

A temporal permission is granted to a role R in an organization Or on a view V to perform an activity Av for a time interval during the day or for a given day during the week, it is expressed as follows:

$\begin{array}{c}Permission@i⊑PermissionAv.Activity\sqcap PermissionR.Role\sqcap \\ PermissionV.View\sqcap PermissionOr.Organization\end{array}$

In the example below, in the hospital, H1 physicians have the right to consult their E-mails during the temporal interval Rest hours.

$\begin{array}{rl}& Permission\left(P1\right)@Rest-hours⊑PermissionAv.Activity\left(Consult\right)\sqcap \\ & PermissionR.Role\left(Physician\right)\sqcap PermissionV.View\left(E-mail\right)\sqcap \\ & PermissionOr.Organization\left(H1\right).\end{array}$

Hierarchy definition axiom for roles and Permission axiom are the same as for DL–OrBAC_δε(Boustia and Mokhtari 2012a), (Boustia and Mokhtari 2012b).

Definition of Rules of Security

We add the following rules on DL–OrBAC_δε(Boustia and Mokhtari 2012a), (Boustia and Mokhtari 2012b) rules:

$\delta Is-permitted@i⊑Employ\sqcap Use\sqcap Consider\sqcap \delta Permission@i$

-If a subject S is employed by organization Or in a role R(Employ), and if there is a relation between action Ac and activity Av(Consider), and if there is a relation between an object O and a view V(Use), and if we have by default a temporal permission relation between role R, activity Av and a view V in an organization Or (δPermission@i), we deduce that a subject S is by default permitted to perform action Ac on object O at the temporal interval i (δIs-permitted@i), and because Is-permitted @i ⊑ δIs-permitted @i (a temporal concrete permission can be deduced from a temporal default permission), we can finally say that a subject S is permitted to perform an action Ac on object O at the temporal interval i.

$Is-permitte{d}^{\epsilon }@i⊑Employ\sqcap Use\sqcap Consider\sqcap Permissio{n}^{\epsilon }@i$

-By cons, if we have an exception on a temporal permission concept wrote Permission^ε@i, we say that we have an exception on a temporal concept Is-permitted@i wrote Is-permitted^ε@i, and because Is-permitted @i ⋢ Is-permitted^ε@i (a temporal concrete permission cannot be deduced from a temporal exceptional permission), we deduce that subject S is prohibited to perform an action Ac on object O at that time period.

The ABox for TDL–OrBAC_δε

The ABox of TDL–OrBAC_δε knowledge base contains seven catalogs of axioms as for DL–OrBAC_δε(Boustia and Mokhtari 2012a), (Boustia and Mokhtari 2012b): Organization assertion’s axiom, Subject assertion’s axiom, Object assertion’s axiom, View assertion’s axiom, Role assertion’s axiom, Action assertion’s axiom and Activity assertion’s axiom. It contains statements about individuals. We could have many ABoxes for one TBox depending on the applications.

Inference of Authorization

TDL_δε is conceptualized with a temporal nonmonotonic description logic that employs defaults, exceptions and temporal connectors used to deduce authorizations depending on the context. The subsumption and the inheritance algorithms that are the essence of inference, described in (Bettaz, Boustia, and Mokhtari 2013b) are both proved to be of a polynomial complexity. This allows us to deduce authorizations, thus once the TBox defined as described above, and given an ABox with a hierarchy of roles, we can give a response to each access request whether positive or negative.

Delegation Using TDL_δε

In this section, we come up to our major goal; redefining delegation for OrBAC using temporal nonmonotonic description logic. For this purpose, we initially redefine the administration model AdOrBAC (Cuppens and Miège 2004a). We rewrite the rules for License and Role – Assignment Views using TDL_δε, the two permissions are represented as follows: The license View is rewritten as follows:

$\delta Permission⊑UseL.License\sqcap GranteeL.Subject\sqcap PrivilegeL.Action\sqcap TargetL.Object.$

δ represents the default context, UseL, GranteeL, PrivilegeL and TargeL are binary relations between the concept Permission and, respectively, the concepts License, Subject, Action and Object, which are all subsumed by ⊤ (the most general concept). In this view by default an authorized user assigns permission to a role or to a user.

The Role assignment View is rewritten as follows:

$\begin{array}{c}Empower⊑UseRA.Role-Assignment\sqcap AssigneeRA.Subject\\ \sqcap AssignmentRA.Role.\end{array}$

UseRA, AssigneeRA and AssignmentRA are binary relations between the concept Empower and concepts Role–Assignment, Subject and Role, all subsumed by ⊤. This axiom enables to assign a user to a role.

We present now our new delegation model (Bettaz, Boustia, and Mokhtari 2016). This approach proposes a redefinition of the delegation model of OrBAC (Ben-Ghorbel-Talbi et al. 2010) formalized previously with predicates from first-order logic. Our redefinition is performed with the use of the temporal nonmonotonic description logic TDL_δε. The utilization of the temporal components of TDL_δε (Bettaz, Boustia, and Mokhtari 2013a) allows a better representation of the temporal aspects proper to a given delegation, and also a better management of the delegation characteristics, where time is an important factor. We illustrate with examples using the temporal components proper to this logic and show how we can represent an exception and an exception of an exception while using delegation permission. First, we need to rewrite the axioms of the two types of delegation views, namely, the License–Delegation View for partial delegation, which permits to delegate rights, and the Role–Delegation View for total delegation, that allows delegating Roles, these views are redefined as follows:

$\begin{array}{c}\delta Permission⊑UseL.License-Delegation\sqcap GranteeL.Grantor\\ \sqcap PrivilegeL.Action\sqcap TargetL.Object.\end{array}$

Here by default, a grantor has the right to delegate permission to a grantee.

$\begin{array}{c}Empower⊑UseRD.Role-Delegation\sqcap AssigneeRD.Grantor\\ \sqcap AssignmentRD.Role.\end{array}$

The above axiom allows the grantor to delegate a Role to a grantee. Now for the process of defining which grantor has an access to these views and in which context, we rewrite the permission axioms that permit this action as follows:

$\begin{array}{c}\delta Permission⊑PermissionGr.Grantor\sqcap PermissionDL.Delegate\\ \sqcap PermissionLDL.License-Delegation.\end{array}$

$\begin{array}{c}\delta Permission⊑PermissionGr.Grantor\sqcap PermissionDL.Delegate\\ \sqcap PermissionRDL.Role-Delegation.\end{array}$

For example, Doctor James decides to delegate permission to nurse Alice to consult the records of his patients. Before assigning Role doctor the permission to delegate this right. The administrator creates first the Record–Delegation View and then he grants the Role doctor the permission to delegate licenses in the formerly defined view, we model these two axioms as follows: Record–Delegation View derived from License – Delegation View:

$\begin{array}{c}Use⊑UseL.License-Delegation\sqcap PrivilegeL.Consult\\ \sqcap TargetL.Patient-Records.\end{array}$

The permission that allows the Role doctor to delegate licenses in Record–Delegation View is:

$\begin{array}{c}\delta Permission⊑PermissionD.Doctor\sqcap PermissionDL.Delegate\\ \sqcap PermissionRCDL.Record-Delegation.\end{array}$

Now by default James can delegate to Alice a permission to consult his patient’s medical records (James–Patient–Records); that is a sub-license of Patient–Records as follows:

$\begin{array}{c}\delta Permission⊑PermissionA.Alice\sqcap PermissionCL.Consult\sqcap \\ PermissionJPR.James-Patient-Records.\end{array}$

We notice here that if the grantor has the permission to delegate a license L then he also has the permission to delegate its sub license L’.

Using the temporal nonmonotonic description logic TDL_δε we can consider the above delegation to be valid at a given temporal context for example Working–Hours, to say that James delegates to Alice the above permission only during the working hours. We can represent this delegation using the @operator:

$\begin{array}{c}\delta Permission@\left(Working-Hours\right)⊑PermissionA.Alice\sqcap \\ PermissionCL.Consult\sqcap PermissionJMR.James-Patient-Records.\end{array}$

Now if we put an exception on this permission, let say in the case where medical records are being updated, than exceptionally Alice won’t be delegated this right, we define it as follows using exception operator (ε):

$\begin{array}{rl}& \delta Permission@{\left(Working-Hours\right)}^{\epsilon }⊑PermissionA.Alice\\ & \sqcap PermissionCL.Consult\sqcap PermissionJMR.James-Patient-Records.\end{array}$

We can also define an exception to the exception of the context on the delegation using TDL_δε.

For instance, we consider the exception (Emergency) and we define an exception on the above permission:

$\begin{array}{rl}& \delta Permission@{\left(Working-Hours\right)}^{\epsilon }{)}^{\epsilon }⊑PermissionA.Alice\sqcap PermissionCL.\\ & Consult\sqcap PermissionJMR.James-Patient-Records.\end{array}$

Here the exception on the exception will omit the exception, so it brings us to the permission by default where Alice is delegated the right to consult James–Patient–Records, in the case of the exception context Record–Update alongside with the exception context Emergency. We should now redefine the axiom that allows us to verify if a given license L is a sub–licenseof L’, we propose the following notation:

$\begin{array}{rl}& Sub-License⊑TargetL.T\sqcap Target{L}^{\prime }.T^{\prime }\sqcap Sub-TargetT.T^{\prime }\sqcap PrivilegeL.P\\ & \sqcap Privilege{L}^{\prime }.P^{\prime }\sqcap Sub-PrivilegeP.P^{\prime }\sqcap ContextL.C\sqcap Context{L}^{\prime }.C^{\prime }\sqcap Sub-C.C^{\prime }.\end{array}$

O is a Sub–Target of O’, if there are two views and O is a sub-view of O’, or if O is an Object used in the view O’, or if they are equal, we redefined as follows: Sub–Target ⊑ Sub–ViewO.O’⊔ UseO.O’⊔ O = O’.

The same notation is used to define Sub–Privilege and Sub–Context.

To verify the equivalence of the two licenses L and L’, we use the following notation:

$Equivalent-Licenses⊑Sub-LicenseL.L^{\prime }\sqcap Sub-License{L}^{\prime }.L.$

We present in the following the re-formalization of the characteristics of delegation using TDL_δε.

a) Permanence: Delegation can be determined in term of its durability, in fact we can specify the time period at which the delegation is valid, this is referred to as temporal context, we can define such delegations by using the temporal components of TDL_δε, in our above example a second license can be created in which doctor James delegates a permission to nurse Alice to consult his patients medical records for a specific period of time, let say during his rest–hours, we will use here the @ operator to append this permission to the time interval Rest–Hours, this is formulated as follows:

$\begin{array}{c}Permission@\left(Rest-Hours\right)⊑PermissionA.Alice\sqcap \\ PermissionCL.Consult\sqcap PermissionJPR.James-Patient-Records.\end{array}$

This delegated permission is valid only during James’ rest hours.

We put into evidence the following definition:

Postulate 1. Each exception of a temporary delegation is a permanent delegation the inverse is also true:

$Temporary-Delegatio{n}^{\epsilon }⊑\delta Permanent-Delegation$

$Permanent-Delegatio{n}^{\epsilon }⊑\delta Temporary-Delegation$

For example, we consider the exception of the context Rest–Hours to be Working–Hours:

$Permission@{\left(Rest-Hours\right)}^{\epsilon }⊑\delta Permission@\left(Working-Hours\right)$

According to our example, we put an exception on the permission delegated to Alice, that states that she has the right to consult James–Patient–Records records during James Rest–Hours, the excepted permission will be (Alice has the right to consult James–Patient–Records during Working Hours), hence Alice has a permission to consult the records the whole time during working hours, which expresses, in this case, the permanence of the permission.

b) Monotonicity: In the case of a monotonic delegation, the grantor preserves the delegated permission; this is the case of the examples cited previously. However to represent a nonmonotonic delegation, where the grantor actually loses the permission he delegates, a License – Transfer View is created, this view is a sub–view of License–Delegation View, thus inserting an object in this view will create a permission to the grantee and a prohibition to the grantor, associated with a highest priority Max. We remodel the License–Transfer View using the temporal operator @ from TDL_δε as follows: Use ⊑ UseL.License–Transfer.

$\begin{array}{c}Prohibition@\left(Delegation-Duration\right)⊑UseL.License-Transfer\\ \sqcap GrantorL.Subject\sqcap PrivilegeL.Action\sqcap TargetL.Object.\end{array}$

The grantor loses this permission only during the period of delegation (Delegation Duration), therefore the temporal context of the prohibition is the same one as the temporal context of the delegated permission.

We propose the following definition:

Postulate 2. Each exception of a nonmonotonic delegation is a monotonic delegation the inverse is also true: $Non-Monotonic-Delegatio{n}^{\epsilon }⊑\delta Monotonic-Delegation.$

$Monotonic-Delegatio{n}^{\epsilon }⊑\delta Non-Monotonic-Delegation.$

For example in the case of a Non–monotonic delegation, we can put an exception on James delegation; in which he grants the permission to Alice to consult his patient medical records, and loses at the same time this right, the exception on this delegation bring us to the monotonic state, in which James preserves his right to consult his patients medical records during the delegation.

c) Multiple Delegation: A grantor may delegate the same right to a group of people at any given time; this is referred to as multiple delegation. The administrator fixes the number Nm of grantees by using the context Max–Multi–Delegation. The permission that represents this delegation is redefined using TDL_δε as follows: $\delta Permission⊑PermissionS.Subject\sqcap PermissionD.Delegate\sqcap PermissionV.View\sqcap$ $PermissionM.Max-Multi-Delegation.$ $$

We redefine in what follows the context Max–Multi–Delegation, for this purpose we count the delegation number concerning the same grantor and the same right:

$Hold⊑UseL.License-Delegation\sqcap GrantorL.S\sqcap Count{L}^{\prime }.C.$

$Count⊑Use{L}^{\prime }.License-Delegation\sqcap Granto{L}^{\prime }.S\sqcap Equivalent-LicenseL.L^{\prime }\sqcap N{m}^{\prime }\le Nm.$

L and L’ are equivalent; hence they represent the same license.

$\begin{array}{rl}& \mathrm{E}\mathrm{x}\mathrm{a}\mathrm{m}\mathrm{p}\mathrm{l}\mathrm{e}:\delta Permission⊑PermissionJ.James\sqcap PermissionDL.Delegate\\ & \sqcap PermissionRCDL.Record-Delegation\sqcap PermissionM.\\ & Max-Multi-Delegation=1\end{array}$

In this example the context Max–Multi–Delegation = 1, which refers to simple delegation, therefore James can delegate the right to consult the medical records of his patients only once. In the case where the context Max–Multi–Delegation is not used, it follows that the grantor can grant an unlimited number of licenses. Now if we put an exception on the above permission it becomes by default a multiple delegation. We can hence state the following definition:

Postulate 3. Each exception on a simple delegation is a multiple delegation, the inverse is also true.

$Simple-Delegatio{n}^{\epsilon }⊑\delta Multiple-Delegation.$

$Multiple-Delegatio{n}^{\epsilon }⊑\delta Simple-Delegation.$

d) Level of Delegation: The level of delegation feature permits to identify if a given delegation can be further delegated and how often. The Grant–Option–License View was created for this purpose; we redefine it using TDL_δε as follows:

$\delta Permission⊑UseL.Grant-Option-License\sqcap GranteeL.U\sqcap TargetL.License.$

The context Valid–Level is redefined as follows:

$\begin{array}{rl}& Hold⊑Use{L}^{\prime }.Grant-Option-License\sqcap Sub-License{L}^{\prime }.L\sqcap \\ & Grantor{L}^{\prime }.U\sqcap LevelL.V\sqcap Level{L}^{\prime }.V^{\prime }\sqcap V^{\prime }<V.\end{array}$

Level represents the number of authorized delegation steps.

According to our example if we consider the fact that James grants Alice the permission to delegate his license L1 (Consult his patient’s medical records) with delegation level equals to 3. For this reason, James generates another license L3 in the Grant–Option–License View with the following characteristics: Grantee: Alice, Privilege: Delegate, Target: L1, Level: 3, Context: Nominal. This corresponds to the following rule:

$\begin{array}{c}\delta Permission⊑PermissionA.Alice\sqcap PermissionD.Delegate\\ \sqcap PermissionL.L1\sqcap PermissionV.Valid-Level.\end{array}$

In this permission by default, Alice can delegate the license L1 or a sub–license of L1 using the context Valid–Level. This means also that she can generate another license L4, to grant another user the permission to delegate the license L1. In this case, the delegation level of L4 must be lower than 3, given that the delegation level of L3 is equal to 3. The grantor can also limit the scope of the delegation by adding another context let say a temporal one. For instance, James can specify in the delegation context that Alice can grant another user to delegate L1, only during the temporal interval Working–Hours. We model this permission using as follows:

$\begin{array}{rl}& \delta Permission@\left(Working-Hour\right)⊑PermissionA.Alice\sqcap PermissionD.Delegate\\ & \sqcap PermissionL.L1\sqcap PermissionV.Valid-Level.\end{array}$

This example states that by default Alice can delegate the license L1 that she receives from James, but the delegated license will be valid only during the temporal context Working–Hours.

e) Revocation: Revocation (Ben-Ghorbel-Talbi et al. 2008) deals with the process of retrieving the delegated license or role. In the following, we redefine the revocation’s properties by using the temporal nonmonotonic description logic TDL_δε.

Grant Dependency

Revocation can be either Grant–Dependent (GD) or Grant–Independent (GID). In the situation of Grant–Dependent revocation, only the Grantor has the right to revoke the delegated license or role. However, in the case of Grant–Independent any member of the sponsoring role has the right to revoke the grantee. These two situations are represented with the following permissions by default while using either the context GD or GID.

$\begin{array}{c}\delta Permission⊑PermissionS.Subject\sqcap PermissionR.Revoke\sqcap \\ PermissionLD.License-Delegation\sqcap PermissionD.GD.\end{array}$

$\begin{array}{c}\delta Permission⊑PermissionS.Subject\sqcap PermissionR.Revoke\sqcap \\ PermissionLD.License-Delegation\sqcap PermissionID.GID.\end{array}$

The two contexts GD and GID are redefined as follows:

$Hold⊑UseL.License-Delegation\sqcap GrantorL.User.$

$\begin{array}{c}Hold⊑UseL.License-Delegation\sqcap GrantorL.GR\sqcap \\ EmpowerGR.Role\sqcap EmpowerUser.Role.\end{array}$

The two contexts GD and GID are applicable in the case of license revocation, to revoke a role a similar approach is used to define the contexts GDR and GIDR.

Example: James can revoke the delegation from Alice duringhis Rest-Hours as follows: δPermission@(Rest–Hours) ⊑ PermissionA.Alice ⊓ PermissionR.Revoke ⊓ PermissionJPR.James–Patient–Records ⊓ PermissionD.GD.

This is a grant dependent revocation specified by GD which means that only James is allowed to revoke this permission from Alice.

Cascading Revocation

The delegation chain produced from the process of performing multi-step delegation should be indirectly revoked. This operation is possible by the use of contextual license, where the delegation of right is valid only in case the grantor still has this right. Using TDL_δε description logic, we redefine the View Cascading–Delegation, which is a sub–view of License–Delegation View:

$\begin{array}{c}\delta Permission⊑UseL.Cascading-Delegation\sqcap GranteeL.Subject\sqcap \\ GrantorL.Gr\sqcap PrivilegeL.Action\sqcap TargetL.Objet\sqcap ContextL.C\end{array}$

Inserting an object in this view will create permission with an additional context (Valid–Delegation context) which verifies if the grantor still has his right. This context is redefined as: $Hold⊑Is-PermittedU.User\sqcap Is-PermittedO.Object\sqcap Is-PermittedA.Action.$

We notice that the delegated permission is valid only if the delegation chain is maintained.

Related Works

The proposed delegation models in the literature are mostly dedicated to RBAC (Barka and Sandhu 2000), (Barka and Sandhu 2004), (Crampton and Khambhammettu 2008), (Zidong, Weiqing, and Mansoor 2013). RBAC does not deal with the notion of context, in fact authorizations are related with appropriate roles and users are assigned to these roles. This kind of representation allows only strict rules representation; it is not flexible to deal with different kinds of situations, such as exceptions or temporal factors. Indeed this model lacks expressivity to represent security rules including delegation and its characteristics. It actually doesn’t comprehend the necessary components that enable the representation of those delegation features as permanence, multiple delegation, revocation, etc. OrBAC (Ben-Ghorbel-Talbi et al. 2010) proposes a more complete delegation model than the previously defined models in the literature. It overcomes the problem of RBAC by extending its delegation model with other components, such as new types of roles, permissions, relations, and the notion of context. This model is also self-administrated and offers facilities, such as multi-granular license, contextual license, use of views, etc. However, OrBAC uses first-order logic for knowledge representation, where the context is represented as an argument inside a unary predicate. This kind of formulation does not allow the representation of more than one context at a time, thus conjunction of contexts or exception to a context cannot be formalized. We proposed in this paper a redefinition of the delegation rules of OrBAC, with the use of the temporal nonmonotonic description logic TDL_δε. This process permits to augment the expressivity of the model. Actually, it allows representing the cases where we can have an exception of an exception of a given context while delegating permission.etc. This operation is not possible with OrBAC. It provides also a simpler way to represent the temporal aspects of delegation, by using the temporal components of TDL_δε. Thus, our approach is more flexible and easier to deal with than the delegation model of OrBAC. Our delegation model reposes on description logic. Thus, from the complexity point of view, it maintains a polynomial complexity, given the fact that OrBAC is modeled with first-order logic, and that description logic is a subset of it.

Conclusion

Providing access control mechanisms in information systems to support dynamic delegation of authority is not a trivial task to model and engineer. In this paper, we reached our main goal; which is presenting a dynamic delegation model based on temporal context. To this end we redefine the delegation model of OrBAC with the use of temporal nonmonotonic description logic, to specify delegation policies automatically. We named this description logic TDL_δε. The motivation of this work is based on a real-world process, where authorizations may change during execution. Delegation policies may change according to specific contexts. The steps that we undertook to reach our goal are summarized in the following points:

-We studied the organization-based access control model OrBAC (Abou El Kalam et al. 2003), which relies on the notion of context to grant authorizations. OrBAC was formalized using first-order logic, it was re-formalized to DL–OrBAC_δε using nonmonotonic description logic (Boustia and Mokhtari 2012b). This new representation provides the possibility to express authorizations in a context by default and also in a context by exception; therefore it permitted to augment the expressivity of the new model and at the same time maintaining a polynomial complexity.

-Our purpose is to deal with the temporal context to express authorizations and manage delegation dynamically. To this end, we developed a new type of description logic, which is temporal and nonmonotonic at the same time (Bettaz, Boustia, and Mokhtari 2013a). This description logic that we named here TDL_δε. is an extension of the nonmonotonic description logic DL_δε (Boustia and Mokhtari 2012a) with temporal components. The benefit that we can get from using TDL_δε is not restricted to improve access control; indeed it can be used for a better management of the time aspect in a variety of domains, such as reasoning about actions and plans and enhancing natural languages comprehension.

-We redefined the access control model OrBAC and its administration part AdOrBAC (Cuppens and Miège 2004a) with the use of the temporal nonmonotonic description logic TDL_δε; we rewrite the permission axioms and security rules for DL–OrBAC_δε by adding the temporal context.

-We demonstrated in (Bettaz, Boustia, and Mokhtari 2013b) that our approach augments the expressivity of the new model while maintaining a polynomial complexity. Indeed our model can take into account authorizations according to temporal context, and at the same time deal with an exception as well as an exception of exception.

-Finally, we come up to our primary objective; defining a dynamic delegation model, where delegation rules may change during execution, according to temporal contexts. For this purpose, we rewrite the delegation rules of OrBAC (Ben-Ghorbel-Talbi et al. 2010) with TDL_δε, by taking into account delegation characteristics where time is an important factor. Our approach provides an enhanced expressivity comparing to the delegation model of OrBAC, meanwhile it maintains a same complexity. In fact, it provides the possibility to represent an exception of a context and an exception of an exception of a context, and so on, in the definition of delegation’s permission. In addition, it allows a better representation of the temporal aspects proper to a given delegation, and also a better management of the delegation characteristics.

An interesting topic for future research is to extend our system to take into account other type of context such as spatial context, where authorizations are validated according to specific access area, for example, the medical system of a given hospital can be accessed only from a station that is located in a specific area inside the hospital, such as administration office, spatial description logics (Aiello, Pratt-Hartmann, and Van Benthem 2007) might be appropriate to deal with this issue.