Monotonic and Non-monotonic Context Delegation

Mouiad AL-Wahah and Csilla Farkas

College of Engineering and Computing, University of South Carolina, 301 Main St, Columbia, SC, U.S.A.

Keywords:

Description Logic, Monotonic, Non-monotonic, OWL Ontology, Context Delegation, Access Control,

Authorization.

Abstract:

Delegating access privileges is a common practice of access control mechanisms. Delegation is usually used

for distributing responsibilities of task management among entities. Delegation comes in two forms, GRANT

and TRANSFER. In GRANT delegation, a successful delegation operation allows delegated privileges to be

available to both the delegator and delegatee. In TRANSFER delegation, delegated privileges are no longer

available to the delegator. Although several delegation approaches have been proposed, current models do not

consider the issue of context delegation in context-based access control policies. We present two ontology-

based context delegation approaches. Monotonic context delegation, which adopts GRANT version of del-

egation, and non-monotonic for TRANSFER version of delegation. The approach presented here provides

a dynamic and adaptive privilege delegation for access control policies. We employ Description logic (DL)

and Logic Programming (LP) technologies for modeling contexts, delegation and CBAC privileges. We have

designed three lightweight Web Ontology Language (OWL) ontologies, CTX, CBAC, and DEL, for context,

Context-Based Access Control (CBAC), and delegation, respectively. We show that semantic-based techniques

can be used to support adaptive and dynamic context delegation for CBAC policies. We provide the formal

framework of the approaches and show that they are sound, consistent and preserve least-privilege principle.

1 INTRODUCTION

In dynamic environments like pervasive systems,

ubiquitous computing, ambient intelligence, and

more recently, Internet of Things (IoT), there is an as-

sociation between a system and its environment and

the system always adapts to its ever-changing envi-

ronment. This situation makes the Context-Based Ac-

cess Control (CBAC) the method of choice for such

environments.

The fundamental idea behind delegation is that

some active entity in a system, the delegator, dele-

gates privileges to another active entity, the delega-

tee, to carry out some functions on behalf of the for-

mer. Delegation comes in two forms (Crampton and

Khambhammettu, 2008), GRANT and TRANSFER.

In GRANT delegation, a successful delegation oper-

ation allows delegated permissions to be available to

both the delegator and delegatee. In TRANSFER del-

egation, the delegated permissions are no longer avail-

able to the delegator.

There is a signiﬁcant previous work on Context-

Based Access Control (CBAC) (Bhatti et al., 2005;

Toninelli et al., 2006; Kulkarni and Tripathi, 2008;

Shen and Cheng, 2011; Corradi et al., 2004; Trnka

and Cerny, 2016; Kagal et al., 2006; Gusmeroli et al.,

2013). However, support to delegate CBAC privi-

leges is limited. For example, approaches described

in (Bhatti et al., 2005; Toninelli et al., 2006; Kulkarni

and Tripathi, 2008; Shen and Cheng, 2011; Bellav-

ista and Montanari, 2017) do not provide any delega-

tion services. Most of the existing delegation meth-

ods are based on traditional access control models,

such as Role-Based Access Control (RBAC) models

(Trnka and Cerny, 2016; Zhang et al., 2001). Methods

such as attribute-based delegation (Servos and Os-

born, 2016; Servos and Osborn, 2017) and capability-

based delegation (Kagal et al., 2006; Gusmeroli et al.,

2013) requires that the underlying access control pol-

icy is changed. Moreover, none of the methods ad-

dress the issue of context delegation when the ac-

cess authorization is a context-dependent. Further-

more, only a few approaches have extensively stud-

ied TRANSFER delegation due to the complexity of

enforcing TRANSFER delegation mechanisms. This

paper extends the work presented by the same authors

in (AL-Wahah and Farkas, 2018).

The main contributions of our approach are: 1)

Our method provides dynamic and adaptive context

Al-Wahah, M. and Farkas, C.

Monotonic and Non-monotonic Context Delegation.

DOI: 10.5220/0007400904490460

In Proceedings of the 5th International Conference on Information Systems Security and Privacy (ICISSP 2019), pages 449-460

ISBN: 978-989-758-359-9

449

delegation that does not modify the original access

control policy in case of monotonic delegation. For

non-monotonic delegation, the approach incurs only

selective changes to the underlying access control pol-

icy. Dynamic adaptability is provided through pol-

icy adjustment operations that keep the policy rules

on update with the latest context changes. Adap-

tation is needed, in our approach, in situations: (i)

When context of the requester/resource/environment

changes, that change should be reﬂected on the access

control policy. (ii) In TRANSFER delegation, the

delegated permissions have to be moved (temporar-

ily or permanently) from the delegator to the delega-

tee and this needs the policy to be updated to cope

with this situation. 2) Our approach can be adopted

by existing CBAC systems which do not provide del-

egation services. 3) Our semantic-based delegation

model supports capabilities such as checking the ac-

cess control and delegation policies for conﬂict and

consistency, explaining inferences and helping to in-

stantiate and validate the variables in dynamic envi-

ronments. 4) We provide the formal proof that context

delegation and its delegation-supported authorization

enforcement are sound, consistent and preserve the

least privilege principle.

The rest of this paper is organized as follows: In

section 2, we present the context-based access control

system modeling. Section 3 is dedicated to semantic-

based context delegation. In section 4, we present

the properties of our approach and the proofs of these

properties, and ﬁnally in section 5, we conclude with

suggestions for future work.

2 CBAC SYSTEM MODELING

In this section, we give a brief overview of the

Context-Based access control. ”Context” has been

deﬁned by Dey et al. (Dey et al., 2001) as ”any infor-

mation 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 re-

source owner) speciﬁes a set of contexts and deﬁnes

for each context c the set of applicable permissions.

When an entity (a user) operates under a certain con-

text, (s)he acquires the set of permissions (if any) that

are associated with the active context. When (s)he

changes the active context, the previous permissions

are automatically revoked, and the new permissions

acquired (Corradi et al., 2004). Hence, Context plays

the role of a bridge between the requester and the ac-

cess permissions. If a requester has a context c at the

time in which the request is made and that c is as-

sociated with permission p, then (s)he can access a

resource using permission p.

2.1 Context-based Access Control

Model

Access requests are evaluated based on the contexts

associated with the subject and the requested. The re-

quest 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.

Deﬁnition 1. (Access Control Policy (ACP) Rules.)

Access control policy rule is given as a 6-

tuple hs, sc,r,rc, p,aci, where s ∈ S ub ject, r ∈

Resource, sc, rc ∈ Context, where sc is the

subject’s context and rc is the resource context,

p ∈ Permission={”Deny”,”Permit”}, and ac ∈

Action={read, write,delegate,revoke}. Each rule is

instantiated by an access request, using the model on-

tologies and rules, and is evaluated at runtime to reach

a decision.

Deﬁnition 2. (Access Request (AR).) An Access re-

quest is given as a triple hs, r,aci, where s ∈ Sub j ect,

r ∈ Resource, ac ∈ Action.

For example, an access request denoted as ar =

hs,r, ”read”i, represents the case when subject s is re-

questing 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 con-

texts of s and r are sc and rc, respectively. If using the

contexts sc and rc, the policy engine can derive a per-

mission, i.e., p is ”Permit”, and there is no conﬂict,

it grants the access permission for the request. Oth-

erwise, it denies the request. This kind of access au-

thorization does not involve the case when delegation

is present within access control policy setting. Algo-

rithm 1 represents this kind of access authorization.

Deﬁnition 3. (Monotonic Reasoning.) Let O

and O

two DL ontologies, and c is a DL axiom. O

entails c

(equivalently, c is a logical consequence of O

), writ-

ten as O

|= c if we have O

⊆ O

and O

|= c. In

secure authorization terms, monotonic authorization

reasoning means that positive (and negative) autho-

rizations will not be altered when new facts are added

into the knowledge base. Hence, what is previously

inferred as a permitted action still holds even after

new facts are asserted (or inferred) into the knowl-

edge base.

Deﬁnition 4. (Closed World Assumption (CWA)

(Pratt, 1994).) Closed World Assumption is the as-

sumption that what is not known to be true is false. In

CWA, absence of information is interpreted as neg-

ative information. CWA assumes complete informa-

ICISSP 2019 - 5th International Conference on Information Systems Security and Privacy

450

tion about a given state of affairs, which is useful for

constraining information and validating data in an ap-

plication such as a relational database.

Algorithm 1: Simple Access Authorization.

Input: CBAC, CBAC ontology and RQ is an Access

Request. RS is Jena rule-set

Output: Access decision, either ”Deny” or ”Permit”.

1: RT ←parse(RQ)  RT = hs,r, aci

2: if RT = access then

3: sc←getContext(s);

4: rc←getContext(r);

5: p←evaluate(s,sc, r,rc,CBAC,RS);

6: if p = ”Permit” AND

noCon f lict(p, s,sc, r,rc,CBAC,RS) then

7: return(”Permit”);

8: exit();

9: end if

10: else

11: return(”Deny”);

12: exit();

13: end if

Deﬁnition 5. (Non-monotonic Reasoning.) Let KB

and KB

be two knowledge bases, and c is a conse-

quence. We may have that KB

⊆ KB

and KB

but KB

c. In secure authorization terms, non-

monotonic authorization reasoning means that pos-

itive (and negative) authorizations may be altered

when new facts are added into the knowledge base.

Hence, what is previously inferred as a permitted ac-

tion may not hold when new facts are asserted (or in-

ferred) into the knowledge base.

Deﬁnition 6. (Open World Assumption (OWA) (Hit-

zler et al., 2010).) The Open World Assumption is

the assumption that what is not known to be true,

is unknown. In OWA, absence of information is in-

terpreted as unknown information that may be added

later. OWA assumes incomplete information about a

given state of affairs, which is useful for extending

information in an application such as ontology-based

applications and Semantic Web.

For the sake of this paper, CWA is better suited,

because we need to capture who has access per-

mission to a certain resource and not the reverse.

CWA assumes non-deductibility as a failure to pre-

vent granting access rights. For example, the access

authorization algorithm needs to know who has the

permission to access a certain resource but not all

those who have not the access permission to that re-

source. For this reason, we have used Jena forward

chaining rules to assert access authorization decisions

and also for blocking delegation-based access permis-

sions. Jena rules are used to enforce the CWA after all

semantic inferences are made.

Deﬁnition 7. (Least Privilege Principle (Schneider,

2003).) The least privilege principle states that a sub-

ject should be given only those privileges that it needs

in order to complete its task

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 (Bellav-

ista and Montanari, 2017). However, our context rep-

resentation differs than that adopted by (Bellavista

and Montanari, 2017). They have tightly coupled

the subject’s context (they call it the requester con-

text), the resource’s context, the environmental con-

text and the time context in one context (protection

context). In our model, the subject’s context and re-

source’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 (Hitzler et al., 2010) and

(https://www.w3.org/OWL/, Data accessed on April

13 2018) for additional description on the current

OWL standard.

Our context model is built around the concept of

contextual attribute, information which models con-

textual attributes of the physical/logical environment

such as location and temperature. Speciﬁc context

subclasses can be represented under Generic Concept

Context. Each subcontext class consists of attribute

values and constants. In our model, the generic con-

text of the subject is given by the following DL axiom:

SContext ≡ Context u (User u ∃hasID.IDentity

u ∃hasRole.Role u ∃hasGroup.Group)

u (Environment u ∃hasLocation.Location)u

(T Element u ∃hasTime.Time Interval) u ∃

hasID.Identi f ier (1)

For example, A reference context of OnDutyDoctor

is represented as follows:

OnDutyDoctor ≡ Context u (User u ∃hasID.IDentity

u ∃hasRole.Role{Doctor} u ∃hasGroup.Group

{InShi f tDoctors}) u (Environment{WorkingEnvrnt}

u ∃hasLocation.Location{Hospital}) u (T Element

{WorkingTime} u ∃hasTime{xsd : dateTime

[≥ 2018 − 04 − 06T 09 : 00 : 00,≤ 2018 − 04 − 06

T 17 : 00 : 00]})u ∃hasID.{0} (2)

Note that the concept OnDutyDoctor includes all the

characteristics speciﬁcations of the generic concept

Monotonic and Non-monotonic Context Delegation

451

SContext. We call this context a re f erence context.

It holds the high-level context of an entity which will

be used later as a reference when we need to in-

stantiate the active context of that entity. The active

context holds the entity context at a speciﬁc instant

of time. For example, when an entity requests an ac-

cess to a resource. Active contexts are similar to their

re f erence contexts counterparts. However, they dif-

fer in that they do not have range values in their deﬁni-

tions. Active context reﬂects a real snapshot of an en-

tity’s context at a speciﬁc time instant. For example,

the following DL axiom describes a certain user con-

text at 2018-04-06T14:23:00, which represents 2:23

pm on April 6, 2018:

OnDutyDoctor{Bob} ≡ Context u (User{Bob} u ∃

hasID.IDentity{Doctor563} u ∃hasRole.Role

{Doctor} u ∃hasGroup.Group{InShi f tDoctors})u

(Environment{WorkingEnvrnt} u ∃hasLocation

.Location{HospitalA}) u (T Element{WorkingTime}

u existshasTime.Time Instance{xsd : dateTime

[2018 − 04 − 06T 14 : 23 : 00]}) u ∃hasID.{0} (3)

This concept states that Bob is OnDutyDoctor at

time 2:23 pm on April 6, 2018, if he is a user, has

a role of Doctor, belongs to a group that is called

InShi f tDoctor, within a WorkingEnvrnt, at location

Hospital and during the WorkingTime.

The context ontology 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 con-

textual attributes may result in a number of problems.

These problems:

• Colluding (Servos and Osborn, 2016; Servos and

Osborn, 2017), i.e., two entities may satisfy a

policy that they could not if they acted individ-

ually. Our approach solves this problem by not

allowing the delegated context’s attributes to be

merged with the delegatee context’s attributes that

are of the same type. For example, consider Fig-

ure. 1 below, Joe and Alice can potentially col-

lude to satisfy a policy that they could not if

they acted individually. The policy {role(Lab-

Analyst),location(Hospital)} can not be satisﬁed

neither by Alice nor by Joe, if acting alone,

but they can deceive the system’s policy through

attribute-delegation.

Figure 1: Attribute delegation problems example.

When this context is delegated by our approach,

the delegatee’s context, c

, is checked if it already

has time and role attributes, and if these satisfy the

delegation constraints, the corresponding contex-

tual attributes of the delegator will not be merged

with them. Instead, a new context, c

, is created

for the delegatee, and the chosen contextual at-

tributes are assigned to it. This way there will be

no colluding among the contextual attributes be-

cause c

is not the same as c

• Inconsistent policy, i.e., the delegated privileges

are conﬂicting the user’s original privileges. For

example, Joe’s delegation of the role ”Doctor” to

Ann will result in Ann’s delegated context that

contains two values for the role attribute, ”Doc-

tor” and ”Nurse”. If there was a policy rule such

that ”role <> ”Nurse””, then two different re-

sults would be possible depending on the value of

role attribute. 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 delega-

tee. After the delegation is successfully completed,

delegatee can use the delegated context and the privi-

lege(s) associated with it to access to a resource r Our

approach imposes constrains on context delegation.

The constraints may be speciﬁed by the delegator or

the system security ofﬁcer. These constraints further

restrict the delegation. Intuitively, if the delegatee’s

context satisﬁes the constraints, then the delegation is

permitted. Otherwise, the delegation will be aborted.

Our model architecture is shown in Figure 2.

Deﬁnition 8. (Delegation Request (DR).) Delegation

request is given as a 6-tuple hs

,r, ac,DCs,Pari,

ICISSP 2019 - 5th International Conference on Information Systems Security and Privacy

452

Figure 2: The proposed system architecture.

where s

, s

∈ Sub ject and they represent the dele-

gator and delegatee, respectively. r ∈ Resource, the

resource to make the delegation over, ac ∈ Action,

the action and must be equal to ”delegate”, DCs ⊆

Constraint represents the set of constraints imposed

by the delegator on delegatee’s context, and Par is a

ﬁnite set of delegation parameters, other than the del-

egation constraints, which are speciﬁed by the dele-

gator. Delegation parameters, Par, are given by:

Par = (n

),..., (n

) (4)

Where n

represents the parameter name

and v

is the value of this parameter. Two important parame-

ters in Par are very crucial for our approach. DelType

and DelStatus, DelType is used to specify whether

the delegation is of type GRANT or T RANSFER.

If DelType = T RANSFER, then the delegator must

specify which kind of T RANSFER to work with. One

of the two values for the parameter DelStatus is used

to do so, which is either Permanent or Temporary.

The meaning of these values is clear, Permanent is

used for permanent delegation and Temporary is for

temporary delegation.

The DCs are represented as a set of pairs:

DCs = (CA

,Cons

),...(CA

,Cons

) (5)

Where CA

represents an attribute i and Cons

the delegation constraints set i (if any) that is imposed

over CA by the delegator and must be satisﬁed by the

delegatee’s contextual attributes.

3.1 Delegation Policies

Every delegation operation is subject to predeﬁned

delegation policies. Delegation policies are rules that

restrict the delegation. We represent our delegation

policies in a predicate form as follows:

can delegate(s

, c

, s

, c

, \GRANT ”, DCs):

subject s

can delegate context c

to subject s

if s

’s

context satisﬁes delegation constraints DCs.

can delegate(s

, c

, s

, c

, \TRANSFER”, DCs):

subject s

can delegate context c

to subject s

’s context (the reference context) satisﬁes delega-

tion constraints DCs.

can revoke(s

, s

, c

, casCaded): delegator s

can revoke the delegated context c

from s

if s

authorized to do so, i.e., it was the delegator of c

and the delegation is of type \GRANT ”. In case of

\T RANSFER” delegation, the system administrator

is responsible for revoking delegated context c

. Note

that, the issue of cascading revoke has been studied

extensively and we do not address this issue in this

paper.

3.2 Delegation Ontology

Delegation ontology, DEL, shown in Figure 3, states

that the Delegator is either a Source of Authority

(SoA), and in this case, she does not lose her ac-

cess rights when she transfers the Context associ-

ated with her to the Delegatee. Or she is not the

SoA, and in this case, she is going to lose her ac-

cess rights to a resource when she transfers her ac-

cess rights to a Delegatee. Only the SoA have the

right to set the value isSoA. This will keep dele-

gation chain under the control of SoA and guaran-

tee that the delegation authorization will not go in-

ﬁnite. Delegation has two types DelType to deal

with the two cases of delegation. The ﬁrst type is

when the Delegator transfers (”Transfer”) her access

rights to the Delegatee and the second type is when

the Delegator grants (”Grant”) her access rights to

the Delegatee. A Delegation can be delegated by

a Delegator who grants/transfers a Context in case

the Delegator is also the SoA) to a Delegatee if that

Delegatee’s context satisﬁes delegation constraints.

The delegated Context qualiﬁes the Delegatee to ac-

complish a speciﬁc type of Permission that is associ-

ated with the Context on a certain Resource. If the

Delegation isDelegatable and the MaxDepth of the

Delegation chain does not reach its limit yet, then the

Delegatee can be a Delegator. When Delegation is

endowed to a Delegatee, the constraints Constraint

are applied to that granted/transferred Delegation ac-

cording to what the Delegator speciﬁes. Delegation

ontology also speciﬁes that a Delegation can be au-

thenticated using some Credential. This meant to

be used by the CBAC engine to authenticate delega-

tors before they can reach/change their delegation set-

tings.

Monotonic and Non-monotonic Context Delegation

453

Figure 3: Delegation ontology.

3.3 Delegation Operations

We assume that each delegation operation delegates

only one context at a time. If the delegator has multi-

ple 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 delega-

tion operations. The delegation operation takes the

form delegate(s

, c

, s

, c

, \GRANT ”, Par).

Delegator s

delegates context c

to delegatee s

After checking delegation constraints satisfaction as

we have illustrated in the previous subsection, the del-

egation algorithm (see Algorithm 3) creates a delega-

tion instance with an identiﬁer del

. The delegation

instance gets part of its values from the delegation re-

quest, namely from Par and DCs. We deﬁne the fol-

lowing parameters, MaxDepth is the depth of the del-

egation. It speciﬁes the number of times the context

can be delegated. This value is set by the ﬁrst delega-

tor (isSoA = true, see Figure 3). The isDelegatable

is a Boolean value that determines whether the con-

text is delegatable. If isDelegatable = f alse, then the

algorithm automatically sets MaxDepth to 0.

3.4 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 ax-

ioms to include Horn-like rules. SWRL rules have

the syntax Antecedent− > Consequent, where each

Antecedent and Consequent consists of atoms. These

atoms can be of the form C(x), P(x,y), sameAs(x, y)

or di f f erentFrom(x,y), where C is an OWL class,

P is an OWL property, and x, y are either vari-

ables, OWL individuals or OWL data values. The

Consequent atom will be true if all atoms in the

Antecedent are true.

For example, suppose that Bob has

OnDutyDoctor as a reference context as has been

shown in equation 2. Now suppose that Bob wants

to set delegation constraint on the time contextual

attribute before delegating his context (his reference

context) to another user, Ann. Ann is a consultant

doctor and she has the following reference context:

OnDutyConsult ≡ C ontext u (User u ∃hasID.IDentity

u ∃hasRole.Role{Consult} u ∃hasGroup.Group

{InShi f tConsult}) u (Environment{WorkingEnvrnt}

u ∃hasLocation.Location{HospitalB}) u (T Element

{WorkingTime} u ∃hasTime{xsd : dateTime

[≥ 2018 − 04 − 06T 09 : 00 : 00,≤ 2018 − 04 − 06

T 17 : 00 : 00]}) u ∃hasID.{0} (6)

The delegation constraint is (01:00pm ≥

time ≥10:00am), that is, it can only be dele-

gated between 10:00 am and 01:00 pm. At the time

of delegation, Ann has an active context as shown

below:

OnDutyConsult{Ann} ≡ Context u (User{Ann} u ∃

hasID.IDentity{Doctor643} u ∃hasRole.Role

{Doctor} u ∃hasGroup.Group{InShi f tConsult})u

(Environment{WorkingEnvrnt} u ∃hasLocation

.Location{Hospital}) u (T Element{WorkingTime}

u existshasTime.Time Instance{xsd : dateTime

[2018 − 04 − 06T 12 : 30 : 00]}) u ∃hasID.{0} (7)

The policy engine checks, then, if the delegation

constraints are satisﬁed or not. The policy engine uses

the following SWRL rule to check the time constraint:

TimeCons(?t

) ∧ notBe f ore(?t

,?cons1) ∧ swrlb :

greaterT hanOrEqual(?cons1, 10 : 00) ∧ notA f ter

(?t

,cons2) ∧ swrlb : l essT hanOrEqual(?cons2,01 : 00)

− > satis f ied(?t

) (8)

where t

=Time Instance and is extracted from Ann’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 Bob.

3.5 Enforcement of Delegated

Authorization

Non-monotonic context delegation (and delegation in

general) needs to revise or contract the underlying

policy rules to make them adaptable to delegation

operation. To this end, non-monotonic delegation

ICISSP 2019 - 5th International Conference on Information Systems Security and Privacy

454

should be able to block, permanently or temporar-

ily, some access rules and prevent them from being

activated. Doing so, however, will enforce the pol-

icy engine to use negation to infer failure of some

rules within the policy rule set. DL’s ontologies and

SWRL rules do not permit this kind of reasoning be-

cause they based on the principle of Open World As-

sumption (OWA). OWA principle does not allow us

to conclude that a SWRL atom is false because OWA

assumes it may become true in the future, and hence,

it assumes that atom’s value is ”Unknown”. On the

contrary, in Logic Programming (LP), which is based

on Closed World Assumption (CWA), every atom or

proposition that is not proved to be true is considered

as a false atom.

The naive approach for doing so can simply be

achieved by removing the context c from the CBAC

knowledge base. However, this method ignores the

fact that one context may have access privileges to

multiple resources. Figure 4 illustrates this situation,

when subject s with context c can access resources

...r

. When trying to prevent subject s with context

c from accessing resources r

and r

by deleting con-

text c, then subject s will also be prevented to access

resources r

, r

Figure 4: Naive context deletion.

To remedy this situation, we propose to selec-

tively block subject with speciﬁc context from ac-

cessing certain resources via labeling the access path

from that context to the blocked resources using OWL

object properties. The predicate update − cbac() is

used to block a subject s with context c and deprive

it from accessing resource r. This is done by insert-

ing fresh OWL Object property instances, isT Blocked

or isPBlocked, between context c and resource r.

isT Blocked is used for temporarily blockade, while

isPBlocked is used for permanent blockade Figure 5.

Both isT Blocked or isPBlocked are deﬁned in CBAC

ontology.

Figure 5: Selective context blockade.

The enforcement of access control authorization

with delegation is achieved via selective blocking of

the context (and hence their associated subjects) from

accessing certain resources. Algorithm 2 is used for

this purpose.

The context delegation (both monotonic and non-

monotonic) is implemented via answering the delega-

tion request using algorithm 3.

Algorithm 3 takes CBAC, Del, Ctx, RS and RQ, for

Context-Based Access Control, delegation and con-

text ontologies, respectively. RS is the access con-

trol rule-set and RQ is an Access Request. The al-

gorithm returns the updated ontologies CBAC, Del,

Ctx and the updated RS. The function parse(RQ) is

used for parsing the request and to check its syntax

correctness. Function dismantle(RT ) is used to fur-

ther partition the request into its elements, namely the

delegator s

, the delegatee s

, the resource r, delega-

tion constraints DCs and delegation parameters Par.

The function isAuthorized(s

,sc

,r, rc,CBAC, RS) is

used to check whether s

has the privilege to access

resource r. It uses Algorithm 2 to do that. Func-

tion extractCAs(X ) is used to extract the contextual

attributes CAs from a given context axiom X. The

function type = extract type(Par) extracts, from a set

of parameters found in Par, the type of delegation.

The checkSatis f iability(DCs,CAs) function checks

the satisﬁability of contextual attributes of s

against

delegation constraints DCs set by s

. The approach

proceeds as follows:

1) The delegator prepares a delegation request and

sends it to the policy engine.

2) The policy engine parses the request and starts the

delegation process.

Monotonic and Non-monotonic Context Delegation

455

Algorithm 2: Delegation-Supported Access Authorization.

Input: CBAC, CBAC ontology, Del is a delegation on-

tology, RQ is an Access Request, RS is access control

rule-set.

Output: Access decision, either ”Deny” or ”Permit”.

1: RT ←parse(RQ)  RT = hs,r, aci

2: if RT = access then

3: sc←getContext(s);

4: if sc.Id 6= Null then

5: d inst ← consult(Del,sc.Id)

6: if Del has an RDF triple:(del : d ins del :

OnResource cbac : r) then

7: rc←getContext(r);

8: p←evaluate(s,sc, r,rc,CBAC,RS);

9: end if

10: if p = ”Permit” AND

noCon f lict(p, s,sc, r,rc,CBAC,RS) then

11: Permit − Access;

12: exit();

13: else

14: Deny − Access;

15: exit();

16: end if

17: end if

18: if sc.Id = Null then

19: if Not(blocked(sc,r,CBAC)) then

20: rc←getContext(r);

21: p←evaluate(s,sc, r,rc,CBAC,RS);

22: end if

23: if p = ”Permit” AND

noCon f lict(p, s,sc, r,rc,CBAC,RS) then

24: Permit − Access;

25: exit();

26: else

27: Deny − Access;

28: exit();

29: end if

30: end if

31: else

32: return(”Not access request”);

33: end if

3) The policy engine extracts the delegation con-

straints, asks the context manager for the delegator’s

context, and checks if the delegator has the delegation

right.

4) If the delegator is authorized, the policy engine

asks the context manager for the delegatee’s (s

) con-

text and checks for satisﬁability of the delegation.

5) If the delegation is satisﬁable, the policy engine

creates a delegation instance using the delegation on-

tology and the parameters speciﬁed in the delegation

request.

Algorithm 3: Context Delegation Request Answering.

Input: CBAC, Del, Ctx are CBAC, delegation, and

context Ontologies. RS is the access control rule-set.

RQ is an Access Request.

Output: UCBAC, UCtx, UDel /*Updated CBAC, con-

text and delegation ontologies.*/

1: RT ← parse(RQ)

2: if RT = RQ then

3: evaluateRQ(RT );

4: exit();

5: end if

6: hs

,r, ac,DCs,Pari ← dismantle(RT );

7: sc

←getContext(s

);

8: rc←getContext(r);

9: if isAuthorized(s

,sc

,r, rc,CBAC, RS) = f alse

then

10: out put(”s

is not authorized to access r”);

11: exit();

12: end if

13: sc

←getContext(s

);

14: CAs←extractCAs(sc

);

15: T ←checkSatis f iability(DCs,CAs);

16: if T = f alse then

17: out put(”T he context is not delegatable”);

18: exit();

19: end if

20: type←extr act type(Par)

21: if type = ”GRANT ” then

22: UDel←createDelegationinstance(Del,hs

r,ac, DCs,Pari, del

)

23: UCtx←createContext(Cx

,Ctx, del

)

24: return(UDel,UCtx)

25: exit()

26: else

27: UDel←createDelegationinstance(Del,hs

r,ac, DCs,Pari, del

)

28: UCtx←createContext(Cx

,Ctx, del

)

29: UCBAC←update cbac(C BAC,UDel,del

,sc

,r)

30: return(UCBAC,UDel,UCtx)

31: exit()

32: end if

6) The policy engine sends a request to the context

manager, accompanied with a delegation identiﬁer,

del

, to construct a generated context for s

. This

context is a copy of the delegator reference context

but it is associated with the delegatee.

7) The context manager creates the generated context

for s

and associates it with the identiﬁer del

pro-

vided by the policy engine with the request.

8) Now the delegatee has two contexts, the instanti-

ated context and the generated context and (s)he can

choose which one to work with.

ICISSP 2019 - 5th International Conference on Information Systems Security and Privacy

456

4 PROPERTIES AND PROOFS

In this section, we provide the proof that context dele-

gation approach, as well as enforcing the context del-

egation in access authorization are sound, consistent

and preserve the Least-Privilege principle.

The function evaluate() is given by:

function evaluate(s,sc, r,rc,CBAC,RS)

1 : RulesNo ← getrulesnumber(RS);

2 : in f model ← reason(CBAC);

3 : for i = 1 to RulesNo do

4 : if RS[i] has the f orm :

(?rq rd f : type cbac : Request)

(?rq ctx : hasAction cbac : ac)

(?rq cbac : hasSub ject ?s)

(?rq cbac : hasResource ?r)

(?s rd f : type ctx : sc)

(?r rd f : type ctx : rc)

(?rq cbac : hasDecision ?d)

− > (?d cbac : hasE f f ect cbac : p)] then

5 : if p = ”Permit” then

6 : return(p);

7 : exit();

8 : else

9 : p = ”Deny”

10 : return(p);

11 : exit();

12 : end {evaluate}

The function evaluate(s,sc,r,rc,CBAC,RS) takes

the access control ontology CBAC, Figure 6 as in-

put and achieves the DL-based reasoning to get the

in f model. The access control policy rules, repre-

sented as Jena forward inference rules, will be ap-

plied on in f model to derive an access decision. The

function getrulesnumber(RS) returns the number of

rules in the access control policy rule-set RS. The

Boolean function noCon f lict(p,s,sc,r,rc,CBAC,RS)

works just like evaluate(s,sc,r,rc,C BAC,RS) function

but it returns a Boolean value if two conﬂicting rules

(”Permit” and ”Deny”) are ﬁred at the same time.

Lemma 1. Given RS and CBAC correctly repre-

sented, the function evaluate(s,sc,r,rc,CBAC,RS) will

always return a correct authorization decision.

Proof. Assume the function

evaluate(s,sc,r,rc,CBAC,RS ), when it is called,

returns false authorization decision. This decision

could be derived in three cases: (i) The ﬁrst case

Figure 6: CBAC ontology.

is an example of traditional security violations that

could take place in any system. A resource owner

(or security ofﬁcer) misconﬁgures her security

settings, such as incorrectly encoding Jena rules for

access control policy. As a result, the system will

adhere to this misconﬁgured setting.(ii) There is no

misconﬁgured security settings. In this case, one

of the following three conditions must be held: (a)

The DL-based reasoning process (step 2) returns

inconsistent model. This assumption is invalid

because we use DL-based reasoner Pellet which

is sound and complete with respect to OWL-DL.

Hence, The system knowledge base is always have

correct and consistent information. (b) RS 2 p, access

control rule-set does not model the decision p (p is

neither ”Permit” or ”Deny”). If p ∈ RS, then RS |= p.

If p /∈ RS, then p must be generated by a Jena rule of

the form:

∧ ... ∧ a

→ p (9)

where a

...a

are RDF (Resource Description Frame-

work) triples and p is an RDF triple (or set of triples),

and for each a

∈ a

...a

, RS |= a

, either by infer-

ence or by assertion. If RS |= a

for all a

...a

, then

...a

|= p, for p is either ”Permit” or ”Deny” (more

precisely, ”Deny” is the default value returned by the

function evaluate(s,sc,r,rc,CBAC,RS ) when there is

no rule of the form a

...a

|= p). Hence, RS |= p

which contradicts our assumption that RS 2 p. (c)

RS and/or CBAC are incorrectly represented. This

contradicts (a) above and our assumption that CBAC

and RS are correctly represented. Hence, the function

evaluate(s,sc,r,rc,CBAC,RS ) will eventually derive a

correct access decision p.

Corollary 1. Given a CBAC and RS correctly repre-

sented, the function noCon f lict(p,s,sc,r,rc,CBAC,RS)

will derive the correct Boolean value and terminates.

Proof. Function noCon f lict(p,s,sc,r,rc,CBAC,RS)

works just like the function

Monotonic and Non-monotonic Context Delegation

457

evaluate(s,sc,r,rc,CBAC,RS ) does but after ﬁnd-

ing a decision p=”Permit”, it iteratively searches

for p=”Deny”. If it happens to ﬁnd two conﬂicting

decisions, it will return a true value. Otherwise,

f alse value is returned. In Lemma 1, we have

proved that the function evaluate(s,sc,r,rc,CBAC,RS)

is sound (returns only correct answers). Hence,

noCon f lict(p,s,sc,r,rc,CBAC,RS) follows from

Lemma 1.

Theorem 1. (Algorithm 2 Soundness.) Given a do-

main knowledge base that is correctly represented us-

ing ontologies CBAC, CT X, DEL, and a set of Jena

rules RS.

Proof. The proof is naturally follows from Lemma 1

and Corollary 1.

Lemma 2. Function checkSatis f iability(DCs;CAs)

is decidable, sound and consistent.

Proof. We use only SWRL-Safe rules in our delega-

tion and CBAC ontologies. A SWRL rule is DL-safe

if every variable in the rule head occurs in a Data-

log atom in the body. SWRL-Safe rules are known to

be decidable, sound, consistent and complete (refer to

(Motik et al., 2005) for the complete proof).

function update cbac(CBAC,UDel,del

,sc

,r)

1 : D ← get Instance(UDel,del

);

2 : if D.isPermanent = ”False” then

3 : UCBAC ← CBAC ∪ opAssertion(sc

,r,

”isT Block”)

4 : else

5 : UCBAC ← CBAC ∪ opAssertion(sc

,r,

”isPBlock”);

10 : return(UCBAC);

11 : exit();

12 : end {update cbac}

Lemma 3. The function up-

date cbac(CBAC,U Del,del

,sc

,r) is decidable,

sound and consistent.

Proof. All ontology-based operations in this func-

tion, namely get Instance() and opAssertion() (for

object Property assertion) are decidable, sound and

complete.

Theorem 2. (Algorithm 2 Soundness.) Given a do-

main knowledge base that is correctly represented us-

ing ontologies CBAC, CT X, DEL, and a set of Jena

rules RS.

Proof. The proof is naturally follows from Lemma 1

and Corollary 1.

Theorem 3. (Algorithm 3 Soundness.) Given a do-

main knowledge base that is correctly represented us-

ing ontologies CBAC, CT X, DEL, and a set of Jena

rules RS.

Proof. The proof is naturally follows from proof of

Theorem 2, Lemma 2 and Lemma 3.

We have shown that Algorithms 2 and 3 are sound.

Remains to prove that the model in which context del-

egation is used is consistent, no contradicting deci-

sions are derived for one access request.

Theorem 4. (Model Consistency.) Given a model

represented by a domain knowledge base that is

correctly represented using ontologies CBAC, CT X,

DEL, and a set of Jena rules RS. Delegation opera-

tion always results in consistent access authorization

decisions (”Permit” and ”Deny” are never both de-

rived as answers for the same access request).

Proof. Let M be the model of our approach and is

given by M =CBAC∪ CT X ∪ DEL. Our model em-

ploys two types of reasoning techniques, monotonic

reasoning which is achieved by DL-based Pellet rea-

soner on the model ontologies before any access au-

thorization or delegation operation is made and non-

monotonic reasoning, which is applied using Jena

forward chaining. Monotonic reasoning has been

proven to be decidable, sound, complete and consis-

tent (Baader et al., 2003; Hitzler et al., 2010). That

means for every sound and consistent model M , there

is an inference model M F = In f (M ), where In f is

the DL-based reasoning operation, M F is also sound

and consistent model. Hence, while the model is cor-

rectly represented (this is given), so all DL-based in-

ferences produce sound and consistent output models.

However, this fact does not solve the problem of pos-

sible inconsistencies that may be resulted when de-

riving an answer for a request (it is possible to reach

to a conclusion that the decision is both ”Permit” and

”Deny” while both of them belong to the same class in

the CBAC ontology and not for disjoint classes). Our

model solves this problem by using Jena rules (func-

tion noCon f lict(p,s,sc,r,rc,CBAC,RS)) which returns

a true value when conﬂicting decision is reached.

Hence, the model M is consistent and any model

M F that is resulted by either monotonic reasoning

or non-monotonic reasoning is also consistent (in re-

spective to conﬂicting access decisions).

Theorem 5. (Least-privilege Principle.) Given a do-

main knowledge base that is correctly represented

using ontologies CBAC, CT X, DEL, and a set of

Jena rules RS. Algorithms 2 and 3 (Delegation-

Supported Context Delegation) always preserve the

ICISSP 2019 - 5th International Conference on Information Systems Security and Privacy

458

Least-Privilege Principle when executes a delegation

request.

Proof. In this proof, we combine two proofs of Algo-

rithms 2 and 3 preserve Least-Privilege Principle. As-

sume that Algorithms 2 and 3 do not preserve Least-

Privilege Principle. This would happen in two situa-

tions:

(i) Delegatee acquires more privileges that (s)he

supposed to have according to the policy in use.

For example, delegatee may acquire, as a result

of context delegation operation, access to more

than the speciﬁed resource(s) or/and can use

more than one access type (write/read/execute)

on a speciﬁc resource. Our approach restricts

the delegatee access to a speciﬁc resource (and

the type of this access) according to the delega-

tion ontology. In (step 4) of Algorithm 2, we

check whether the context is a delegated or an

instantiated context (sc.Id = X or sc.Id = Null,

X is any non-zero integer value). If it is a del-

egated context, then the algorithm checks if the

delegation instance d ins is applicable on a re-

source r by checking existence of RDF triple

(del

: d ins del : OnResource cbac : r) in del-

egation ontology (step 6). Only in this case the

delegatee with context sc is permitted to access

resource r in ontology CBAC. Otherwise, ac-

cess is denied. But this violates our assump-

tion that Algorithms 2 and 3 do not preserve

Least-Privilege Principle. Hence, Algorithms 2

and 3 preserve Least-Privilege Principle for the

delegatee accessing a resource in the knowledge

based.

(ii) Delegator has transferred her context sc to

the delegatee but she is still able to use it

for accessing resource r. Algorithm 3 (step

29) updates the CBAC ontology by insert-

ing an RDF triple (ctx : c cbac : isPBlock

cbac : r), for permanent delegation, and (ctx : c

cbac : isT Block cbac : r), for temporary del-

egation). In this way, when delegator tries

to access resource r using a context sc that

she has already permanently or temporarily

transferred it to the delegatee, then algorithm

will discover that this context is blocked from

access resource r (step 19 of Algorithm 2).

Again, this violates our assumption that Algo-

rithms 2 and 3 do not preserve Least-Privilege

Principle. Hence, Algorithms 2 and 3 preserve

del, cbac and ctx are preﬁxes for delegation, CBAC and

context ontologies

Least-Privilege Principle for the delegator ac-

cessing a resource in the knowledge based.

5 CONCLUSION AND FUTURE

WORK

In this paper we have proposed two ontology-based

context delegation approaches. Monotonic context

delegation, which adopts GRANT version of del-

egation, and non-monotonic for TRANSFER ver-

sion of delegation. The approaches provide dynamic

and adaptive mechanism for monotonic and non-

monotonic privilege delegation. The proposed mono-

tonic delegation does not cause any change to the un-

derlying access control policy. For non-monotonic

delegation, the approach incurs only selective changes

to the underlying access control policy. The ap-

proaches presented in this paper are modeled using

semantic-based technologies and can be used by ex-

isting CBAC systems which do not provide delegation

capability. Furthermore, we have provided the for-

mal proofs that context delegation and its delegation-

supported authorization enforcement are sound, con-

sistent and preserve the least privilege principle. We

have implemented the model using real networks.

The ontologies and some related preliminary cod-

ing can be found on https://github.com/Mouiad1975/

Context-Delegation

For future direction, we are working on extending

our model by using RESTful web services with Java

(Jersey/JAX-RS). Another extension we are working

on is the semantic-based obligation for situations that

need to make sure some obligations are respected by

subjects already got the access authorization to access

certain resources.

REFERENCES

AL-Wahah, M. and Farkas, C. (2018). Context delegation

for context-based access control. In 2nd International

Workshop on A.I. in Security, pages 70–79. ECML.

Baader, F., Calvanese, D., McGuinness, D., Patel-

Schneider, P., and Nardi, D. (2003). The description

logic handbook: Theory, implementation and applica-

tions. Cambridge university press.

Bellavista, P. and Montanari, R. (2017). Context awareness

for adaptive access control management in iot envi-

ronments. Security and Privacy in Cyber-Physical

Systems: Foundations, Principles and Applications,

pages 157–178.

Monotonic and Non-monotonic Context Delegation

459

Bhatti, R., Bertino, E., and Ghafoor, A. (2005). A

trust-based context-aware access control model for

web-services. Distributed and Parallel Databases,

18(1):83–105.

Corradi, A., Montanari, R., and Tibaldi, D. (2004). Context-

based access control management in ubiquitous envi-

ronments. In Proceedings of the 3rd IEEE Interna-

tional Symposium on Network Computing and Appli-

cations, pages 253–260. IEEE.

Crampton, J. and Khambhammettu, H. (2008). Delegation

in role-based access control. International Journal of

Information Security, 7(2):123–136.

Dey, A., Abowd, D., and Salber, D. (2001). A concep-

tual framework and a toolkit for supporting the rapid

prototyping of context-aware applications. Hum.-

Comput. Interact., 16(2):97–166.

Gusmeroli, S., Piccione, S., and Rotondi, D. (2013). A

capability-based security approach to manage access

control in the internet of things. Mathematical and

Computer Modelling, 58(5-6):1189–1205.

Hitzler, P., Kr

otzsch, M., and Rudolph, S. (2010). Foun-

dations of Semantic Web Technologies. Chapman and

Hall/CRC Press.

Kagal, L., Berners-Lee, T., Connolly, D., and Weitzner, D.

(2006). Self-describing delegation networks for the

web. In Policies for Distributed Systems and Net-

works, 2006. Policy 2006. Seventh IEEE International

Workshop on, pages 10–pp. IEEE.

Kulkarni, D. and Tripathi, A. (2008). Context-aware role-

based access control in pervasive computing systems.

In Proceedings of the 13th ACM symposium on Ac-

cess control models and technologies, pages 113–122.

ACM.

Motik, B., Sattler, U., and Studer, R. (2005). Query answer-

ing for owl-dl with rules. Web Semantics: Science,

Services and Agents on the World Wide Web, 3(1):41–

60.

Pratt, I. (1994). Closed World Assumptions, pages 65–84.

Springer.

Schneider, F. (2003). Least privilege and more [computer

security]. IEEE Security & Privacy, 99(5):55–59.

Servos, D. and Osborn, S. (2016). Strategies for incorpo-

rating delegation into attribute-based access control

(abac). In International Symposium on Foundations

and Practice of Security, pages 320–328. Springer.

Servos, D. and Osborn, S. (2017). Current research and

open problems in attribute-based access control. ACM

Computing Surveys (CSUR), 49(4):1–65.

Shen, H. and Cheng, Y. (2011). A semantic context-based

model for mobile web services access control. Inter-

national Journal of Computer Network and Informa-

tion Security, 3(1):18.

Toninelli, A., Montanari, R., Kagal, L., and Lassila, O.

(2006). A semantic context-aware access control

framework for secure collaborations in pervasive com-

puting environments. In International semantic web

conference, pages 473–486. Springer.

Trnka, M. and Cerny, T. (2016). On security level usage in

context-aware role-based access control. In Proceed-

ings of the 31st Annual ACM Symposium on Applied

Computing, pages 1192–1195. ACM.

Zhang, L., Ahn, G., and Chu, B. (2001). A rule-based

framework for role based delegation. In Proceedings

of the sixth ACM symposium on Access control models

and technologies, pages 153–162. ACM.

ICISSP 2019 - 5th International Conference on Information Systems Security and Privacy

460