δǫ

-OrBAC: Context based Access Control

Narhimene Boustia

and Aicha Mokhtari

Saad Dahlab University, Algeria

USTHB University, Algeria

Abstract. The ﬁnal objective of an access control model is to provide a frame-

work to decide if an action performed by subjects on objects is permitted or not.

It is not convenient to directly specify an access control policy using concepts

of subjects, objects and actions. In OrBAC (Organization Based Access Control),

we can not only express static authorizations but also dynamic authorizations, de-

pending on context. Formally, OrBAC is described in ﬁrst order logic, where the

context is one of the argument of predicate. We propose a new formalism based

on description logic with defaults and exceptions [1] to describe and reason on

OrBAC model. This paper is an enrichment of a previous work [10] with the in-

troducing of an exception operator (ǫ). This formalism covers not only concepts

of information systems like users, objects, subjects and roles but also the context

by the add of two operators of default (δ) and exception (ǫ). Notice that time

complexity is still polynomial [2].

1 Introduction

Security policy models as DAC [3], MAC [4,5] and RBAC [6] (Role Based Access

Cotrol) provide concepts that are useful in current IS. However, such security policies

must also be adapted to deal with new requirements; rule are depending on context.

OrBAC (Organization Based Access Control) is useful to deal with some of these

new requirements [7]. OrBAC is a model that allows to express a security policy at

organizational level, i.e., indepent from the implementation made for this policy. The

access control policy does not directly apply to subject, object and action. It deﬁnes

static authorizationsthat apply within organization to controlthe activities performedby

roles on views. However, the OrBAC model also allows speciﬁcation of more complex

dynamic authorizations applying in a given context. The formalism used is the ﬁrst

order logic where the context is an additive argument.

The purpose of this paper is to present DL

δǫ

-OrBAC which is a new formalization

of OrBAC model based on descrition logic with defaults and exceptions (AL

δǫ

) [1].

Description Logic (DLs) [8] are a family of knowledge used to describe and classify

concepts and their instances. (AL

δǫ

) extends the well known description logic (AL) [8]

with the two unary connectives (δ, ǫ) to express respectively default and exception.

The idea is to consider that when we are in a usual context, we obtain a default

authorization and we express this fact with the connective(δ), but if the context change,

the authorization is excepted, and we express this exception with the connective (ǫ).

Notice, that even if we have more thant exception, we can represent this fact with the

Boustia N. and Mokhtari A. (2009).

DLδ-OrBAC: Context based Access Control.

In Proceedings of the 7th International Workshop on Security in Information Systems, pages 111-118

DOI: 10.5220/0002175801110118

 SciTePress

composition of operators of exception (ǫ), and in spite of this, time complexity still

polynomial. This paper is an enrichment of a previous work [10] with the introducing

of an exception operator (ǫ).

The rest of the paper is structured as follow. Section 2 presents OrBAC model,

section 3 introduces description logic with defaults and exceptions. Section 4 deﬁnes

δǫ

-OrBAC, shows how we express security and how we can infer access control

rules in differents contexts. We conclude in section 5 by the prospects of evolution of

δǫ

-OrBAC.

2 OrBAC Model

The central entity in OrBAC model is Organization. An Organization can be seen as an

organized group of subjects, each playing a speciﬁc role. In the medical domain, “Pi`ere

and Marie Curie Center”, “Service of Pediatrics”,etc are organizations. Subject, Action

and Object are respectively abstracted into Role, Activity and View [7].

A Role is a set of Subjects to which the same security rule apply, for example, the

subject “John” plays the role of “Doctor” in the organization “Service of Pediatrics”. A

View corresponds to a set of Objects that satisfy a common property,for example, in the

medical domain, the view “Medical record” corresponds to the object “Medical record

of patient”. An Activity regroups Actions that partake of the same principle. In OrBAC

model, Actions will mainly contain computer actions such as “read”, “write”,etc, when

Activities contain “consulting”,“writing”,etc. Privileges only apply in speciﬁc contexts.

Contexts can be used to specify the concrete circumstances where organizations grant

roles permission to perform activities on views.

It considers that all actions which are not permitted are prohibited, so it sufﬁce to

deﬁnes only permission relation.

OrBAC is deﬁned using eight basic sets of entities: OR (set of organizations), S

(set of subjects), AC (set of actions), O (set of objects), R (set of roles), AV (set of

activities), V (set of views) and C (set of contexts).

In the next section, we will introduce our formalism used to describe DL

δǫ

-OrBAC

which is based on description logic with defaults and exceptions.

3 Description Logic with Defaults and Exceptions

Description logic is actually largelly used to represent concept hierarchies, it employs

two kinds of formalisms for the knowledge representation: the terminological formal-

ism (TBox) used to describe conceptual knowledge, the assertional formalism (ABox)

used to allow facts to be stated [8].

In what follows, we present (AL

δǫ

), an extension of AL language with the two

operators of defaults (δ) and exceptions (ǫ).

3.1 AL

δǫ

Language

The description language with defaults and exception AL

δǫ

is inductively deﬁned from

a set R of primitive roles and a set P of primitive concepts [9], augmented by the con-

stant ⊤ (Top), with the abstract syntax rule:

112

C, D → ⊤ the most general concept

| P primitive concept

| C ⊓ D concept conjunction

| ¬P negation of primitive concept

| ∀∃r : C C is a value restriction on all roles R(> 0)

| δC default concept

| C

exception to the concept

δ and ǫ are two unary connectives, ⊓ is a binary conjunction connective and ∀∃

enables universal quantiﬁcation on role values.

In the next section, we will give the formalization of OrBAC model based on de-

scription logic with defaults and exceptions. We will show how these two connectives

(δ, ǫ) can be efﬁcient to formalize access control.

4 DL

δǫ

-OrBAC

We now conceptualize the OrBAC model and construct a DL knowledge base capturing

the characteristics of OrBAC, including the context with the use of (δ) and (ǫ).

4.1 The TBox

Given an OrBAC model, we deﬁne a DL knowledgebase K, the alphabets of K includes

the following atomic concepts: Organization, Subject, Object, Role, View, Action, Con-

text and Activity. The TBox includes the following axioms, each axiom is illustrated

with examples.

– Role Attribution Axiom: deﬁnes the relationship between subject and role.

Sub ject ⊑ ⊤; Role ⊑ ⊤;

Organization ⊑ ⊤

Employ ⊑ EmployS.Subject ⊓ EmployR.Role ⊓ Emp loyOr.Organization

Suppose that in a given hospital X, Jean is assigned in the role of Doctor, and Tom

is assigned in the role of Surgeon. We express all these facts by the following rules.

Employ(E1) ⊑ EmployS.Subje c t (J ean) ⊓ Empl oyR.Role(Doctor)

⊓ EmployOr.Organization(X)

Employ(E2) ⊑ EmployS.Subje c t (T om) ⊓ EmployR.Role(Surg eon)

⊓ EmployOr.Organization(X)

Where E1, and E2 are instances of Employ.

– View Deﬁnition Axiom: deﬁnes relationship between object and view.

Object ⊑ ⊤

V iew ⊑ ⊤

Use ⊑ UseO.Object ⊓ UseV.V i ew ⊓ UseOr.Organ ization

Suppose that in a given hospital X, Med-rec1 and ordinnance1 are instances of

concept Object, and Med-rec and ordinnance are instances of concept View. We

express all these facts by the following rules.

Use(U1) ⊑ Us eO.Object(Med − rec1) ⊓ U seV.view(Med − rec)

⊓ U seOr.Organization(X)

113

Use(U2) ⊑ Us eO.Object(Ordinnance1) ⊓ U seV.view(Or dinnance)

⊓ U seOr.Organization(X)

Where U1 and U2 are instances of Use.

– Activity Deﬁnition Axiom: deﬁnes relation between action and activity.

Action ⊑ ⊤

Activity ⊑ ⊤

Consider ⊑ ConsiderAc.Action ⊓ ConsiderAv.Activity

⊓ ConsiderOr.Organization

Suppose that in a given hospital X, action write is considered as a modiﬁcation

activity and action read as a consultation activity. We express all these facts by the

following rules.

Consider(C1) ⊑ ConsiderAv.Activity(Modify)⊓ConsiderAc.Action(write)

⊓ ConsiderOr.Organization(X)

Consider(C2) ⊑ ConsiderAv.Activity(Consult)⊓ConsiderAc.Action(read)

⊓ ConsiderOr.Organization(X)

Where C1 and C2 are instances of Consider.

– Context Deﬁnition Axiom:

Conte xt ⊑ ⊤

Define ⊑ DefineAc.Action ⊓ DefineS.Subject ⊓ DefineO.Object

⊓ Def ineC.Context ⊓ DefineOr.Organization

We need ﬁrst to deﬁne the Normal context.

Define(D1) ⊑ De f ineAc.Action(W rite) ⊓ DefineS.Subject(Jean)

⊓ Def ineO.Object(Ordinnance) ⊓ Def ineC.Context(Normal)

⊓ Def ineOr.Organization(X)

Where D1 is an instance of Deﬁne.

– Permission Attribution Axiom: deﬁnes the relation between role, activity, view

and context in an organization.

Prohibition = non Permission

P ermission ⊑ P ermisionAv .Activity ⊓ P ermissionR .Role

⊓P ermissionV.V iew ⊓P ermissionC.Context⊓P ermissionOr.Organization

Every user who play the role of Doctor is permitted to modify an ordinnance

when the context normal is true.

P ermission(P 1) ⊑ P er m isionAv.Activity(Modify)

⊓ P ermissionR.Role(Doctor) ⊓ P ermissionV.V iew(Ordinnance)

⊓ P ermissionC.Context(Normal) ⊓ P ermissionOr.Org anization(X)

Where P1 is an instance of Permission.

– Hierarchy Deﬁnition Axiom: deﬁnes the hierarchy between roles.

Sub−role ⊑ Sub−role1.Role⊓Sub−role2.Role⊓Sub−roleOr.Organization

Role1 is a sub role of Role2 in organization Or

Suppose that in a given hospital X, a Surgeon play also the role of Doctor, then a

surgeon inherits the set of authorizations of the role doctor. The next rule express

this fact.

P ermission(X, Doctor, Av, V, C) ⊑ P er m ission(X, Surgeon, Av, V, C)

114

And because we deﬁned the concept of Sub-role, so the inheritance is expressed as

follow:

P ermission(X, Surgeon, Av, V, C) ⊑ P ermission(X, Doctor, Av, V, C) ⊓

Sub − role(X, Surgeon, Doctor)

– Concrete Permission Axiom:

Is − permitted ⊑ Is − permittedAc.Action ⊓ Is − p ermittedS.Subject

⊓ Is − pemittedO.Object

Jean is permitted to write Diagnosis

Is − permitted(I1) ⊑ Is − per mittedAc.Action(W rite)

⊓ Is − permittedS.Subject(Jean) ⊓ Is − pemittedO.Object(Diagnosis)

Deﬁnition of Rules of Security:

Employ ⊓ U se ⊓ Consider ⊓ δP ermission ⊓ δDefine ⊑ δIs − p ermitted

Employ ⊓ U se ⊓ Consider ⊓ P ermission

⊓ Def ine

⊑ Is − permitted

4.2 The ABox

The ABox of K includes eight catalogs of axioms: Organization assertions axiom, Sub-

ject assertions axiom, Object assertions axiom, View assertions axiom, Role assertions

axiom, Action assertions axiom, Activity assertions axiom and Context assertions ax-

iom.

In the next section, we show how a security policy can be modelized and how we

can infer authorizations.

4.3 Inference and Subsumtion

– Permission Hierarchy

We know that a Surgeon is a sub-role of Doctor, so we can write:

Sub − role(S1) ⊑ Sub − role1.Role(Surgeon) ⊓ Sub − role2.Role(D octor)

⊓ Sub − roleOr.Organization(X)

When we want to know if a Surgeon is permitted to write an ordinnance, we use

the following rule:

P ermission(X, Surgeon, M odif y, Ordinnance , N ormal) ⊑

P ermission(X, Doctor, M odif y, Ordinnance, N orma l) ⊓ Sub − role(S1)

and then the answer in this case is Yes because we use the inheritance of properties

in the normal case.

– Access Control if Normal Context is True

Within organization X, Normal context holds between subject Jean, action Write

and object Diagnosis1, we obtain D2, an instance of concept Deﬁne.

Define(D2) ⊑ De f ineAc.Action(W rite) ⊓ DefineS.Subject(Jean)

⊓ Def ineO.Object(Diagnosis1) ⊓ DefineC.Context(Normal)

⊓ Def ineOr.Organization(X)

We also know that Diagnosis1 is an object used in a view Diagnosis, an instance

U3 of Use is write as:

115

Use(U3) ⊑ Us eO.Object(Dia gnosis1) ⊓ UseV.view(Diagnosis)

⊓ U seOr.Organization(X)

And ﬁnally, we know that in organization X, each person who play the role of

Doctor is permitted to modify Diagnosis, when Normal context is true, we write

an instance P2 as:

P ermission(P 2) ⊑ P er m isionAv.Activity(Modify)

⊓ P ermissionR.Role(Doctor) ⊓ P ermissionV.V iew(Di agnosis)

⊓ P ermissionC.Context(Normal) ⊓ P ermissionOr.Org anization(X)

Now, the question is: Is Jean permitted to write diagnosis in a normal context?; We

have:

-Jean play role of doctor in organization X: Employ(E1);

-and, Diagnosis1 is an object used in the view Diagnosis: Use(U3);

-and, Write is considered as a modiﬁcation activity: Consider(C1);

-and, by default, within organizationX, contextNormal holds between subject Jean,

action Write and object Diagnosis1: δDef ine (D2);

-and ﬁnally, by default, in organization X, each person who plays the role of Doctor

is permittedto modify Diagnosis, whenNormalcontextis true:δP ermission(P 2).

Formally,we write:Employ(E1)⊓Use(U3)⊓Consider (C1)⊓δP ermission(P 2)⊓

δDef in e(D2)

Using security rules, we can deduce that the precedent proposition subsume δIs −

per m itted(I1).

And because Is − pe rmitted(I1) ⊑ δIs − permitted(I1), we can deduce that

Jean is permitted to write diagnosis.

– Access Control if Context “Contamination-risk” is True. We have within orga-

nization X, context Contamination-risk holds between subject Jean, action Write

and object Diagnosis1, we obtain D3, an instance of concept Deﬁne.

Define(D3) ⊑ De f ineAc.Action(W rite) ⊓ DefineS.Subject(Jean)

⊓DefineO.Object(Diagnosis1)⊓Def ineC.Context(Contam ination−risk)⊓

DefineC.Context(normal) ⊓ DefineO r.Organization(X)

We know that context Contamination-risk is an exception of context normal,

DefineC.Context(Contam ination−risk) ≡ (Def ineC.Context(Normal))

If we substitute DeﬁneC.Context(Contamination-risk) by its value, we obtain:

δDef in e(D3) ⊑ δDef ine Ac.Action(W rite) ⊓ δDefineS.Subject(Jean)

⊓ δDefineO.Object(Diagnosis1) ⊓ δDefineC.Context(N ormal)

⊓ (Def ineC.Context(Normal))

⊓ δDefineOr.Organization(X)

Using the rule A

≡ δA ⊓ A

, we obtain:

(DefineC.Context(Normal))

≡ δDef ineC.Context(Normal)

⊓ (Def ineC.Context(Normal))

after replacment, we get:

δDef in e(D3) ⊑ δDef ine Ac.Action(W rite) ⊓ δDefineS.Subject(Jean)

⊓ δDefineO.Object(Diagnosis1) ⊓ (DefineC.Context(N ormal))

⊓ δDefineOr.Organization(X)

which means that: Define(D2)

⊑ δDef ine(D3)

In the context Contamination-risk, we create a new instance P3 which is deﬁned

as follow:

116

P ermission(P 3) ⊑ P er m isionAv.Activity(Modify)

⊓ P ermissionR.Role(Doctor) ⊓ P ermissionV.V iew(Di agnosis)

⊓P ermissionC.Context(Normal)⊓P ermissionC.Context(Contamination−

risk) ⊓ P erm issionOr.Organization(X)

Context Contamination-risk is an exception of context normal

P ermissionC.Context(Contamination−risk) ≡ (P ermissionC.Context(Normal))

After substitution, we get:

P ermission(P 3) ⊑ P er m isionAv.Activity(Modify)

⊓ P ermissionR.Role(Doctor) ⊓ P ermissionV.V iew(Di agnosis)

⊓ P ermissionC.Context(Normal) ⊓ (P ermissionC.Context(Normal))

⊓ P ermissionOr.Organization(X)

We know that, A

≡ δA ⊓ A

, we obtain:

P ermission(P 3) ⊑ P er m isionAv.Activity(Modify)

⊓ P ermissionR.Role(Doctor) ⊓ P ermissionV.V iew(Di agnosis)

⊓ (P ermissionC.Context(Normal))

⊓ P ermissionOr.Organization(X)

So, we can deduce: P ermision(P 2)

⊑ δP erm ission(P 3)

The question we can ask is: Is Jean permitted to write Diagnosis when context

Contamination-risk is true?

We have: -Jean play role of doctor in organization X: Employ(E1);

-and, Diagnosis1 is an object used in the view Diagnosis: Use(U3);

-and, Write is considered as a modiﬁcation activity: Consider(C1);

-and, by default, within organization X, context Contamination-risk holds between

subject Jean, action Write and object Diagnosis1: δDef ine (D3);

-and ﬁnally, by default, in organization X, each person who plays the role of Doc-

tor is permitted to modify Diagnosis, when context Contamination-risk is true:

δP ermission(P 3).

We obtain: Employ(E1) ⊓ Use(U 3) ⊓ Consider(C1) ⊓ δP ermission(P 3) ⊓

δDef in e(D3)

≡ Em ploy(E1) ⊓ U se(U 3) ⊓ Consider(C1) ⊓ δP ermission(P 2)

⊓ δDefine(D2)

≡ Em ploy(E1)⊓Use(U 3)⊓Consider(C1)⊓P ermission(P 2)

⊓Define(D2)

Using security rules, we can deduce that the precedent proposition subsume Is −

per m itted(I1)

. And because Is − permitted(I1) 6⊑ Is − permitted(I1)

, then

we can’t deduce Is-permitted(I1), and Jean is not permitted to write diagnosis when

there is a contamination risk.

5 Conclusions

The aim of this paper is to give a logical formalisation to DL

δǫ

-OrBAC model using

the expressive AL

δǫ

language. We showed how default and exceptional knowledge are

well suited to represent and reason about access control, we illustrate this fact with a

small example of medical information system.

To implement and reason about this model, we need to choose a reasoner which take

into account default and exceptional knowledge. There are many tools for the classical

description logic [11], we mention Classic, Fact++, RacerPro, but in our knowledge,

there is no tool for description logic with default and exception reasoner.

117

The next step of our work is to develop such a reasoner. N eo−Classic

δǫ

is actually

our preoccupation.

References

1. F. Coupey and C. Fouquer´e. Extending conceptual deﬁnitions with default knowledge. Com-

putational Intelligence, Vol 13, Num 2, 1997.

2. F.M. Donini, M. Lenzerini, D. Nardi, B. Hollunder, W. Nutt and M. Spaccamela. The com-

plexity of existential quantiﬁcation in concept languages. Artiﬁcial Intelligence, 53:309-

327,1992.

3. B. Lampson. Protection. In 5th Princeton Sympoium on Information Sciences and Systems,

March 1971, pp. 437- 443.

4. D.E. Bell and L.J. LaPadula. Secure computer systems: Uniﬁed exposition of multics inter-

pretation. Tech. Rep. ESD-Tr-73-306, The MITRE Corporation, March 1976.

5. K.J. Biba. Integrity consideration for secure computer systems. Tech. Rep. MTR-3153, The

MITRE Corporation, June, 1975.

6. R. Sandhu, E.J. Coyne, H.L. Feinstein and C.E. Youman. Role based access control models.

In IEEE Comuter, Vol. 29, no. 2, pp. 38-47, 1996.

7. A. Abou El Kalam, R. El Baida, P. Balbiani, S. Benferhat, F. Cuppens, Y. Deswarte,

A. Mi`ege, C. Saurel, and G. Trouessin. Organization Based Access Control. In 4th IEEE

International Workshop on Policies for Distributed Systems and Networks (Policy’03), Lake

Come, Italie, June 2003.

8. F. Baader, D.L. McGuiness, D. Nardi and P.F. Schneider. The Description logic handbook:

Theory, Implementation and Applications. Cambridge university press, 2002.

9. B. Nebel. Reasoning and revision in hybrid representation systems. In Lecture Note in

Computer Science, Springer-Verlag, 1990.

10. N. Boustia and A. Mokhtari. Representation and reasoning on OrBAC. In The Third Inter-

national Conference on Availability, Security and Reliability, Barcelona, Spain,2008.

11. http://www.cs.man.ac.uk/ sattler/reasoners.html

118