dynamic delegation framework for role based access control in distributed data management systems

Distrib Parallel DatabasesDOI 10.1007/s10619-012-7120-4

Dynamic delegation framework for role based accesscontrol in distributed data management systems

Chun Ruan · Vijay Varadharajan

© Springer Science+Business Media New York 2013

Abstract This paper proposes a logic based framework that extends role based ac-cess control systems with dynamic delegation in a decentralised environment. It al-lows delegation of administrative privileges for both roles and access rights betweenroles. We have introduced the notion of trust in delegation and have shown how ex-tended logic programs can be used to express and reason about roles and their delega-tions with trust degrees, roles’ privileges and their propagations, delegation depth aswell as conflict resolution. Furthermore, our framework is able to enforce various roleconstraints such as separation of duties, role composition and cardinality constraints.The implementation of the framework is also discussed. The proposed framework isflexible and provides a sound basis for specifying and evaluating sophisticated rolebased access control policies in decentralised environments.

Keywords Role based access control · Privilege delegation · Logic programs

1 Introduction

A fundamental challenge in the development of large scale secure database systemsis the design of access control and privilege management model and architecture.The dynamic aspect of privileges coupled with the fine-grained nature of entities in-volved in large scale distributed database systems make this a significant problem,

Communicated by Elena Ferrari.

C. Ruan (�) · V. VaradharajanUniversity of Western Sydney, Penrith South DC, NSW 1797, Australiae-mail: [email protected]

V. VaradharajanMacquarie University, North Ryde, NSW 2109, Australiae-mail: [email protected]

mailto:[email protected]

mailto:[email protected]

Distrib Parallel Databases

especially in the context of pervasive mobile distributed applications. For instancewith the dramatic growth in mobile social networking increasingly more and moredata and applications are being accessed by mobile users. The owner of data andapplication provider may wish to restrict dynamically which other users are able toaccess the application and view the data. Applications can range from storing of pho-tos to more sensitive information such as storage of electronic patient records in acloud based healthcare system which would have dynamic security needs requiringdynamic delegation as well as context based role based access control. At a generallevel, there are two types of mappings, one from requesting entity to privileges andthe other from the privileges to accessed entity. Models such as Role-Based AccessControl (RBAC) [11] is well-known in terms of their ability to decouple these twomappings, by having a user to role mapping and role to objects mapping. The centralnotion of RBAC is that access rights or privileges are associated with roles and usersare assigned to appropriate roles. In distributed applications and services, we have ac-cess rights and roles are mapped to entities other than individuals. This partitioninginto two mappings enables the system to manage these two mappings somewhat in-dependently thereby helping to achieve more flexible and secure policy management.For instance, in a user based role system, if a specific user leaves the organizationand changes his/her position, only the mapping from users (subjects) to roles needto be revoked or changed (while the mapping between the role and the rights are nottouched). On the other hand, if the access rights of the roles change, only the mappingfrom roles to access rights need to be changed.

When it comes to management of policies, in general, there are two types of ap-proaches namely centralised and decentralised. Decentralised management in prin-ciple allows many administrators with different privileges and rights residing in dif-ferent locations in a distributed system. A main advantage of centralised paradigmis that it enables an organization to have central control over its resources. However,when the system is large, it is often difficult, and sometimes impossible, for a singlecentral unit to know every suitable role for a user, and every suitable access right fora role. Furthermore, large organizations may have over a thousand roles, and tens ofthousands of users. A case study carried out with Dresdner Bank, a major Europeanbank, resulted in an RBAC system that has around 40,000 users and 1300 roles [14].In a distributed federated application environment over the Internet, where the re-sources are owned (and administered) by different entities, it is infeasible to envisagea centralised approach to access control management. Although decentralised man-agement with different entities offers flexibility, it poses several security policy andarchitectural challenges

While RBAC is mainly used in a centralised management, we believe that it canbe extended to a distributed environment such as web service or Internet applicationsthrough proper delegation and trust management. That is, roles can be assigned tounknown entities based on the delegation and trust. For example, many newspaperssuch as Daily Telegraph provide free access to university students. In this case, uni-versities can be delegated the right to assign the role “student” with full trust. Thispaper is concerned with dynamic delegation based access rights management in a dis-tributed environment with multiple administrative entities. In this paper, we considerdynamic delegation of administrative privileges in the context of role based access


control system. In such a situation, a major security concern is whether the organi-zation can have some degree of control about who can access its resources; as afterseveral steps of delegations, a user who is not trusted may get control over the systemresources. Therefore how to use the delegation without compromising the security ofthe system is a big challenge. In this paper, we consider several ways for the dele-gators to control their delegations. Firstly, we allow a delegator to express their trustdegrees on the delegations. For example, in a university context, the Vice-Chancellor(VC) may delegate the capability of recruiting a role “Leading Security Researcher”(LSR) to the Research Director (RD) who may further delegate to his or her ResearchGroup Leader and an external member. The Research Director may associate differ-ent degrees of trust to these two delegations. This is especially the case when the roleis fuzzy, like the above “Leading Security Researcher”. Furthermore, an entity maybe assigned to a role by two other entities (assigners) with different trust degrees.Hence when it comes to deciding on a user’s assignment to a role, it is necessaryto consider the multiple paths involved and the trust degrees associated with thesepaths. A role assignment can be rejected if the trust degree associated with this fallsbelow a certain threshold. Our framework takes into account of such trust aspects inreasoning about access in decentralised systems.

Conflict resolution is another important aspect in the design of access control sys-tems. Conflicts may arise in a number of ways involving positive and negative autho-rizations as well as due to dynamic delegation of privileges between roles. Solvingconflicts in role based access control systems can be a complex issue that has notbeen well studied in the current research. A role may dynamically receive two con-flicting authorizations from two different roles which are able to grant privileges.E.g. an Enrolled Student when using a website associated with a course, may receiveconflicting authorizations from a Website Administrator and the Course Coordinator.Alternatively, a user may receive two conflicting authorizations from the two rolesin which he/she is a member. For example, Alice is an enrolled student and a tutor.Therefore she may receive two conflicting authorizations, with one allowing her toaccess the students’ work and the other not. Both levels of conflicts need to be prop-erly resolved. In our framework, delegators and grantors are allowed to express trustdegrees on their delegations and authorizations. Both the grantor’s priority and thetrust of the authorization will be taken into consideration in resolving conflicts. Itwill also allow us to express and enforce a range of other role requirements based onconstraints such as separation of duty, role exclusion and cardinality.

Our framework is based on extended logic programs (ELP) [3]. Logic based autho-rization models have been studied by many researchers for the purpose of formalizingauthorization specifications and evaluations. Logic based formalisms enable separa-tion of policies from implementation mechanisms, and have well-defined semantics.The extended logic programs (ELP), is based on nonmonotonic reasoning semantics,and has strong expressive power in the sense that it can deal directly with incompleteinformation in representation and reasoning. Since incomplete information is com-mon when it comes to access control policies, such policies are easier to specify inELPs. For example, if one wants to express that a user is denied to access a websiteif there is no knowledge that he/she is registered, the negation as failure (weak nega-tion) is often the most direct way to express this intention. We will extend ELP with


features needed for handling role based access control policies. This will enable us torepresent the delegation or granting relationship and the degree of the trust explicitlyin role based access models.

The main contribution of this paper is the design of a logic based framework thatsupports dynamic delegation for role based access control systems in a decentralisedenvironment. It has several novel features and allows for—delegation of both role ad-ministration and access right administration, trust degrees to be associated with roleand access right delegations, able to specify both positive and negative authorizationsto be granted to roles. This in turn enables to specify and reason about trust in dele-gated RBAC policies as well as resolve conflicts using trust in such policies. We havefurther used the answer set solver CLASP to evaluate the user and system rules, andimplemented a case study of the access control requirements for a health informationsystem.

The paper is organised as follows. Section 2 provides an overview of our formaldynamic delegation framework for role based access control systems. In Sect. 3, wedefine a role based authorization program (RBAP) to capture the delegations, trustdegrees, access right propagations along the hierarchies of roles and objects and con-flict resolution. A discussion of the features of RBAP and syntax are given in Sect. 3.Section 4 presents the formal semantics, and Sect. 5 presents how to use CLASP toevaluate RBAP. Section 6 discusses the implementation, and Sect. 7 compares ourframework with previous works and discusses the possible future work.

2 An overview of the formal framework

In this section, we present the basic ideas in the development of a formal dynamicdelegation framework for role based access control systems. In particular, we dis-cuss and analyse several design aspects such as role assignment and delegation cor-rectness, role constraints, authorization grant and delegation correctness, degrees oftrust, privilege propagation along role and object hierarchy, and conflict resolution.This section will form the foundation of our proposed framework.

2.1 Administrative privilege delegation correctness

In our formalization, administrative privilege delegation includes role administrativeprivilege delegation and access right administrative privilege delegation. We assumethat System Security Officer (SSO) in an organization is the first role that can dele-gate. Others have to be granted the privilege to delegate.

Definition 1 Delegation correctness: A role r can delegate other roles the privilegeto assign a role with depth d if and only if r is SSO or r has been delegated theprivilege to assign roles with delegation depth d + 1. A role r can delegate otherroles the privilege to grant an access right a over object o with depth d if and only ifr is SSO or r has been delegated the privilege to grant a over o with delegation depthd + 1.


The delegations are dynamic in our system in several ways. Firstly, the delegationscan be subjective to conditions. For example, we can say that a Head of School is del-egated the right to assign new staff if the student teacher ratio is greater than 50:1.Hence the delegation depends on the ratio which is changing dynamically. Second,the delegation paths are changing dynamically. Since a number of roles can be del-egated the right to further delegate, or assign a role or access rights, the delegationswill be dynamically generated. Furthermore, a delegation is allowed to be associatedwith a trust degree, which also affects the delegation’s evaluation. We will give moredetails about this later.

2.2 Role and access right assignment correctness

In this paper, we use users and entities interchangeably. The users can be individuals,agents or processes. For a particular role r , only the roles that have been granted therole administrative privilege on r can exercise r’s role assignment. We assume SSOcan assign any roles in the organization.

Definition 2 Role assignment correctness: A role r can assign users to a role r ′ ifand only if r is SSO or r has been granted the privilege to assign r ′.

In our formalization, the access right administrative privilege is in terms of a spe-cific access right on a specific object. Thus it is possible to say that a role can onlygrant read, but not write, on an object to others. For instance, a Head of School maybe able to grant “read” about the college’s budget file but not write. We also assumeSSO can grant any privileges on any object in the organization.

Definition 3 Access right assignment correctness: A role r can grant other roles anaccess right a of type + or − over object o if and only if r is SSO or r has beengranted the privilege to grant a over o.

2.3 Degrees of trust and effective trust

In the real world, trust is often not a yes/no binary decision. People often trust somepeople or something to a certain degree. This is also true when it comes to the roleor access right assignment or delegations. There is a need for people to express thedegree to which they believe that someone can perform some role/action, or someonecan grant some role/action. In our formalization, we allow a trust degree to be asso-ciated with each role/access right assignment, and each role/access right delegation.The trust degree may come from the delegator’s own knowledge about the delegatee,or from the information that the delegator obtains from reputable sources. There hasbeen a lot research about trust evaluations in the area of trust management systems,and we will not address the issue in detail in this paper.

Consider for example the following case: (i) A says B and C can say who canassign the role R with 0.9 and 0.8 trust degrees respectively, (ii) B and C say D canassign the role R with 0.7 and 0.6 trust degrees respectively, and (iii) D assigns Aliceto role R with 1. So, what should be the effective trust degree that the system adopts


about assigning Alice to the role R? A statement’s effective trust degree should con-sider all the trust degrees on a delegation path to it, and all the delegation paths to it. Inour framework, for any statement, if there exists only one path to it, then the productof all the trust degrees on the path is defined as its effective trust degree. If there existmultiple paths to it, then the greatest value of all the paths is defined as its effectivetrust degree. In the above example, there are two paths leading to Alice’s role assign-ment, A → B → D → Alice and A → C → D → Alice, with effective trust degrees0.9 ∗0.7 ∗1 and 0.8 ∗0.6 ∗1 respectively, so the effective trust degree for Alice’s roleassignment is 0.63. Effective trust degree can help to dynamically control the admin-istrative privilege delegation and role or access right assignment. For example, if theeffective trust degree falls below a certain threshold, then, the system can reject therole assignment or delegation. The trust degrees, the effective trust degrees, and thethreshold can be dynamically changed, and so are the delegations and role or accessright assignments. For example, a previously ineffective delegation may become ef-fective due to the increased effective trust degree caused by an additional delegationpath added to it. We believe that assigning and evaluating effective trust degrees is aneasy but effective approach for delegation control.

Example 1 Let us consider an example in the university context about teaching webservice. Suppose that the contents of a course website are open to all university stu-dents, and SSO has delegated the capability to assign students to the trusted uni-versities. SSO firstly delegates the Educational Department (EduD) to assign trusteduniversity (TUni) with full trust and delegation depth of 1, so that EduD can dele-gate once more. SSO then delegates the same right to any trusted university with atrust degree of 0.9 and delegation depth of 0 (meaning that they cannot further del-egate). A university becomes trusted university if it has existed for over 10 years.Now suppose EduD says UniOne is a trusted university with a trust degree of 0.9,and UniOne says Bob is a student with full trust. Then Bob will be able to access theresources on the teaching website if the role assignment threshold is set to 0.85. Nowif UniOne says UniTwo is a university with a trust degree of 0.9, and UniTwo saysTom is a student with full trust, then Tom will not be able to access the contents onthe website, as UniTwo is not a trusted university since its effective trust degree isonly 0.9 ∗ 0.9 = 0.81 which is less than the threshold of 0.85 (suppose UniTwo hasnot existed for over 10 years). The situation will be represented in RBAP program inthe next section.

2.4 Role constraints

Role constraints are supported in our framework. Firstly, strong exclusion is an im-portant one which is also called Static Separation of Duty. Two roles are strongly ex-clusive if no one person is ever allowed to perform both these roles. In other words,the two roles have no shared users. For example, full-time staff and part-time staffroles should be exclusive. We believe this exclusion requirement can be generalizedto any number of roles; in our current framework, we consider up to 4 roles exclusion,which is adequate for most common systems.


Role cardinality requirement is about the number of members in a role. To makethis more general, we will allow the expression of a minimum number and a maxi-mum number for a role at a given time. For instance, the promotion committee con-sists of at least 5, and at most 7 members. The exact role number requirement is thenexpressed by making minimum number equal to the maximum number.

Role composition requirement is about a role’s relationship with another role. Forexample, a university promotion committee should include two staff members. Wewill also generalize this constraint to express that one role should contain at least n

and at most m members from another role.In the real world, it is often required that to be able to perform role 1, one needs to

be in role 2. For example, many universities require that Unit coordinators to be fulltime academic staff. Role dependency requirement is thus introduced in our frame-work to represent this situation.

2.5 Conflict resolution

Two types of conflicts can arise in a role based access control system. A role mayreceive conflicting authorizations from multiple administrators, or an user may re-ceive conflicting authorizations due to being a member of two different roles. Forexample, a staff member is allowed to borrow books from a library, but an “overduestaff” member who has overdue books is not allowed to borrow books. If a person be-longs to both of the roles, then he/she will receive two conflicting authorizations. Forboth types of conflicts, we will use the effective trust degree to resolve the conflicts.This means that the authorization with higher effective trust degree will override.For example, by giving a higher trust degree to the negative authorization granted to“overdue staff” than that of the positive authorization granted to staff, an “overduestaff” cannot borrow books. This method would also allow the administrative privi-lege delegator to control their delegations flexibly. For instance, by giving a delegateea less than one trust degree, a delegator can keep a higher priority than the delegateein their ‘can grant’ delegations. Therefore, when the delegator gives an authoriza-tion a full trust degree, this authorization will not be overridden by the delegatee’sauthorizations. This method will help to enforce the high level policies despite thedelegations.

Example 2 Consider again the example about university teaching web service. Sup-pose the SSO delegates the capability to grant access right on the teaching coursewebsite (CWeb) to each Course Coordinator (CC) with a trust degree of 0.9 and adelegation depth of 1. However, SSO has made a strong university wide policy thatanyone who enrolled in the course can access the website’s teaching materials, and allschool staff can also access the website’s teaching materials. This is done by grantingthe access to enrolled students (Enro) and school staff with a full trust degree of 1.SSO has also made a weak policy that external students can access the course web-site’s teaching materials, and this is done by granting the access to students with a lowtrust degree of 0.6. Suppose SSO says Head of School (HOS) can assign the coursecoordinators with a trust degree of 1 and a delegation depth of 1. HOS says Helen isa course coordinator if no information shows she is on leave. If Helen wants to deny


the external students to access her teaching materials, she can grant them a negativeauthorization with a full trust degree. In this case her grant’s effective trust is 0.9 ∗ 1,which is greater than SSO’s 0.6, and therefore her grant will override. However, ifHelen wants to deny the school staff to access in the same way, she will not be suc-cessful as her grant’s effective trust degree of 0.9 (the maximum she can get) is lessthan the SSO’s 1. This time SSO’s grant will win. The situation will be representedin RBAP program in the next section.

When the two conflicting authorizations have the same effective trust, the conflictsare said to be unresolved in our framework. Although we can use the simple negative-take-precedence to solve them, we prefer to leave it to the access control mechanismsto resolve the situation.

We would like to point out that most current conflict resolution policies can beeasily achieved in our framework. For example, by always giving a negative autho-rization a higher trust than positive one or vice versa, we can achieve negative-take-precedence or positive-take-precedence policies. By giving more specific authoriza-tions a higher trust degree than general ones, we can achieve the more specific-take-precedence policy. Similarly, by always giving the strong authorizations a higher trustdegree than the weak ones, we can achieve the strong and weak policies. By givinga trust degree of less than one to administrative privilege delegations, and giving atrust degree of one to authorizations, we can achieve the predecessor-take-precedencepolicy. This shows that our conflict resolution policy is very flexible which can meetdifferent applications’ needs.

2.6 Authorization and delegation propagations

Rule based formalism allows implicit roles and their access rights to be derived fromexplicit role/access right assignments, and hence this can greatly reduce the size ofexplicit assignment set. For example, the role Head of School will inherit role staffand therefore has all the access rights granted to staff. If a role is allowed to accessstudent profile then the role should be able to access the profile’s components such asthe personal information and study record. In our framework, we support the implicitrole/access right assignment by supporting inheritance. We consider the authorizationpropagations along hierarchies of roles and objects represented by the correspondingpartial orders.

For the same reason, we also support the administrative privileges inheritancealong role and object hierarchies. For example, if the role staff is allowed to assignrole student or grant access right on student profile, then the role Head of Schoolshould also be able to do so.

2.7 RBAP

Role based authorization program (RBAP) is an extended logic program which con-tains system built-in predicates and user defined predicates. Users can use RBAP toexpress complex security policies based on delegation and trust. Any RBAP consistsof domain specific rules and domain independent rules. Domain specific rules are de-fined by users to express the desired application related security policies, using user


defined predicates as well as built-in predicates. Domain independent rules are de-fined to capture the features stated above such as role and access right administrativeprivilege delegation correctness, role and access right assignment correctness, roleconstraints and delegations, role and access right propagations along the hierarchiesof roles and objects, and conflict resolution. We will develop the domain independentrules in the next section. The domain independent rules are the same for all appli-cations. These general rules are combined with the domain-specific rules defined byusers to derive the authorizations holding in the system. We will adopt well known an-swer set semantics for RBAP because it is more suitable for our purpose of handlingauthorization conflicts since it provides a more flexible way to deal with incompleteand contradictory information.

3 Role based authorization programs

Role based authorization program (RBAP) is an extended logic program. Any RBAPis consisted of domain specific rules and general rules. The former is defined by usersto express the desired application related security policies, while the latter is definedin this section to capture the general features stated in the last section.

3.1 Syntax of RBAP

Role based authorization program (RBAP) is a multi-sorted first order language, withseven disjoint sorts R, U , O, A, T , W , and N for role, user, object, access right, au-thorization type, weight and depth respectively. Variables are denoted by strings start-ing with lower case letters, and constants by strings starting with upper case letters.In addition, two partial orders <R , <O are defined on sorts R and O representing therole and object hierarchies respectively. There are two authorization types denotedby −, +, where − means negative, + means positive. A negative authorization spec-ifies that the access must be forbidden, while a positive authorization specifies thatthe access must be granted. W is a set of real number in (0,1], and N is a set ofnon-negative integers. In general, we prohibit function symbols in our language forthe sake of simplicity, but allow some simple built-in arithmetic functions to be used.A rule r is of the form:

b0 ← b1, . . . , bk,not bk+1, . . . ,not bm,m ≥ 0

where b0, b1, . . . , bm are literals, and not is the negation as failure symbol. A RoleBased Authorization Program, RBAP, consists of a finite set of rules.

In the following, we will normally use the following vocabulary:

1. Sort role: role variables r, r ′, r1, r2, . . . .2. Sort users: with user variables g,u,u′, u1, u2, . . . .3. Sort object: with object variables o, o′, o1, o2, o3, . . . .4. Sort access right: access right variables a, a′, a1, a2, . . . .5. Sort authorization type: with authorization type variables t, t ′, t1, t2, . . . .6. Sort weight: with variables w,w′,w1,w2, . . . .7. Sort non-negative integer: with variables m,n,d, d ′, d1, d2, . . . .


8. Predicate Symbol set P

The predicate set P in RBAP consists of a set of ordinary predicates defined by users,and a set of system built-in predicate designed for user to express role assignment,role/user to privilege grant, role/access right administrative privilege delegation, androle constraints.

In our formalization, administrative privilege delegation includes role adminis-trative privilege delegation and access right administrative privilege delegation. Weassume that System Security Officer (SSO) in an organization is the first role that candelegate. Others have to be granted the privilege to delegate. For role assignment del-egation, a special predicate (g, r,w,d)canAssign(r ′, r ′′) is defined, where (g, r,w,d)

is called the grantor of the delegation. Intuitively, it means that a user g in role r saysthat the role r ′ can not only assign users to role r ′′, but also further delegate this ad-ministrative privilege on r ′′ for the maximum delegation depth d , and g’s trust degreeon this delegation to r ′ is w. If the depth is 0, r ′ cannot further delegate. A depth of 1would mean that r ′ can further delegate to some role with maximum depth of 0 andetc. Similarly, for privilege grant delegation, we have (g, r,w,d)canGrant(r ′, o, a),which means that a user g in role r says that role r ′ can not only grant access righta on o, but also further delegate this administrative privilege to the maximum depthof d . And g’s trust degree on this delegation to r ′ is w.

In terms of role assignment, a special predicate of the form (g, r,w)assign(r ′, u)

is defined. Intuitively, it means that a grantor g in a role r assigns user u to role r ′.g’s trust degree on this role assignment is w. The users can be individuals, agentsor processes. Similarly, we define a predicate grant (g, r,w)grant(r, o, t, a) for au-thorization. It means that g in role r says that role r can/cannot (depending on thetype t) do access a on object o, and the grant weight is w. A role r can assign usersto a role r ′ if and only if r is SSO or r has been granted the privilege to assign r ′(using canAssign). A role r can grant other roles an access right a of type + or −over object o if and only if r is SSO or r has been granted the privilege to grant a

over o (using canGrant).For the role delegation, predicate deleRole(u,u′,R) means user u delegates its

role R to user u′ while deleAll(u,u′) means user u delegates its every role to user u′.The delegatee can perform the delegated role due to the delegation.

For the exclusion of roles, we define a predicate exclusive(r1, r2) to represent tworoles exclusion.

Predicate roleNum(r, n,m) is defined for the role cardinality constraint. It meansthat a role r should have at least n and at most m members. If there is no restrictionon the minimum or maximum number, n or m is set as 0. Exact number of membersis represented by setting m==n.

For the role composition constraint, we define the predicate roleComp(r, r ′, n,m).It means that role r should contain at least n and at most m members from anotherrole r ′.

In the real world, it is often required that to be able to perform role 1, one needs tobe in role 2. For example, many universities require that Unit coordinators to be fulltime academic staff. Role dependency requirement is thus introduced in our frame-work to represent this situation. For the role dependency constraint, we define thepredicate depend(r, r ′) which means that role r depends on role r ′.


Example 3 We can now use RBAP program to represent Example 1.

(a1). (Alice,SSO,1,1)canAssign(TUni,Stu) ←(a2). (Alice,SSO,1,1)canAssign(EduD,TUni) ←(a3). (Alice,SSO,0.9,0)canAssign(TUni,TUni) ←(a4). (Alice,SSO,1)assign(TUni, x) ← year(x,10), (u, r, t)assign(Uni, x)

(a5). (Mary,EduD,0.9)assign(TUni,UniOne) ←(a6). (Evan,UniOne,1)assign(Stu,Bob) ←(a7). (Evan,UniOne,0.9)assign(TUni,UniTwo) ←(a8). (Rose,UniTwo,0.9)assign(Stu,Tom) ←The meanings of these rules are as follows. (a1) Alice as SSO says, with trust degree 1and delegation depth 1, that TUni can assign Stu. (a2) Alice as SSO says, with trustdegree 1 and delegation depth 1, that EduD can assign TUni. (a3) Alice as SSO says,with trust degree 0.9 and delegation depth 0, that TUni can assign TUni. (a4) Alice asSSO says, with trust degree 1, that if x is assigned to a Uni and existed for 10 years,then it is assigned to a TUni. (a5) Mary in role EduD assigns UniOne to TUni withtrust degree 0.9. (a6) Evan in role UniOne assigns Bob to Stu with trust degree 1.(a7) Evan in role UniOne assigns UniTwo to TUni with trust degree 0.9. (a8) Rosein role UniTwo assigns Tom to Stu with trust degree 0.9.

Example 4 The following RBAP program represents Example 2.

(b1). (Alice,SSO,0.9,1)canGrant(CC,CWeb,R) ←(b2). (Alice,SSO,1)grant(Enro,CWeb,+,R) ←(b3). (Alice,SSO,1)grant(Staff ,CWeb,+,R) ←(b4). (Alice,SSO,0.6)grant(Stu,CWeb,+,R) ←(b5). (Alice,SSO,1,1)canAssign(HOS,CC) ←(b6). (Alice,SSO,1)assign(Jim,HOS) ←(b7). (Jim,HOS,1)assign(Helen,CC) ← not onleave(Helen)

(b8). (Helen,CC,1)grant(Staff ,CWeb,−,R) ←(b9). (Helen,CC,1)grant(Stu,CWeb,−,R) ←The meanings of these rules are as follows. (b1) Alice as SSO says, with trust de-gree 0.9 and delegation depth 1, that CC can grant CWeb. (b2) Alice as SSO says,with trust degree 1, that Enro can read CWeb. (b3) Alice as SSO says, with trustdegree 1, that Staff can read CWeb. (b4) Alice as SSO says, with trust degree 0.6,that Stu can read CWeb. (b5) Alice as SSO says, with trust degree 1 and delegationdepth 1, that HOS can grant CC. (b6) Alice in role SSO assigns Jim to HOS withtrust degree 1. (b7) Jim in role HOS assigns Helen to CC with trust degree 1 if noinformation indicates that Helen is on leave. (b8) Helen as CC says, with trust de-gree 1, that Staff cannot read CWeb. (b9) Helen as CC says, with trust degree 1, thatStu cannot read CWeb.

3.2 Domain-independent rules

In this section, we define a set of domain-independent rules to formally achieve theconcepts defined in the last section on role and access right administrative privilege


delegation, role constraints, delegation correctness, role and privilege propagations,and conflict resolution.

Rules r1–r11 are about role delegation and assignment management.

Rules for role assignment delegation correctness The next two rules are about del-egation of role assignment. The first rule means that any delegation from SSO willbe accepted, represented by predicate canAssign1. The second rule means that if arole has been delegated to assign roles for the maximum delegation depth d ′, then therole’s further delegation with depth less than d ′ is accepted.

(r1). (g,SSO,w,d)canAssign1(r, r ′) ← (g,SSO,w,d)canAssign(r, r ′)(r2). (g, r1,w,d)canAssign1(r, r2) ← (g, r1,w,d)canAssign(r, r2),

(g′, r3,w1, d′)canAssign1(r1, r2), role(r1, g), d ′ > d

Rules for role assignment correctness The following two rules mean any role as-signment from the System Security Officer or a grantor holding the right to assign arole is accepted represented by assign1.

(r3). (g,SSO,w)assign1(r ′, u) ← (g,SSO,w)assign(r ′, u), role(SSO, g)

(r4). (g, r,w)assign1(r1, u) ← (g, r,w)assign(r1, u),(g′, r2,w1, d)canAssign1(r, r1), role(r, g)

Rules for calculating the role’s assigner’s trust degree A role assigner’s trust degreeis the product of all the trust weights along the path from the root(SSO) to it. If thereare multiple paths to it, then the greatest number will be chosen as its trust degree.The following rules are used to achieve this. The first rule assigns SSO the maximumtrust degree of 1. The second calculates the candidate trust based on a delegation’sweight and the delegator’s trust degree. The third and fourth rule check that, for anycandidate trust degree x of an assigner g on a role r (represented by trusts(g, r, x)), ifthere is any other that is greater than it (represented by existHigherTrusts(g, r, x)). Ifthere is no higher one, then the current one is the assigner’s trust degree (representedby trust(g, r, x)).

(r5). trust(SSO, r,1) ←(r6). trusts(r1, r2,w

′ ∗ w) ← (g, r,w,d)canAssign1(r1, r2), trust(r, r2,w′)

(r7). existHigherTrusts(r, r ′,w) ← trusts(r, r ′,w), trusts(r, r ′,w′),w′ > w

(r8). trust(r, r ′,w) ← trusts(r, r ′,w), not existHigherTrusts(r, r ′,w)

Rules for role assignment acceptance The following rule means that a role assign-ment from an assigner is accepted if the production of its trust degree and the assign-ment weight is greater than W , where W is a constant in (0,1] used to express thetrust degree accepted by the organization.

(r9). role(r, u) ← (g, r ′,w)assign1(r, u), trust(r ′, r,w′),w′ ∗ w ≥ W

Rules for role delegation The next two rules are about role delegation. The first rulemeans that a user u delegates its role r to another user u′. If u is a member of r , thenu′ will be added to the role. The second rule means that u delegates all of its rolesto u′.


(r10). role(r, u′) ← deleRole(u,u′, r), role(r, u)

(r11). role(r, u′) ← deleAll(u,u′), role(r, u)

Rules s1–s8 are about enforcing role constraints.

Rules for enforcing the constraint about separation of duty The next rule is aboutstatic separation of duty. It means that r1 and r2 are required to be exclusive, andthereby a user cannot be assigned to both of them.

(s1). ← exclusive(r1, r2), role(r1, u), role(r2, u)

Rules for enforcing the constraint about role dependency requirement Role r1 issaid to be dependent on r2 if r1 needs to be a subset of r2. The following rule enforcesthis requirement.

(s2). ← depend(r1, r2), role(r1, u),not role(r2, u)

Rules for enforcing the constraint about the cardinality constraint The followingrules are used to enforce the role cardinality constraints. The first rule means that it isnot acceptable if there are more than m different members in r . The second and thirdrules mean that it is not acceptable if there are not n different members in r .

(s3). ← roleNum(r, n,m), role(r, u1), . . . , role(r, um+1),m > 0, ui �= uj

(i �= j, i, j = 1, . . . ,m + 1)

(s4). existRoleNum(r, n) ← role(r, u1), . . . , role(r, un), n > 0, ui �= uj

(i �= j, i, j = 1, . . . , n)

(s5). ← roleNum(r, n,m),not existRoleNum(r, n)

Rules for enforcing the constraint about role composition requirement The follow-ing rules are used to enforce the role composition requirement. The first rule saysthat, if a role r should have at most m members from r ′, but in fact there are m + 1users who belong to both roles, then the system will fail. The second and the thirdrules mean that if a role r should have at least n members from r ′, but the systemcannot find n members from r ′ belonging to r , then it will fail.

(s6). ← roleComp(r, r ′, n,m), role(r, u1), . . . , role(r, um+1), role(r ′, u1), . . . ,

role(r ′, um+1), ui �= uj , (i �= j, i, j = 1, . . . ,m + 1)

(s7). existRoleComp(r, r ′, n) ← role(r, u1), . . . , role(r, un), role(r ′, u1), . . . ,

role(r ′, un), ui �= uj , (i �= j, i, j = 1, . . . , n)

(s8). ← roleComp(r, r ′, n,m), not existRoleComp(r, r ′, n)

Rules o1–o8 are about access right delegation and grant management.

Rules for administrative privilege delegation correctness The following rules areused to guarantee that the administrative privileges are properly delegated in termsof the eligible delegators and the valid delegation depths. The first rule means theSystem Security Officer (SSO)’s any administrative privilege delegation is accepted(represented by predicate canGrant1). The second rule means if a subject has beendelegated the right to grant for the maximum delegation depth d ′, then the subject’sfurther administrative delegation with depth less than d ′ is accepted.


(o1). (g,SSO,w,d)canGrant1(r, o, a) ← (g,SSO,w,d)canGrant(r, o, a),role(SSO, g)

(o2). (g, r2,w,d)canGrant1(r1, o, a) ← (g, r2,w,d)canGrant(r1, o, a),(g′, r3,w

′, d ′)canGrant1(r2, o, a), role(r2, g), d ′ > d

Rules for administrative privilege propagation along the role hierarchy The nextrule is about administrative privilege propagations along the role hierarchy. It meansthat a subject’s administrative privilege on some object and access right would prop-agate automatically to its next higher level roles represented by <R relation.

(o3). (g, r ′′,w,d)canGrant1(r, o, a) ← (g, r ′′,w,d)canGrant1(r ′, o, a), r <R r ′

Rules for administrative privilege propagation along the object hierarchy The nexttwo rules are about administrative privilege propagations along the object hierarchy.It means that a subject’s administrative privilege on some object and access rightwould propagate automatically to its next lower level objects represented by <O .

(o4). (g, r ′,w,d)canGrant1(r, o, a) ← (g, r ′,w,d)canGrant1(r, o′, a), o′ <O o

Rules for authorization correctness The following two rules mean any grant fromthe System Security Officer or a grantor holding the right to grant is accepted (repre-sented by predicate grant1).

(o5). (g,SSO,w)grant1(r, o, t, a) ← (g,SSO,w)grant(r, o, t, a), role(SSO, g)

(o6). (g, r1,w)grant1(r, o, t, a) ← (g, r1,w)grant(r, o, t, a),(g′, r2,w

′, d)canGrant1(r1, o, a), role(r1, g)

Rules for authorization propagation The following rules are used to achieve au-thorization propagation along role and objects inheritance hierarchies. The first rulemeans any authorization given to a role would propagate to its superior roles rep-resented by the <R relation. The second rule means any authorization on an objectwould propagate to its sub-objects represented by the <O relation.

(o7). (g, r,w)grant1(r2, o, t, a) ← (g, r,w)grant1(r1, o, t, a), r1 <R r2, t = −(o8). (g, r,w)grant1(r2, o, t, a) ← (g, r,w)grant1(r1, o, t, a), r2 <R r1, t = +(o9). (g, r,w)grant1(r1, o

′, t, a) ← (g, r,w)grant1(r1, o, t, a), o <O o′

Rules c1–c9 are about conflict resolution for roles and users.

Rules for conflict resolution An authorization grantor’s trust degree or priority is theproduct of all the trust weights along the path from the root(SSO) to it. If there aremultiple paths to it, then the greatest number will be chosen as its trust degree. Thefirst rule assigns SSO the maximum trust degree of 1. The second calculates the can-didate trust based on a delegation’s weight and the delegator’s trust degree. The thirdand fourth rule check that, for any candidate trust degree w of a grantor g on manag-ing an access right a over object o (represented by priorities(r, o, a,w)), if there isany other that is greater than it (represented by existHigherPriorities(r, o, a,w)). Ifthere is no higher one, then the current one is the grantor’s trust degree (representedby priority(r, o, a,w)). Predicate existHigherPriorities means that the corresponding


priorities is not the highest one. It is introduced to avoid the existential quantifier tobe used in (c4), as in an extended logic program all the variables in clauses are con-sidered to be universally quantified. For the two conflicting authorizations, we willcompare the sum of the grantor’s priority and weight of the authorization, and theone with smaller value will win. Predicate overridden is introduced to indicate thatthe corresponding authorization is overridden by some other authorizations. Predi-cate hold means the corresponding authorization holds as it is not overridden by anyother authorizations, and its effective weight is greater than W which is a constantdenoting the trust degree accepted by the organization.

(c1). priority(SSO, o, a,1) ←(c2). priorities(r, o, a,w′ ∗w) ← (g, r ′,w,d)canGrant1(r, o, a), priority(r ′, o, a,w′)(c3). existHigherPriorities(r, o, a,w) ← priorities(r, o, a,w), priorities(r, o, a,w′),

w′ > w

(c4). priority(r, o, a,w) ← priorities(r, o, a,w),not existHigherPriorities(r, o, a,w)

(c5). (g, r1,w)overridden(r, o, t, a) ← (g, r1,w)grant1(r, o, t, a),(g′, r2,w1)grant1(r, o, t ′, a), priority(r1, o, a,w2), priority(r2, o, a,w3),

w1 ∗ w3 > w2 ∗ w

(c6). (g, r ′,w ∗ w′)grant2(r, o, t, a) ← (g, r ′,w)grant1(r, o, t, a),not (g, r ′,w)overridden(r, o, t, a),priority(r ′, o, a,w′),w′ ∗ w > W

(c7). (g, r ′,w)grant3(u, o, t, a) ← (g, r ′,w)grant2(r, o, t, a), role(r, u)

(c8). (g1, r1,w)overridden(u, o, t, a) ← (g1, r1,w1)grant3(u, o, t, a),(g2, r2,w2)grant3(u, o, t ′, a),w1 < w2

(c9). (g, r,w)hold(u, o, t, a) ← (g, r,w)grant3(u, o, t, a),not (g, r,w)overridden(u, o, t, a)

Let R denote all the general rules, i.e. R = {r1, . . . , r11, s1, . . . , s8, o1, . . . o9, c1, . . . ,

c9}. R will be combined with application dependent rules to evaluate the authoriza-tions holding at any time (represented by predicate hold). Any access request willthen be checked against it. For example, Examples 3 and 4 will be combined with R

to evaluate the authorizations holding in this application.

4 Formal semantics of RBAP

We will adopt well known answer set semantics for RBAP because it is more suitablefor our purpose of handling authorization conflicts since it provides a more flexibleway to deal with incomplete and contradictory information. Let Π be a RBAP, theBase BΠ of Π is the set of all possible ground literals constructed from the sys-tem reserved predicates and predicates appearing in the rules of Π , the constantsoccurring in R, U , O, A, T , W , N . A ground instance of r is a rule obtained fromr by replacing every variable W in r by δ(x), where δ(x) is a mapping from thevariables to the constants in the same sorts. Let G(Π) denote all ground instancesof the rules occurring in Π . Two ground literals are conflicting on subject U , ob-ject O and access right A if they are of the form (G,R,W)hold(U,O,+,A) and(G′,R′,W ′)hold(U,O,−,A). A subset of the Base of BΠ is consistent if no pair


of complementary or conflicting literals is in it. An interpretation I is any consistentsubset of the Base of BΠ .

Definition 4 Given a RBAP Π , an interpretation for Π is any interpretation ofΠ ∪ R. Let I be an interpretation for a RBAP G(Π), the reduction of Π w.r.t. I ,denoted by ΠI , is defined as the set of rules obtained from G(Π ∪ R) by deleting(1) each rule that has a formula not L in its body with L ∈ I , and (2) all formulas ofthe form not L in the bodies of the remaining rules.

Given a set R of ground rules, we denote by pos(R) the positive version of R, ob-tained from R by considering each negative literal ¬p(t1, . . . , tn) as a positive onewith predicate symbol ¬p.

Definition 5 Let M be an interpretation for Π . We say that M is an answer set forΠ if M is a minimal model of the positive version pos(ΠM).

Example 5 Let us consider the RBAP given in Examples 3 and 4. To evaluate the au-thorizations holding, it should be combined with the general rules in R. In the processof answer set generation, the role and access right assignment and delegation correct-ness are enforced, the role constraints are checked, the authorization and delegationpropagations are carried out along the given role and object inheritance hierarchies inthe domain, and the conflicts are resolved based on our trust based resolution policy.For instance, UniTwo will not be assigned to role TUni because its effective trustdegree is less than the threshold of 0.85. As a result, Tom will not be assigned to therole Stu, and therefore will not be able to access the course website due to Helen’snegative authorizations to Stu which overrides the SSO’s weak positive authorizationto Stu. On the other hand, a staff will be able to access the website despite Helen’snegative authorization since it is overridden by SSO’s strong positive authorization.

4.1 Access control policy

We can now define our access control policies. A query is a four-ary tuple (u, r, o, a)

in U × R × O × A, which denotes that a user u as an active member of role r requestsaccess a over object o. The access control policy is a function f from U × R × O × Ato {true, false,undecided}. Given a request (u, r, o, a), if f (u, r, o, a) = true thenit is granted. If f (u, r, o, a) = false then it is denied. Otherwise, f (u, r, o, a) =undecided, and it is left to be decided by the implemented access control system.Although most access control mechanisms may treat undecided as denial, the dis-tinction between false and undecided is important. false means denial in the strongersense in that its negation exists, while undecided means denial in the weaker sense inthat it does not succeed.

According to answer set semantics, there may exist several authorization answersets for a given RBAP, and they may not consistent with each other in the sense thatthey may contain conflicting literals. We will adopt optimistic approach to deal withthis problem. Let Π be a RBAP, A1, . . . ,Am be its authorization answer sets. Forany query (u, r, o, a), f (u, r, o, a) = true if r is SSO and u is a member of SSO


(role(u,SSO) appears in all Ai,1 ≤ i ≤ m); or the role r is granted access right a ono in some answer set, and u is a member of r . More formally, this means that thereexists a (r ′, r,w)hold(u, o,+, a) for some r ′ and w, and a role(u, r) in some Ai ,1 ≤ i ≤ m. Otherwise, f (u, r, o, a) = false if there exists a (r ′, r,w)hold(u, o,−, a)

for some r ′ and w, and a role(u, r) in some Ai,1 ≤ i ≤ m. Otherwise f (u, r, o, a) =undecided. On the other hand, there may exist no authorization answer set for a givenRBAP Π . For example, there will be no answer set if the role constraints, such asseparation of duty, are not satisfied. In this case, we say Π is not well-defined.

5 Using CLASP to evaluate RBAP

5.1 CLASP

Like SMODELS, CLASP [2] implements the answer set semantics for extended logicprograms. It is an answer set program solver on SMODELS format, as output byGringo or Lparse. The language is domain-restricted but supports extensions includ-ing built-in functions as well as cardinality and weight constraints.

In CLASP, constants are either numbers or symbolic constants that starts with alower case letter. Variables start with a capital letter. A function is either a functionsymbol followed by a parenthesized argument list or a built-in arithmetical expres-sion. A range is the form of: start..end where start and end are constant valued arith-metic expressions. A range is a notational shortcut for defining numerical domains.

Rules are in the format of:

h :− l1, l2, . . . , ln

where the head is the part to the left of :−, and the body is right to :−. A programconsists of set of rules.

5.2 Domain-independent rules

In this section, we present the CLASP program for the domain-independent rules Rin RBAP. Most of the transformations are straightforward. The special predicates,which are more readable to users, need to be transformed into the normal predi-cates. For example, the predicate (g, r,w,d)canAssign(r ′, r ′′) will be transformedinto canAssign(G,R,R′,R′′,W,D). The weight’s range is changed to 0 to 10. Au-thorization types are represented by 0 and 1, meaning negative and positive respec-tively. We also add domain definitions based on the CLASP syntax requirements.

Rules for domains of roles, persons, objects, access methods, authorization types,trust weights and depths:

#domain person(P ;P 1;P 2), role(R;R1;R2;R3),depth(D;D1),file(F ;F1;F3),method(M;M2;M1),weight(W ;W1),authtype(T ;T 1).

weight(0..10).depth(0..10).authtype(0..1).#const wei = 8.


Rules for role assignment capability delegation correctness

(r1). canAssign1(P, sso,R,R1,W,D) :− canAssign(P, sso,R,R1,W,D),inRole(sso,P ).

(r2). canAssign1(P,R,R1,R2,W,D) :−canAssign(P,R,R1,R2,W,D), canAssign1(P 2,R3,R,R2,W1,D1),

inRole(R,P ),D1 > D.

Rules for role assignment correctness

(r3). assign1(P, sso,P 1,R,W) :− assign(P, sso,P 1,R,W), inRole(sso,P ),P != P 1.

(r4). assign1(P,R,P 1,R1,W) :− assign(P,R,P 1,R1,W),

canAssign1(P 2,R2,R,R1,W1,D), inRole(R,P ),P != P 1.

Rules for calculating the role’s assigner’s trust degree

(r5). trust(sso,R,10) :−(r6). trusts(R1,R2,W ∗ W1/10) :− canAssign1(P,R,R1,R2,W,D),

trust(R,R2,W1)

(r7). existHigherTrusts(R,R1,W) :− trusts(R,R1,W), trusts(R,R1,W1),

W1 > W

(r8). trust(R,R1,W) :− trusts(R,R1,W), not existHigherTrusts(R,R1,W)

Please note that when there are multiple trust degrees for an assigner, we choosethe biggest one.

Rules for role assignment acceptance

(r9). inRole(R1,P 1) :− assign1(P,R,P 1,R1,W), trust(R,R1,W1),

W1 ∗ W/10 > wei.

Assigner’s trust degree has to be greater than the predefined threshold.Rules for role delegation

(r10). inRole(R,P 1) :− deleRole(P,P 1,R), inRole(R,P ),P != P 1.(r11). inRole(R,P 1) :− deleAll(P,P 1), inRole(R,P ),P != P 1.

A person can delegate all of his/her roles or a specific role to another person.Rules for constraints about role dependency, role exclusion, role cardinality, and

role composition

(s1). :− dep(R,R1), inRole(R,P ),not inRole(R1,P ).(s2). :− ex(R,R1), inRole(R,P ), inRole(R1,P ).

Rules for constraints about role cardinality

(s3). :− roleNum(R,N,M),M + 1 {inRole(R,P )}.(s4). :− roleNum(R,N,M), {inRole(R,P )}N − 1.

Rules for constraints about role composition

(s5). :− roleComp(R,R1,N,M), inRole(R,P ),M + 1 {inRole(R1,P )}.(s6). :− rikeComp(R,R1,N,M), inRole(R,P ), {inRole(R1,P )}N − 1.


Rules for authorization capability delegation correctness:

(o1). canGrant1(P, sso,R1,F,M,W,D) :− canGrant(P, sso,R1,F,M,W,D),

inRole(sso,P ).(o2). canGrant1(P,R,R1,F,M,W,D) :− canGrant(P,R,R1,F,M,W,D),

canGrant1(P 1,R2,R,F,M,W1,D1), inRole(R,P ),D1 > D.

Rules for administrative privilege propagation:

(o3). canGrant1(P,R2,R,F,M,W,D) :− canGrant1(P 1,R2,R1,F,M,W,D),higherRole(R,R1)

(o4). canGrant1(P,R2,R,F,M,W,D) :− canGrant1(P 1,R2,R,F1,M,W,D),

inFolder(F1,F )

Rules for authorization correctness:

(o5). grant1(P, sso,R1, T ,F,M,W) :− grant(P, sso,R1, T ,F,M,W),

inRole(sso,P ).(o6). grant1(P,R,R1, T ,F,M,W) :− grant(P,R,R1, T ,F,M,W),

canGrant1(P 1,R2,R,F,M,W1,D1).

Rules for authorization propagation:

(o7). grant1(P,R,R1, T ,F,M,W) :− grant1(P,R,R2, T ,F,M,W),higherRole(R1,R2), T = 1

(o8). grant1(P,R,R1, T ,F,M,W) :− grant1(P,R,R2, T ,F,M,W),higherRole(R2,R1), T = 0

(o9). grant1(P,R1,R,T ,F,M,W) :− grant1(P,R1,R,T ,F1,M,W),inFolder(F1,F )

Rules for conflict resolution (for simplicity, here we omit the user level conflictresolution rules):

(c1). priority(SSO, o, a,10) :−(c2). priorities(R,F,M,W ∗ W1/10) :− canGrant1(P,R1,R,F,M,W,D),

priority(R1,F,M,W1).(c3). existHigherPriorities(R,F,M,W) :− priorities(R,F,M,W),

priorities(R,F,M,W1),W1 > W .(c4). priority(R,F,M,W) ← priorities(R,F,M,W),

not existHigherPriorities(R,F,M,W).(c5). overridden(P,R1,R,T ,F,M,W) :− grant1(P,R1,R,T ,F,M,W),

grant1(P 1,R2,R,T 1,F,M,W1),priority(R1,F,M,W2),priority(R2,F,M,W3),W1 ∗ W3 > W2 ∗ W

(c6). hold(P,R1,R,T ,F,M,W) :− grant1(P,R1,R,T ,F,M,W),not overridden(P,R1,R,T ,F,M,W), priority(R1,F,M,W1),W ∗ W1/10 > wei.

6 Implementation

We have implemented a case study of the access control requirements for HealthInformation System in a small aged care facility in rural New South Wales. The case


Fig. 1 RBAP framework

study is complex enough to demonstrate the richness of our framework. In this sectionwe only briefly describe some examples and not the whole case study due to spacerequirements. In terms of implementation, for this case study, we have developed aweb based application running on Windows Server 2008. We chose ASP.NET and MSSQL languages because they can be used to build a rapid prototype application. Atthe back-end of this application is our reasoning system using CLASP and CLINGO.CLASP is another answer set solver for extended logic programs. which has similarfunctions to SMODELS. We chose to use CLASP as we found that its performance issuperior to SMODELS for many examples that we experimented with.

We will now briefly describe the implementation and the associated interfaces.Basically, ASP.NET is used to write a user interface that accepts users inputs re-garding the delegatable role based access control policies, such as role delega-tion/assignments with weights and delegation depths, role constraints, access rightsand delegation/assignments with weights and depths. It interacts with the reasoningsystem (CLASP and Lparse) to generate the results and store them in the MS SQLdatabase. We divide the database into 2 parts, application rule database and systemrule database. System rule database contains the system rules and validated applica-tion oriented facts. It is then used to control the users privileges on the application;for instance, user login, assignment, delegation and granting of privileges. For exam-ple, only users in an authorised role can do the user-role or role-access right assign-ment/delegation. Role constraints are also enforced by the system rules. Applicationdatabase is used to store user’s input before reasoning. That is, when people enterdata on the interface, it is stored in the MS SQL database. When people save theirchanges, the system takes entire application database and pass it into the reasoningsystem. After the reasoning process completed, the results are returned and stored inthe system rule database. Again this database is used to manage the privileges of useron the website. The process is illustrated in Fig. 1.


As you can see from the diagram, the system rules are divided into two files. Thisis because we found that the reasoning system can’t handle a large data on WindowsOperating System.

This application has been developed on Visual Studio 2010. When running thesystem for the first time, the system will load the default setting in the initialSet-ting.txt file located in “lparse” folder. This is the default setting that helps to defineSSO in the system. When SSO has been verified, he/she can start to define the rulesand assign/delegate roles or grant/delegate access rights to users the system.

SSO modifies the settings in the system using system configuration functions.These include

– Add new access right.– Add new role.– Add new group.– Assign a role into a group.– Role hierarchy.– Assign a group into another group (Group Set).– Role dependence.– Role exclusive.– Access right inheritance.– Manual Config– Add new custom rules

We have conducted numerous validations on this application including the variousfeatures in the role hierarchy cycle. For example, A > B , B > C then the system willprevent the addition of C > A. Otherwise, the system will enter a recursive reasoningthat never completes.

The interface for system configuration is shown in Fig. 2.The user interface allows users to exercise their authorised rights to

– assign roles to users.– delegate roles to roles.– grant right to roles.– delegate rights to roles.– access files.

For example, in a ‘can assign’ function, users in certain authorised roles (this ischecked by the system) can say a role can assign another role with certain weightand depth. Furthermore, users are allowed to add some conditions directly to the as-signment, such as not onleave(x) to the assignment of x to a role of unit coordinator.To make the system more efficient, we do not run the reasoning on each assignmentadding action. The reasoning engine only starts when user clicks on Generate Button.It means user can add a number of assignments before they run the reasoning system.

The user interface is shown in Fig. 3 and the user interface for can assign is shownin Fig. 4.

With 12 different roles and 6 different groups and some 30 system rules, the an-swer set is found to be of the order of a few seconds, though it varies depending onthe depth of the role delegation and access right delegation etc. We have also ex-perimented with increasing the number of rules. We found that it is the number of


Fig. 2 System configuration

terms in the predicates which have more influence on the performance rather than thenumber of rules in many situations.

Currently we are in the process of migrating the whole system implementation toa Unix based system with a faster hardware configuration with a greater CPU speedand more memory. We have already transferred the rule evaluation part to a UnixSystem (CentOS) and the performance results are looking more promising.

However the focus in this paper has been on the specification, control and im-plementation of the delegation relationship for both roles and access rights. Oncepersons are delegated the right to assign the roles, they will be able to assign roles inparallel which of course will further increase the speed. The idea is to increase thepolicy expressive power using the reasoning engine at the back. In fact, as mentionedabove, once the answer set is generated, the results will be put in a database whichcontrols further input. We can do the reasoning off line.

7 Discussion and related work

In this section, we briefly compare our work with other relevant works in this area.ARBAC97 [12] is a model for decentralized administration of RBAC policies. In

a typical ARBAC policy, roles are classified as administrative roles and normal roles.Only administrative roles can assign users and privileges. There is a single top leveladministrator role, called the Senior Security Officer (SSO) and a number of JuniorSecurity Officers (JSO). The SSO partitions the organization’s policy into differentsecurity domains, each of which is administered by a different JSO. To decentralise


Fig. 3 User interface

Fig. 4 Can assign

the policy details without loosing central control over broad policy, each delegationto JSO is associated with some condition. The ARBAC policy specifies, for instance,to which normal roles and under what conditions can members of a JSO role as-sign users. Although the framework decentralizes the administration to some degree,the scalability is still limited. Use of additional relations to limit the delegation and


thereby enforcing central control is not flexible. Furthermore, negative authorizationsare not discussed in ARBAC. ARBAC99 [10] and [9] improve some shortcomings ofARBAC97. But, they do not change the fundamental approach of using administra-tive roles, additional relations, and role ranges based on hierarchies. Our frameworkdoes not distinguish user roles and administrative roles. Delegations are conditional,and the broad policy is achieved through trust management.

The work in [7] proposes to use security analysis techniques, which views anaccess-control system as a state transition system, to maintain desirable security prop-erties while delegating administrative privileges. [15] discusses how to assist a del-egator in choosing the delegatee using trust-based approach. In their approach, trustis a relationship between a truster and trustee with respect to a given task and de-pends on several factors such as properties, experience and recommendation. Thefactors are quantified and used for the delegator to choose the delegatee. A permis-sion based delegation model is presented in [17], which supports user-to-user, role-torole, and multi-depth delegations. However, how to resolve conflicts with respect toaccess rights in this context has not been well studied. [13] describes a way to detectconflicts, meaning the violation of specified constraints such as separation of dutyconstrains, caused by the role delegations. For conflict resolution, it is suggested in[13] to constrain the delegations, which in turn greatly reduces the flexibility of themodel.

Several schemes based on logic have been proposed with a view to formalizingauthorization specifications and evaluations. DKAL [4] is a declarative authorizationlanguage for distributed systems which is based on existential fixed-point logic. Itaims at expressive power to cater for complex policies by supporting the express fea-tures such as targeted communication, nested quotations and delegations etc. Jajodiaet al. proposed a logical language in [5] and illustrated how it can specify authoriza-tion, conflict resolution, access control and integrity constraint checking. In [6], N. Liand J.C. Mitchell present a language called RT C

1 which is based on constraint Dat-alog. The language allows first-order formulas in one or more constraint domains,which may define file hierarchies, time intervals, and so on, to be used in the body ofa rule, thus representing access permissions over structured resources in a declarativelanguage. In [8] N. Li et al. developed another logic based language, namely D1LP, torepresent policies, credentials, and requests in distributed authorization. Their workfocussed on how to express delegations based on an entity’s attributes in an opensystem. D1LP is extended to D2LP to support negation and non-monotonic reason-ing. It provides a predicate “overrides” which can only be used to specify priorityinformation between rules. Abadi et al. proposed a modal logic based approach foraccess control in distributed systems in [1]. Their work focussed on how to believethat a principal (subject) is making a request, either on his/her own or on someoneelse’s behalf. Woo and Lam proposed an expressive language to authorization in dis-tributed systems [16]. In their method, they consider structural properties inherent inauthorization and provide formal semantics evaluation which is based on an extendedlogic program. However, in general, the above logic models did not address the issueof delegations for role and access right administrative privileges in role based accesscontrol systems, and did not address the issue of how to resolve the possible autho-rization conflicts properly by allowing both positive and negative authorizations in


this context, which are in fact the main focus in this paper. The main contributionof this paper is the design of a logic based framework that supports dynamic delega-tions for role based access control systems in a complex environment. It has severalnovel features such as (1) allowing for delegations of both role administration andaccess right administration; (2) allowing for trust degrees to be associated with roleand access right delegations; (3) being able to specify both positive and negative au-thorizations to be granted to roles; (4) enabling to specify and reason about trust indelegated RBAC policies as well as resolve conflicts using trust in such policies.

For our future work, we intend to study the formal model for a temporal role basedaccess control system, where time period can be associated with roles and delega-tions, which will expire when the time period expires. We also intend to investigateprogram update including revocation of roles and access rights.

References

1. Abadi, M., Burrows, M., Lampson, B., Plotkin, G.: A calculus for access control in distributed sys-tems. ACM Trans. Program. Lang. Syst. 15(4), 706–734 (1993)

2. Gebser, M., Kaminski, R., Faufmann, B., Ostrowski, M., Schab, T., Thiele, S.: A User’s Guide togringo, clasp, clingo and iclingo. University of Potsdam (2008)

3. Gelfond, M., Lifschitz, V.: Classical negation in logic programs and disjunctive databases. New Gener.Comput. 9, 365–385 (1991)

4. Gurevich, Y., Neeman, I.: DKAL: distributed knowledge authorization language. In: Proceedings ofthe 21st IEEE Computer Security Foundations Symposium, pp. 149–162. IEEE Comput. Soc., LosAlamitos (2008)

5. Jajodia, S., Samarati, P., Subrahmanian, V.S.: A logical language for expressing authorizations. In:Proceedings of the 1997 IEEE Symposium on Security and Privacy, pp. 31–42. IEEE Comput. Soc.,Los Alamitos (1997)

6. Li, N., Mitchell, J.C.: Datalog with constraints: a foundation for trust management languages. In: Pro-ceedings of the 5th International Symposium on Practical Aspects of Declarative Languages, pp. 58–73. Springer, Berlin (2003)

7. Li, N., Tripunitara, M.V.: Security analysis in role-based access control. ACM Trans. Inf. Syst. Secur.9(4), 391–420 (2006)

8. Li, N., Grosof, B.N., Feigenbaum, J.: Delegation logic: a logic-based approach to distributed autho-rization. ACM Trans. Inf. Syst. Secur. 6(1), 128–171 (2003)

9. Oh, S., Sandhu, R.S.: A model for role administration using organization structure. In: Proc. of theSeventh SACMAT (2002)

10. Sandhu, R.S., Munawer, Q.: The ARBAC99 model for administration of roles. In: Proc. of the 18thAnnual Computer Security Applications Conference, pp. 229–238 (1999)

11. Sandhu, R.S., Coyne, E.J., Feinstein, H.L., Youman, C.E.: Role based access control models. Com-puter 29(2), 38–47 (1996)

12. Sandhu, R., Bhamidipati, V., Munawer, Q.: The ARBAC97 model for role-based administration ofroles. ACM Trans. Inf. Syst. Secur. 2(1), 105–135 (1999)

13. Schaad, A.: Conflict detection in a role-based delegation model. In: Proc. of Annual Computer Secu-rity Applications Conference (2001)

14. Schaad, A., Moffett, J., Jacob, J.: The role-based access control system of a European bank: a casestudy and discussion. In: Proc. of the Sixth SACMAT, pp. 3–9 (2001)

15. Toahchoodee, M., Xie, X., Ray, I.: Towards trustworthy delegation in role-based access control model.In: ISC 2009, pp. 379–394 (2009)

16. Woo, T., Lam, S.: Authorization in distributed systems: a formal approach. In: Proceedings of IEEEon Research in Security and Privacy, pp. 33–50 (1992)

17. Zhang, X., Oh, S., Sandhu, R.: PBDM: a flexible delegation model in RBAC. In: Proc. of the 8thACM Symposium on Access Control Models and Technologies (2003)

dynamic delegation framework for role based access control in distributed data management systems

Documents