A Contextual Access Control ModelNarhimene Boustia Saad Dahlab University of Blida, Algeria

Email: narhimene@hotmail.comAicha Mokhtari LIPN, Paris 13 University, France

Email: aissani mokhtari@yahoo.fr, ma@lipn.univ-paris13.fr

Abstract—The proposed access control model is based ondescription logic (DL) augmented with a default (δ) and anexception (ε) operators to capture context feature. Our modelis inspired from OrBAC model and has an expressivity almostcomparable to it, which means assigning authorization to a useraccording to its role in an organization in a given context.The most important difference of our model is the allow ofcomposed context, the add of new context and the deductionof new authorization depending on context.

keywords: Access Control, OrBAC model, Context, De-scription Logic, Defaults and Exceptions, Reasoner.

I. INTRODUCTION

Access control consists in deciding whether the agentthat issues a request should be trusted on this request.

Almost all studies on access control and authorizationsystem have assumed the following model: “ a user makesan access request of a system in some context, and thesystem either authorizes the access requestor or deniesit”.

Recently, different formalizations were developed foraccess control model. These include industry standardssuch as XACML (eXtensible Access Control MarkupLanguage) [2], but also academic efforts ranging frommore practical implemented languages such as Ponder [3],to theoretical languages such as in [4], semantic web basedlanguages such as Rei [5] and KAoS [6], and finally todescription logic for RBAC model [18], [19], [20], [21],[22]. In this framework, permissions are assigned to a useraccording to its role. This is insufficient: authorization canchange with the context (exceptional contexts). The lack ofexception features in these approaches is not innofensive,it can leads to an incoherent system.

OrBAC (Organization Based Access Control) [1] is anaccess control model in which authorization is given tousers depending on their role in an organization in a givencontext. The problem is that OrBAC is formalize in firstorder logic in which context is represented by an argumentin a predicate Permission(organization, role, view, activity,context).

In this paper, we propose another solution to take intoaccount the context. We use the JClassicδε system [23],developped by us for this purpose. It is a descriptionlogic based system augmented with two operators δ (fordefault) and ε (for exception)1 This kind of non monotonicreasoning in description logic is not sufficintly developed

1.

(see the recommendation of the Handbook of Descriptionlogic [9]). Actually, there is no system, in our sens,developed on this kind of reasoning in the web. Thewell known system as C-Classic, NeoClassic, Loom, Racer,Fact++ ... are all based on monotonic reasoning [10], [11],[12], [13], [14], [15], [16]. The use of our system in dynamicaccess control is interesting for many reasons: it allowsfor compounded context, adding of a new context and thededuction of new authorization depending on context.

Moreover, it is known that DLs are well adapted tomodelize information system [9], [26]. This confort ourchoise to use DLs to provide access control with therepresentation of concepts such as user, role, object,...

The paper is structured as follow. We describe in thefirst one the key features of our tool JClassicδε [23], whichis the reasoner used to infer authorization. In the secondpart, we provide a new policy language and show howauthorizations can be deduce with a case study. Finally, weconclude by prospects of evolutions of our access controlmodel.

II. JClassicδε

Description logics are a family of knowledge represen-tation formalisms that stem from KL-ONE[17].

Several systems have been built based on DL[10],[11], [12], [13], [14], [15], [16], and used in real worldapplications. Besides, DLs facilitate the use of backgroundknowledge and are more expressive than attribute valuerepresentations.

In DLs, a concept is defined as a set of propertiessatisfied by individuals that are instances of the concept.These properties are expressed by terms that are built fromatomic concepts and roles and from a set of connectives.Concepts are partially ordered by a subsumption relationwhich expresses the inclusion relation between conceptsand is usually based on a standard model based logicalsemantics.

C-Classic is a knowledge representation system basedon description logic. C-Classic is equivalent to Classic[10], [11] augmented by the connective MIN and MAXwhich allow set of real to be defined. It is one of the mostexpressive previously known tractable DL, which preservesits good computational properties for subsumption. C-Classic is represented with an intentional semantic, whichis more interesting than an extentional semantic (it iseasier to compare two concepts by the use of their set

2010 International Conference on Broadband, Wireless Computing, Communication and Applications

978-0-7695-4236-2/10 $26.00 © 2010 IEEE

DOI 10.1109/BWCCA.2010.71

200

2010 International Conference on Broadband, Wireless Computing, Communication and Applications

978-0-7695-4236-2/10 $26.00 © 2010 IEEE

DOI 10.1109/BWCCA.2010.71

200

2010 International Conference on Broadband, Wireless Computing, Communication and Applications

978-0-7695-4236-2/10 $26.00 © 2010 IEEE

DOI 10.1109/BWCCA.2010.71

200

2010 International Conference on Broadband, Wireless Computing, Communication and Applications

978-0-7695-4236-2/10 $26.00 © 2010 IEEE

DOI 10.1109/BWCCA.2010.71

200

,

,

of properties than by their set of instances), and forour purpose, it is easier to add default and exceptioncharachteristics to concepts and roles properties than tothe instances.

Our JClassicδε is a combinaison of ALδε a descriptionlogic augmented with default and exception [8] and C-Classic formalism [10], [11], it have the particularity to bepossibly used in practical case. It not only allows repre-sentation of default knowledge and exceptional knowledge,but also infers and deduces new knowledge using tractablealgorithms.

The subsumption relation in JClassicδε, which is centralto deducing access control, is presented in section 2.2.Knowledge is mainly separated into two components:a terminological component (TBox) which contains theterminological definition of concepts and roles and as-sertional components (ABox) contaning statements aboutindividuals.

A. Terminological Language

The connectives of JClassicδε are for the moment,the ones of ALδε [8]. The terminological language ofJClassic−δε is defined using a set R of atomic roles, a set Pof atomic concepts, the constant > (Top) and the followingsyntactic rules (C and D are concepts, P an atomic concept,and R an atomic role):C,D → > the most general concept

| ⊥ the most specific concept| P primitive concept| C uD concept conjunction| Minu u is a real number| Maxu 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 (min)| R AT-MOST n cardinality for R (max)| ¬P negation of primitive concept2

| ∀r : C C is a value restriction on all roles| δC default concept| Cε exception to the concept

δ and ε are unary connectives, u is a binary conjunctionconnective and ∀ enables universal quantification on rolevalues.

B. Subsumption Algorithm SubδεSubδε is composed of 2 stages. The first is a normalisa-

tion of descriptions. The second is a syntactic comparisonbetween normal forms.

Let C and D be two terms of JClassicδε. To answerthe question “Is C subsumed by D?” we apply the nextprocedure. The normal forms of C and “C u D” arecalculated with the procedure of normalisation.

There are two steps in the comparison. We compare thestrict parts of the two concepts. If these are equal, then

2This restriction to primitive concept in the negation, and the lack ofdisjunction connective is a choise to avoid the untractability

we compare the default parts. If the two normal forms areequal, the algorithm returns “Yes”. Else it returns “No”otherwise.

In the next section we present our new access controlmodel inspired by OrBAC model using JClassicδε.

III. THE ACCESS CONTROL MODEL

As in OrBAC model, the central entity is Organization.An Organization can be seen as an organized group of sub-jects, each playing a specific role. In our medical domainexample, we consider an “hospital” as an Organization,“Jean” as a Subject, “Read” as an Action and “Medicalrecord” as an Object which are respectively abstractedinto Role, Activity and View [1].

A Role is a set of Subjects to which the same securityrule applies. For example, the subject “John” plays the roleof “Doctor” in the organization “Service of Pediatrics”.A View corresponds to a set of Objects that satisfy acommon property. For example, in the medical domain, theview “Medical record” corresponds to the object “Medicalrecord of patient”. An Activity groups together Actions thatpartake of the same principle. Actions will mainly containcomputer actions such as “read”, “write”,etc, whereas Ac-tivities contain “consulting”, “writing”,etc. Privileges onlyapply in specific contexts. In OrBAC, Contexts are usedto specify the concrete circumstances where organizationsgrant role permission to perform activities on views [7]. Inour model, we take into account the context by consideringthe following postulate.

Postulate 1 (Normal context). By default, the context isnormal.

Contrary to OrBAC model, our authorization modelconsiders that:

Postulate 2. All actions that are not permitted are prohib-ited.

In this case, it suffice to defines permission relation.

The seven basic sets of entities of OrBAC are adaptedhere: OR (set of organizations), S (set of subjects), AC (setof actions), O (set of objects), R (set of roles), AV (set ofactivities) and V (set of views).

We now conceptualize access control model by a DLknowledge base capturing its characteristics, including thecontext with the use of defaults (δ) and exceptions (ε).We define then TBox and ABox axioms with examples toillustrate their content and use. We conclude in section3.3 with a case study in which we demonstrate how anauthorization can be deduced in each context variation bythe use of our reasoner [24], [25].

A. The TBox

We define a DL knowledge base K. The alphabet ofK includes the following atomic concepts: Organization,Subject, Object, Role, View, Action and Activity. The TBoxis as follow:

201201201201

TBoxRole attribution axiom:Subject v >;Role v >;Organization v >;Employ v EmployS.Subject u EmployR.Role u EmployOr.Organization;View definition axiom:Object v >;V iew v >;Use v UseO.Object u UseV.V iew u UseOr.Organization;Activity definition axiom:Action v >;Activity v >;Consider v ConsiderAc.Action u ConsiderAv.Activity u ConsiderOr.Organization;To define a default permission, we use the following axiom:δPermission v PermisionAv.Activity u PermissionR.Role u PermissionV.V iewuPermissionOr.Organization;To define a relation of hierarchy between roles, we introduce the following axiom:Sub− role v Sub− role1.Role u Sub− role2.Role u Sub− roleOr.Organization;A concrete permission is expressed with the next axiom:Is− permitted v Is− permittedAc.Action u Is− permittedS.SubjectuIs− pemittedO.Object;

TABLE IABOX

Definition of rules of security:δIs − permitted v Employ u Use u Consider u

δPermission

- If a subject S is employed by organization Or in arole R (Employ), and if there is a relation betwwen actionAc and activity Av (Consider), and if there is a relationbetween an object O and a view V (Use), and if we haveby default a permission relation between role R, activityAv and a view V in an organization Or (δPermission), wededuce that a subject S is by default permitted to performaction Ac on object O (δIs − permitted), and becauseIs − permitted v δIs − permitted (a concrete permisioncan be deduced from a default permission), we can finallysay that a subject S is permitted to perform an action Acon object O.

Is− permittedε v Employ u Use u Consider uPermissionε

- By cons, if we have an exception on a permissionconcept wrote Permissionε, we say that we have an ex-ception on a concept Is-permitted wrote Is− permittedε,and because Is−permitted 6v Is−permittedε (a concretepermission can not be deduced from an exceptional per-mission), we can deduce that a subject S is prohibited toperform an action Ac on object O.

B. The ABox

The ABox of K includes seven catalogs of axioms:Organization assertion’s axiom, Subject assertion’s axiom,Object assertion’s axiom, View assertion’s axiom, Roleassertion’s axiom, Action assertion’s axiom and Activityassertion’s axiom.

It contains statment about individuals. We could havemany ABox for one TBox depending on applications.

We illustrate this in the next section, we show how asecurity policy can be modelized in our framework andhow we can infer authorizations.

In the next section, we present an example of oneABox of our medical system information to show howauthorization can be deduce.

C. Case Study

To illustrate how authorization can be deduce, we usethe following instances of the ABox:

- Using the previous instances, the system infers that inorganization X, each person who play the role of Doctoris by default permitted to modify Diagnosis and add thisinstance to the ABox : δPermission(P1).

Where:δPermission(P1) v PermisionAv.Activity(Modify)u PermissionR.Role(Doctor) uPermissionV.V iew(Diagnosis)u PermissionOr.Organization(X)

Using the previous ABox, we show how deduction canbe done in differents contexts.• Permission hierarchy: we show first how authorization

can be deduced when we have an hierarchy of roles.

We know that a Surgeon is a sub-role of Doctor, sowe can write:Sub− role(S1) v Sub− role1.Role(Surgeon)uSub−role2.Role(Doctor)u Sub− roleOr.Organization(X)

If we want to know if a Surgeon is permitted to writean ordinnance, we use the following rules:δPermission(PE1) vPermisionAv.Activity(Modify)u PermissionR.Role(Doctor) u

202202202202

ABoxOrganization(X);Role(Doctor); Role(Surgeon);Subject(Jean);View(Diagnosis);Object(Diagnosis1);Action(Write);Activity(Modify);Employ(E1) v EmployS.Subject(Jean) u EmployR.Role(Doctor)uEmployOr.Organization(X);Use(U1) v UseO.Object(Diagnosis1) u UseV.view(Diagnosis)uUseOr.Organization(X);Consider(C1) v ConsiderAc.Action(Write)uConsiderAv.Activity(Modify) u ConsiderOr.Organization(X);

TABLE IIABOX

PermissionV.V iew(Ordinnance)u PermissionOr.Organization(X)

δPermission(PE2) vPermisionAv.Activity(Modify)u PermissionR.Role(Surgeon) uPermissionV.V iew(Ordinnance)u PermissionOr.Organization(X)

And because we have defined the concept of Sub-role,the inheritance is expressed as follows:

δPermission(PE2) v δPermission(PE1) u Sub −role(S1)

The answer in this case is Yes because we use theinheritance of properties in the default case.

• Access control in a default context: Suppose that userJean want to write diagnosis1, can he obtain thisprivilege?

We know that:-Jean play role of doctor in organization X: Em-ploy(E1);-and, Diagnosis1 is an object used in the view Diag-nosis: Use(U1);-and, Write is considered as a modification activity:Consider(C1);-and finally, by default, in organization X, eachperson who plays the role of Doctor is permittedto modify Diagnosis, when Normal context is true:δPermission(P1).Formally, we write:

Employ(E1) u Use(U1) u Consider(C1) uδPermission(P1)

Using security rules, we can deduce that the precedingproposition subsumes δIs− permitted(I1).Where:Is − permitted(I1) v Is −permittedAc.Action(Write)u Is − permittedS.Subject(Jean) u Is −pemittedO.Object(Diagnosis1)

And because Is − permitted(I1) v δIs −permitted(I1), we can deduce that Jean is permittedto write diagnosis.

• Access control if context “Contamination-risk” istrue: Suppose that there is a contamination risk andJean want to write diagnosis1, did he have this right?

In the context Contamination-risk, the system deducea new instance P2 which is defined as follows:

δPermission(P2) v PermisionAv.Activity(Modify)u PermissionR.Role(Doctor) uPermissionV.V iew(Diagnosis)u PermissionOr.Organization(X)

And we add to the ABox the next rule:Permision(P1)ε v δPermission(P2)

We know that:-Jean plays role of doctor in organization X: Em-ploy(E1);-and, Diagnosis1 is an object used in the view Diag-nosis: Use(U1);-and, Write is considered as a modification activity:Consider(C1);-and finally, by default, in organization X, each personwho plays the role of Doctor is permitted to modifyDiagnosis, when context Contamination-risk is true:δPermission(P2).We obtain:

Employ(E1) u Use(U1) u Consider(C1) uδPermission(P2)≡ Employ(E1) u Use(U3) u Consider(C1) uδPermission(P1)ε

We know that Aε ≡ δAε, we obtain:

≡ Employ(E1) u Use(U1) u Consider(C1) uPermission(P1)ε

Using security rules, we can deduce that the precedentproposition subsumes Is− permitted(I1)ε.

And, because Is − permitted(I1) 6v Is −

203203203203

permitted(I1)ε, we can’t deduce Is-permitted(I1).Therefore Jean is not permitted to write diagnosis1when there is a contamination risk.

Our policy language allows us to have more than oneexception in a context.• Access control if context “Fatal-Desease” is true: a

new context appearn and Jean want to write diagnosis,can he get this right? We illustrate here an exampleof exception of exception case.

In the context Fatal-Desease, the system deduce a newinstance P3 defined as follows:

δPermission(P3) v PermisionAv.Activity(Modify)u PermissionR.Role(Doctor) uPermissionV.V iew(Diagnosis)u PermissionOr.Organization(X)

We know that permission in a ContextContamination-risk is an exception of permissionin a context normal, and permission in a contextFatal-Desease is an exception of permission in acontext Contamination-risk (we have an exampleof exception of an exception), then we augment theABox by the rule:

Permission(P2)ε v δPermission(P3)

We have:-Jean plays role of doctor in organization X: Em-ploy(E1);-and, Diagnosis1 is an object used in the view Diag-nosis: Use(U1);-and, Write is considered as a modification activity:Consider(C1);-and finally, by default, in organization X, eachperson who plays the role of Doctor is permitted tomodify Diagnosis, when context Fatal-Desease is true:δPermission(P3).We obtain:

Employ(E1) u Use(U1) u Consider(C1) uδPermission(P3)≡ Employ(E1) u Use(U1) u Consider(C1) uδPermission(P2)ε

≡ Employ(E1) u Use(U1) u Consider(C1) uδ(Permission(P1)ε)ε

Using the rule δA ≡ δ(Aε)ε, we obtain3

≡ Employ(E1) u Use(U1) u Consider(C1) uδPermission(P1)

Using security rules, we can deduce that the precedentproposition subsumes δIs− permitted(I1).

We know that Is − permitted(I1) v δIs −permitted(I1), so we can deduce Is-permitted(I1).

3Exception at an even level cancel the effects of exceptions and thereforeinfers the property by default

Therefore Jean is permitted to write diagnosis whenthe desease is fatal.

We illustrate by this example, one of our main result,which is to consider the context dynamically, and inferthe authorization to each context changing.

IV. CONCLUSION AND FUTURE WORKS

In this paper, we presented an approach for an accesscontrol authorization with concept and role by means ofDL with default and exception. To summarize our result,we have:

- developed a model based on the main concepts ofOrBAC: organization, subject, role, object, view, action,activity and context. However, instead of defining contextas argument, we point out that it is more coherent to usethe two operators of default and exception.

- provided an algorithm for the main computationaltasks of classifying concepts under strict and defaultconditions without increasing the complexity of equivalentexpressivity reasoner.

An interseting topic for future research is to extendour system to take into account other connectives forexample the disjunction operator to make our system moreexpressive with keeping a reasonable complexity. We alsowant to consider time as contextual information.

REFERENCES

[1] A. Abou El Kalam, R. El Baida, P. Balbiani, S. Benferhat, F. Cup-pens, Y. Deswarte, A. Miege, C. Saurel, and G. Trouessin. Organi-zation Based Access Control. In 4th IEEE International Workshopon Policies for Distributed Systems and Networks (Policy’03), LakeCome, Italie, June 2003.

[2] T. Moses and all. eXtensible Access Control Markup Language(XACML) version 2.0. OASIS Standard 200502, 2005.

[3] N. Damianou, N. Dulay, E. Lupu, M. Sloman. The ponder policyspecification language. In Lecture Notes in Computer Science 1995,2001.

[4] S. Jajodia, P. Samarati, V. Subrahmanian. A Logical languagefor Expressing Authorizations. In Proc 1997 IEEE Symposium onSecurity and Privacy, 1997.

[5] L. Kagal, T. Finin, A. Joshi. A policy language for pervasive systems.In 4th IEEE Int. Workshop on Policies for Distributed Systems andNetworks, 2003.

[6] G. Tonti, J.M. Bradshaw, R. Jeffers, R. Montanar, N. Suril,A. Uszokl. Semantic web languages for policy representation andreasoning: A comparison of Kaos, Rei and Ponder. In Proceedingsof the 2nd International Semantic Web Conference (ISWC2003),Springer-Verlag, 2003.

[7] F. Cuppens, A. Miege. Modelling Contexts in the ORBAC Model. In19th Annual Computer Security Applications Conference, Las Vegas,December 2003.

[8] F. Coupey and C. Fouquere. Extending conceptual definitions withdefault knowledge. Computational Intelligence, Vol 13, Num 2, 1997.

[9] F. Baader, D.L. McGuiness, D. Nardi and P.F. Schneider. The De-scription logic handbook: Theory, Implementation and Applications.Cambridge university press, 2008.

[10] R.J. Brachman, D.L. McGuinness, P.F. Patel-Schneider, L. AlperinResnick, and A. BorgidaN. Living with CLASSIC: When and Howto Use a KL-ONE-Like Language. In John Sowa, ed., Principles ofSemantic Networks: Explorations in the representation of knowledge,Morgan-Kaufmann: San Mateo, California, 1991, pages 401–456.

[11] R.J. Brachman, D.L. McGuinness, L. Alperin Resnick, andA. Borgida. CLASSIC: A Structural Data Model for Objects. InProceedings of the 1989 ACM SIGMOD International Conference onManagement of Data, pages 59–67, June 1989.

[12] http://owl.man.ac.uk/factplusplus/, 2007.

204204204204

[13] http://www.racer-systems.com/products/racerpro/index.phtml, 2010.[14] http://www.cs.man.ac.uk/ sattler/reasoners.html, 2010.[15] http://www.kaon2.semanticweb.org, 2003.[16] http://www.clarkparsia.com/pellet, 2009.[17] R.J. Brachman. A structural paradigm for representing knowledge.

In Technical report 3605, BBN Report, 1978.[18] C. Zhao and all. Representation and Reasoning on RBAC: A

Description Logic Approach In Theoretical Aspects of Comput-ing,ICTAC, 2005.

[19] M. Knechtel and all. RBAC Authorization Decision with DLReasoning. In Proceedings of the IADIS International ConferenceWWW/Internet, 2008.

[20] T. Finin and all. ROWLBAC - Representing Role Based AccessControl in OWL. In Proceedings of the 13th Symposium on Accesscontrol Models and Technologies, June 2008.

[21] T. Finin and all. Role Based Access Control and OWL. In Pro-ceedings of the fourth OWL: Experiences and Directions Workshop,April 2008.

[22] M. Knechtel and all. Using OWL DL Reasoning to Decide AboutAuthorization in RBAC. In Proceedings of the OWLED 2008Workshop on OWL: Experiences and Directions, 2008.

[23] N. Boustia, A. Mokhtari. JClassic−δε to reason on default andexceptional knowledge. In Internal report, n◦ 39/ 09, LRIA, USTHB,Algeria, 2009.

[24] N. Boustia and A. Mokhtari. Representation and reasoning onORBAC: Description Logic with Defaults and Exceptions Approach.In Workshop on Privacy and Security - Artificial Intelligence (PSAI),ARES’08, Spain, 2008.

[25] N. Boustia and A. Mokhtari. DLδε − OrBAC: Context basedAccess Control. In WOSIS’09, Italy, 2009.

[26] M. Collinson and all. Algebra and Logic for Access Control. InFormal Aspects Computing, 2009.

205205205205