Using Description Logics in Relation Based Access Control

Abstract

Relation Based Access Control (RelBAC ) is an access control model designed for the new scenarios of access control on Web 2.0. Under this model, we discuss in this paper how to formalize with Description Logics the typical authorization problems of access control together with the enforcement of an important security property: Separation of Duties (SoD) and some high level security policies about the composition of those subjects on which to separate the duties.

Introduction

Access control is an important branch of computer security. Nowadays, access control models become more and more complex in order to represent the dynamics of the subject, i.e., the new scenario where objects and permissions of access control are located on the web. Early access control models, such as Mandatory Access Control and Discretionary Access Control, have evolved to more complex models such as Role-Based Access Control (RBAC) [ 4 ] and, most recently, Relation-Based Access Control (RelBAC ) [ 8 ]. Complex models, such as RBAC, have been deeply studied and many logical formalisms have been proposed to formalize their access control policies. In particular, it has been shown how RelBAC can be used to model access control in terms of lightweight ontologies [ 6, 7, 18 ] of users, objects and permissions, and how this can be exploited to automatically manage permissions.

In this paper, we discuss how to formalize the typical authorization problems in the RelBAC model with a speci c Description Logic (DL), i.e., the DL ALCQIBO [ 13, 14, 16 ]. RelBAC is a new model designed specially for the various dynamic scenarios of Web 2.0 in [ 8 ]. It is natural and exible such that it is easy to understand and use for personal resources of an ordinary web user (see, e.g., photos on Flickr1). The main feature of RelBAC is that a permission, intuitively the operation allowed to be performed on some resource, is modeled as a binary relation between a set of subjects and a set of objects. Furthermore, it is exible enough to enforce cardinality related access such as to restrict that `anonymous users can view no more than 5 of my photos'. RelBAC is formalized

1 http://www. ickr.com

with an access control domain speci c Description Logic in order to provide formal syntax and semantics plus an automated reasoning mechanism to facilitate the access control management.

The contributions of this paper are as follows: { Focusing on authorization problem of RelBAC , we discuss the usage of DL to formalize access control policies. { Di erent formalizations of Separation of Duties (SoD ) are analyzed as an important security property. { Dynamic SoD and high-level security policies about SoD are also formally represented and discussed.

The rest of the paper is organized as follows. Section 2 describes the DL exploited to capture the access control problems. Section 3 discusses the expressiveness of the proposed DL to faithfully capture the RelBAC application domain. In Section 4 we discuss the logical formalization of a security property, i.e., Separation of Duties. The related work is summarized in Section 5 and we make our concluding remarks in Section 6. 2

The Description Logic ALCQI BO The logic ALCQIBO extends the description logic ALC [ 1 ] with quali ed cardinalities, inverse roles, nominals and Boolean for roles (see [ 16, 14, 13 ] for extensions of DLs with Booleans between roles). We de ne the syntax of ALCQIBO as follows.

De nition 1 (ALCQIBO Syntax). Let NC, NR and NI be pairwise disjoint and countably in nite sets of concept names, role names and individual names. Then concept expressions and role expressions are de ned as follows: C; D ::= A j :C j C u D j R; S ::= P j R j :R j R u S n R:C j faig where A 2 NC, P 2 NR, ai 2 NI and n 2 N.

A Knowledge Base (KB) is a pair K = hT ; Ai where T , called TBox, is a nite set of general concept inclusions (GCIs) of the form C v D and a nite set of general role inclusions (GRIs) of the form R v S, while A, called ABox, is a nite set of concept and role assertions of the form C(ai) and R(ai; aj ), with ai; aj 2 NI.

An ALCQIBO-interpretation, I, is a pair ( ; I ) where is a non-empty set called the domain of I and I is a function mapping each A 2 NC to a subset AI and each P 2 NR to a relation P I . Furthermore, I applies also to individuals by mapping each individual name ai 2 NI into an element aiI 2 such that aiI 6= ajI , for all i 6= j, i.e., we adopt the so called unique name assumption (UNA). We extend the mapping I to complex roles and concepts as follows: (R )I := f(y; x) 2 (:R)I :=

j (x; y) 2 RI g; n RI ; (:C)I :=

n CI ; (R u S)I := RI \ SI ; (C u D)I := CI \ DI ; (> n R:C)I := fx 2 j ]fy 2 j (x; y) 2 RI and y 2 CI g ng; faigI := faiI g: An ALCQIBO-interpretation I = ( ; I ) is said a model of a KB, K, i it satis es CI DI , for all C v D 2 K, RI SI , for all R v S 2 K, aiI 2 CI , for all C(ai) 2 A, and (aiI ; ajI ) 2 RI , for all R(ai; aj ) 2 A. In this case we say that K is satis able and write I j= K. A concept C (role R) is satis able w.r.t. K if there exists a model I of K such that CI 6= ; (RI 6= ;).

As usual, we can de ne a number of useful abbreviations:

C t D for :(:C u :D) (6 n R:C) for :(> n + 1 R:C) (= n R:C) for :(> n + 1 R:C) u (> n R:C) 9R:C for (> 1 R:C) 8R:C for (6 0 R::C) > for A t :A (for some concept A) ? for :>

U for R t :R (for some role R)

Note that, TBox axioms can be internalized. Indeed, we can encode each axiom C v D as the concept expression 8U :(:C t D), while each role axiom R v S can be encoded as the concept expression 8U :8(R u :S):?. (To encode ABox assertions as concept expressions see [ 16 ]).

Concerning the complexity of ALCQIBO, KB satis ability can be reduced to reason over the two-variable rst-order fragment with counting quanti ers which is NExpTime-complete [ 15 ]. On the other hand, Boolean modal logic is a proper sub-language of ALCQIBO and it is NExpTime-complete [ 13 ]. Summing up, reasoning in ALCQIBO is NExpTime-complete. 3

The Authorization Problem in RelBAC

Here we discuss the authorization problem, which deals with questions like `who is authorized to access what'. We distinguish two di erent phases: general authorizations on group of users and sets of resources, and ground authorizations onto individual users and/or resource instances. 3.1

General Authorizations

In RelBAC , a generic permission P (e.g., Write) is modeled as a binary relation between a class of users U (e.g., SW-Developer) and a class of objects O (e.g., Java-Code). The following general constraints can be captured in ALCQIBO. 1. `The permission P applies only between users U and objects O'.

This is a form of domain and range constraint for the binary relation P and can be modeled in ALCQIBO with the following axioms:

Domain Restriction

Range Restriction 9P:> v U 9P :> v O 2. `Users in U can access just objects in O with P ' `Objects in O can be accessed just from users in U with P '.

We can represent these constraint using universal restrictions as: U v 8P:O Universal Restriction

O v 8P :U Universal Restriction 3. `Users in U are allowed to access (with P ) at most n objects in O' `At most n users in U are allowed to access any given object in O with P '. We can represent these constraints using cardinality constraints as: U v (6 n P:O) Cardinality Restriction

O v (6 n P :U ) Cardinality Restriction 4. `Users in U have access to at least m objects in O with P ' `At least m users in U have access to any object in O with P '.

We can represent these constraints using cardinality constraints as: U v (> m P:O) Cardinality Restriction

O v (> m P :U ) Cardinality Restriction 5. `All users in U have access to all objects in O with P ' `All objects in O are accessed by all users in U with P '.

This rule de nes a so called Total Access Control rule (TAC) and can be captured using the negation of roles constructor in cardinality restriction: U v 8:P::O O v 8:P ::U

TAC Rule

TAC Rule 3.2

Ground Authorizations

Using the ABox mechanism of ALCQIBO we can assert particular facts associated to given individuals of the domain. The following is a list of the most common assignments concerning single individuals that can be captured in ALCQIBO (in the following u and o are individuals in NI, P is a role in NR, U and O are concepts in NC). 1. `The user u is allowed to access the object o with P '.

This is represented as: P (u; o).

For example, U pdate(david; mb903ll=a) says that `David is allowed to update the entry MB903LL/A'. 2. `The user u is allowed to access maximum n objects in O with P '.

This is represented as: (6 n P:O)(u).

For example, (6 5 U pdate:Digital)(David) says that `David is allowed to update maximum 5 entries of Digital'. 3. `The user u is allowed to access minimum n objects in O with P '.

This is represented as: (> n P:O)(u).

For example, (> 5 U pdate:Digital)(David) says that `David is allowed to update minimum 5 entries of Digital'. 4. `The user u is allowed to access all objects in O with P '.

This is represented as: (8:P::O)(u).

For example, (8:U pdate::Digital)(David) says that `David is allowed to update all entries in Digital'. 5. `Minimum n users in U are allowed to access the object o with P '.

This is represented as: (> nP :U )(o).

For example, (> 3 U pdate :Apple)(mb903ll=a) says that `At least 3 friends from Apple are allowed to update the entry MB903LL/A'. 6. `All users in U are allowed to access the object o with P '.

This is represented as: U v 9P:fog.

For example, Apple v 9U pdate:fmb903ll=ag says that `All friends from Apple are allowed to update the entry MB903LL/A'.

Besides the traditional access control rules which can specify only `one-toone' and `one-to-many' mappings about individuals, we see that the ABox of ALCQIBO provides many ways to write a ground access control rule in RelBAC . Altogether, as is shown in Figure 1 (taken from [ 18 ]), RelBAC can specify 15 kinds of access control rules with a single DL axiom (counting minimum/maximum/equal cardinality restriction as one). These rules show, both the power of RelBAC as an access control model and the expressiveness of the logic to be able to capture this scenario. The cardinality related rules (formed with cardinality restriction) are important especially in those scenarios where number is a key factor for access control.

So far we discussed the permission assignments at design time. When an access control request arrives at run time the access control should decide whether to accept or deny these requests according to the assignments done at design time. Since a RelBAC system is an ALCQIBO KB, while a request is captured by an ABox, then at run time the system decides to grant an access if by adding the ABox to the current KB the resulting KB is satis able. 4

Separation of Duties

Separation of Duties SoD is an important security property in modern access control systems. It enforces that more than one person is required to complete a task. In this section, we will discuss the general meaning of an SoD, its enforcement at design and run time and the high-level security policy [ 12 ] for an SoD. 4.1

General SoD

De nition 2 (Separation of Duties SoD ). An SoD states that, if a sensi

tive task consists of two steps, then two di erent users should perform mutually exclusive steps. More generally, when a sensitive task is composed of n steps, an SoD constraint requires the cooperation of at least k (for some k 6 n) di erent users to complete the task.

In one of the most well-known access control model, RBAC[ 4 ], SoD is enforced with the help of restrictions on the `roles2'. The SoD that `di erent users should perform two di erent steps of a task' can be enforced at design time by restricting any user from the assignments to the two roles, each of which is assigned the permission to carry out a step of the two. For a more general SoD that `di erent users should perform n di erent steps of a task', each step is modeled as an RBAC role Ri, and the SoD is formally expressed as the following formula: R1 u ::: u Ri u ::: u Rn v ?.

In RelBAC , a permission is a relation which links a subject with an object. To enforce this SoD in RelBAC , we can simply assert an axiom about the permissions. For example, suppose in a scenario of sales force automation3, to initiate, process, check and archive an order should not be completed by only one user. Suppose Initiate, Process, Check and Archive are four permissions with the same domain as users and co-domain as orders. The SoD above can be expressed in RelBAC as

Initiate u P rocess u Check u Archive v ? This policy restricts any pair (u; o) from belonging to all four sets Initiate, Process, Check and Archive.

In general, given n steps of a task step1; :::; stepn, the SoD requires at least k (k 6 n) users can ful ll all these n steps. Suppose any of the k users can ful ll 2 To be di erentiated from a DL role, the `role' in the RBAC model is a component simulating the real world enterprise organism. A user can only execute a permission assigned to the role that s/he can activate. 3 http://www.salesforce.com (k 1) m < n i:e: m 6 dn=(k 1)e 1 because k; m; n are all integers. This means intuitively that any user can be assigned to at most m of these duties as restricted in Formula 1. Thus, any m + 1 of these duties should not be assigned to one user. Then RelBAC can enforce the SoD with the following axiom: maximum m steps. In the worst case, everyone can ful ll equal number of steps, and satis es the following DL axiom: (1) (2) Cndn=(k 1)e dn=(k 1)e

G ( l i=1 j=1

Pij ) v ? in which Pij stands for one of the m permissions for each step, and Cnk is the binomial coe cient of `n choose k'.

Following the example above, given the 4 duties in the SFA scenario, an SoD requires that at least 3 users should be involved. This SoD can be enforced as follows.

(Initiate u P rocess) t (Check u Initiate) t (P rocess u Archive)t (P rocess u Check) t (Archive u Initiate) t (Check u Archive) v ? as Cndn=(k 1)e = Cd4=2e = C42 = 6.

4

An SoD can be enforced both at design and at run time. Up to now, we have discussed the SoD designed by the administrator o -line. An SoD enforced at run time intuitively means that the duties to be separated can be assigned to one user during design, but cannot be executed by her simultaneously.

RBAC ful lls it with the concept of session as representatives of the user at run time by restricting sessions from activation of separated roles. To enforce an SoD at run time, the concept of `session' has been introduced in the RBAC model. At run time, a user activates sessions to execute permissions. The duties assigned to the user at design time and restricted to be executed simultaneously are separated by enforcing that no session can execute them at the same time.

In RelBAC , we do not need the concept of `session', but use a run time permission to describe the state of a permission in execution to enforce SoD at run time.

De nition 3 (Run Time Permission - RTP ). A RTP describes the current

execution of a permission. We assume that the name of a RTP is formed by alternating the verb (phrase) denoting the permission into the present participle of the verb (phrase). A user cannot be assigned to a RTP unless she has the permission for the original permission.

For each RelBAC permission, a RTP is introduced. For example, assume that Initiating is the RTP for the permission Initiate. As said above, a user cannot execute the permission Initiating without having the permission Initiate. Now, the SoD `a user cannot initiate and process an order at the same time ' is enforced as follows (we assume that both permissions have the same range, Order):

Initiating u P rocessing v ? In the real world, a user can be granted the permission to initiate an order (as a customer) and to process an order (as a sales agent), but cannot perform the two permissions (duties) simultaneously in order to avoid the process of one's own order.

Although an SoD can be enforced at design and run time with similar role axioms in RelBAC , the mechanisms regulating it are di erent. To enforce an SoD at run time, the monitoring mechanism should inform the access control system in real time, so that the current state such as Alice is initiating an order `Bolzano' should be recognized. Then the knowledge base should be updated with the new assertion Initiating(alice; bolzano). Therefore, the above SoD (ruling out the possibility of initiating and processing an order at the same time) in the KB K entails the following:

K t fInitiating(alice; bolzano)g j= :P rocessing(alice; bolzano) although Alice might have permissions to both initiate and process some order. For the general SoD property, the composition of the k users to complete the task is sometimes important. The administrator may like to constraint rst that these users are from certain groups, cardinality related constraints are also necessary for the composition.

N.Li et al. studied SoD in detailed requirements for speci c attributes of the users in addition to numbers of each kind of users. An algebra was proposed in [ 12 ] to specify complex policies combining requirements on user attributes and number. On top of the cardinality constraints for given duties, the algebra can specify the composition of the users for the SoD which they regard as high-level security policy. For example, beyond to restrict that at least 2 users should be involved for the 4 steps in the SFA schema of Section 4.1, it further enforces that the set of users that can complete the order ful llment task involve customer(s) to initiate the order and sales manager(s) to check the order. For example, the composition of the user set should be as follows. 1. At least one sales manager to check orders and at least one customer to initiate orders. 2. At least one sales manager and at least one customer and maybe some other sales manager or customer involved, but no others than those two kinds of users. 3. Exactly two users, one sales manager and one customer.

Case 1 means that a customer should be involved to initiate the order and a manager should be involved to check the order, for the other users, the administrator does not care who processes and archives the order. Case 2 speci es that only customer and manager can be involved which means the same manager (or some other manager) will take charge of the duties to process and to archive. Case 3 is the most strict by allowing only one customer and one manager to be involved.

RelBAC can achieve this kind of constraints with object-centric rules with the cardinality restriction constructor. For example, as for the cases above, the three constraints for the set of users can be formalized as follows.

Order v (> 1 Initiate :Customer) u (> 1 Check :M anager) Order v 8Involve:(Customer t M anager) u

(> 1 Initiate :Customer) u (> 1 Check :M anager) Order v (= 2 Involve:(Customer t M anager)) u (= 1 Initiate :Customer) u (= 1 Check :M anager) u :9 Involve:(Customer u M anager) Where Involve is a permission more general than any of the 4 permissions for the 4 duties in the above schema, i.e.

Initiate t P rocess t Check t Archive v Involve

This kind of high-level security policy complements the general SoD policy as discussed in Section 4.1 because it has the full power to describe the composition of the set of subjects including the exact cardinality. 5

Related Work

Description Logics [ 1 ] arouse the interests in the AI community for their expressiveness and decidability of the reasoning services. Various papers describe the use of Description Logics to formalize access control models and use state of the art Description Logic reasoners to formalize security properties and check their consistency (see, e.g. [ 2, 5, 8, 9, 18, 19 ]).

F.Giunchiglia et al. introduced in [ 8 ] the RelBAC model together with a domain speci c Description Logic as the formalism. RelBAC captures, with subsumption axioms, the dynamic hierarchies of the subjects, objects and permissions and provides, with cardinality restrictions, powerful cardinality related speci cations of access control rules. The theory of Lightweight Ontology [ 7 ] can be used to model the social community into ontologies as discussed in [ 9 ] and can facilitate the management of knowledge hierarchies and access control rules.

In [ 19 ] an early attempt was made by C.Zhao et al. to apply DLs to the representation of policies in the RBAC model. In their proposal, users, roles, sessions and permissions are formalized as DL concepts but objects are regarded as encapsulated inside permissions together with operations. This results in an explosion in the number of permissions and the corresponding di culty to specify policies about objects. Moreover, they proposed to use only the existential restriction constructor for permission assignments.

Another formalization of RBAC in DLs was proposed by J.Chae et al. [ 2 ], where an operation is represented by a DL role. Their system has several critical points, and in particular: { Miss use of existential quanti er. In the semantics of their formalization, the assignment with the formula `Admin v 9CanRead:Log' assigns to all administrators the read access to all log les. But the DL semantics of this formula enforces only the existence of some connections between administrators and log les. In our case, the TAC rules are introduced to cover precisely this case (see Sect. 3.1). { The formalization of `assign' and `classify' into DL roles seems redundant.

These DL roles are supposed to connect users to RBAC roles or object to object classes. We explicitly use an ABox mechanism to better deal with individuals.

However, their work is relevant for our approach since: { They inspired us in the way they formalized operation, i.e., by introducing a binary relation from a subject to an object. { They extended RBAC with the object hierarchy similar to the user hierarchy which facilitates the permission propagation.

Recently, T.Finin et al. proposed to use OWL4 language as the formalization of the RBAC model in [ 5 ]. They provide two ways to formalize a RBAC role, as a class or as an attribute. N3Logic is used together with DL subsumption reasoning. Authorization decision queries can be answered using DL reasoners in their system.

Another important work is related with the formalization of SoD. N.Li et al. studied SoD in [ 12 ], and proposed an algebra to specify the composition of the users that share the duties. In [ 11 ] N.Li et al. modeled the problem of an SoD of n duties among k users with a rst order logic formula as

k 1 8u1:::uk 1 2 U (( [ auth perms [ui]) 6 fp1:::png) i=1 (3) with universal quanti er on arbitrary k 1 users in space of U . Formula 3 speci es that the collection of all the permissions explicitly/implicitly assigned to this k 1 users should not be a superset of all the n steps of duties. Their solution has the complexity of (jU jk 1 n) which explodes to the cardinality of the subject space. In RelBAC , as shown in Formulas 2, our solution enforces a su cient but not necessary condition of the SoD because the `ceiling' operator (d e) is an approximation of the exact value for n=(k 1). For example, in the schema above, the representation are the same for k = 3 and k = 4. However the

4 http://www.w3.org/TR/owl-guide/

computational complexity is only (nn=k). Considering that the number of steps which is n, is far less than the number of users in the system, which is jU j, our method is more e cient than [ 11 ].

An existing industry standard is XACML [ 3 ] which is an XML based access control policy language without formal semantics such as in a logic. Kolovski et al. used DL to provide formal semantics for XACML in [ 10 ]. RelBAC , in contrast, is not only a new access control model, but also a logic with well de ned syntax and semantics to express web-based access control policies. 6

Conclusion

In this paper, we discussed a domain speci c Description Logic, i.e. ALCQIBO for access control, in which the reasoning is NExpTime-complete. Exploiting ALCQIBO to formalize the RelBAC model, we have been able to formalize the typical authorization problem of access control. Besides, we studied the formalization of an important security property which is the Separation of Duties (SoD ). Furthermore, di erent aspects of SoD can be formalized in ALCQIBO such as dynamic SoD and high level security policy of SoD.

A basic version of RelBAC has been implemented as described in [ 18 ]. But the evaluation results with a general purpose DL reasoner, Pellet [ 17 ], are not good enough to achieve real-time response. The future work of this direction is to adapt such general purpose DL reasoners to access control knowledge bases for more e cient reasoning.

References

1. Franz Baader , Diego Calvanese, Deborah L. McGuinness , Daniele Nardi , and Peter F. Patel-Schneider, editors. The description logic handbook: theory, implementation, and applications . Cambridge University Press, New York, NY, USA, 2003 .

2. Jung-Hwa Chae and Nematollaah Shiri . Formalization of rbac policy with object class hierarchy . In Ed Dawson and Duncan S. Wong, editors, ISPEC , volume 4464 of Lecture Notes in Computer Science, pages 162 { 176 . Springer, 2007 .

3. OASIS eXtensible Access Control Markup Language (XACML) TC . http://www.oasis-open.org/committees/tc home. php? wg abbrev=xacml.

4. David F. Ferraiolo , Ravi S. Sandhu, Serban I. Gavrila , D. Richard Kuhn, and Ramaswamy Chandramouli . Proposed NIST standard for role-based access control . Information and System Security , 4 ( 3 ): 224 { 274 , 2001 .

5. T. Finin , A. Joshi , L. Kagal , J. Niu , R. Sandhu , W. Winsborough , and B. Thuraisingham . Rowlbac: representing role based access control in owl . In SACMAT '08: Proceedings of the 13th ACM symposium on Access control models and technologies , pages 73 { 82 , New York, NY, USA, 2008 . ACM.

6. Fausto Giunchiglia , Maurizio Marchese, and Ilya Zaihrayeu . Encoding classi cations into lightweight ontologies . In ESWC , pages 80 { 94 , 2006 .

7. Fausto Giunchiglia and Ilya Zaihrayeu . Lightweight ontologies . In Encyclopedia of Database Systems . Springer, 2008 .

8. Fausto Giunchiglia , Rui Zhang, and Bruno Crispo . Relbac: Relation based access control . In SKG '08: Proceedings of the 2008 Fourth International Conference on Semantics, Knowledge and Grid , pages 3 { 11, Washington, DC, USA, 2008 . IEEE Computer Society.

9. Fausto Giunchiglia , Rui Zhang, and Bruno Crispo . Ontology driven community access control . In SPOT2009 - Trust and Privacy on the Social and Semantic Web , 2009 .

10. Vladimir Kolovski , James Hendler, and Bijan Parsia . Analyzing web access control policies . In WWW '07: Proceedings of the 16th international conference on World Wide Web , pages 677 { 686 , New York, NY, USA, 2007 . ACM.

11. Ninghui Li , Mahesh V. Tripunitara , and Ziad Bizri . On mutually exclusive roles and separation-of-duty . ACM Transactions on Information System Security , 10 ( 2 ): 5 , 2007 .

12. Ninghui Li and Qihua Wang . Beyond separation of duty: an algebra for specifying high-level security policies . In CCS '06: Proceedings of the 13th ACM conference on Computer and communications security , pages 356 { 369 , New York, NY, USA, 2006 . ACM.

13. C. Lutz and U. Sattler . The complexity of reasoning with boolean modal logics . In Frank Wolter, Heinrich Wansing, Maarten de Rijke, and Michael Zakharyaschev, editors, Advances in Modal Logics Volume 3 . CSLI Publications , Stanford, 2001 .

14. C. Lutz and D. Walther . Pdl with negation of atomic programs . Journal of Applied Non-Classical Logic , 15 ( 2 ): 189 { 214 , 2005 .

15. Ian Pratt-Hartmann. Complexity of the two-variable fragment with counting quanti ers . J. of Logic , Lang. and Inf., 14 ( 3 ): 369 { 395 , 2005 .

16. R. A. Schmidt and D. Tishkovsky . Using tableau to decide expressive description logics with role negation . In K. Aberer, K.-S. Choi, N. Fridman Noy , D. Allemang , K.-I. Lee , L. J. B. Nixon , J. Golbeck , P. Mika , D. Maynard , R. Mizoguchi , G. Schreiber, and P. Cudre-Mauroux, editors, The Semantic Web, 6th International Semantic Web Conference, 2nd Asian Semantic Web Conference , ISWC 2007 + ASWC 2007, Busan , Korea, November 11 { 15 , 2007 , volume 4825 of Lecture Notes in Computer Science, pages 438 { 451 . Springer, 2007 .

17. E. Sirin , B. Parsia , B. Cuenca Grau , A. Kalyanpur , and Y. Katz. Pellet : A practical owl-dl reasoner. Submitted for publication to Journal of Web Semantics ., 2003 .

18. Rui Zhang. RelBAC: Relation Based Access Control . PhD thesis , University of Trento, March 2009 .

19. Chen Zhao , NuerMaimaiti Heilili , Shengping Liu, and Zuoquan Lin . Representation and reasoning on rbac: A description logic approach . In Dang Van Hung and Martin Wirsing, editors, ICTAC , volume 3722 of Lecture Notes in Computer Science, pages 381 { 393 . Springer, 2005 .