JOURNAL OF INFORMATION SCIENCE AND ENGINEERING 18, 871-889 (2002)

871

Designing a Complete Model of Role-based Access Control System for Distributed Networks

CHANG N. ZHANG AND CUNGANG YANG

Department of Computer Science University of Regina, Trlabs

Regina, Saskatchewan, S4S 0A2, Canada E-mail: zhang@cs.uregina.ca

E-mail: cungang@cs.uregina.ca

In distributed computing environments, users like to share resources and communi-

cate with each other in order to perform their jobs more efficiently. It is important to keep resources and information from unexpected use by unauthorized users. Therefore, in the past few years there has been a strong demand for access control of distributed shared resources. Role-Based Access Control (RBAC) has been introduced and has of-fered a powerful means of specifying access control decisions. In this paper, we pro-pose an object-oriented RBAC model for distributed systems (ORBAC) to efficiently represent the real world. Moreover, under the decentralized management architecture, an ORBAC implementation of the model has been extended to realize multiple domain access control. Finally, an automatic intelligent role assignment backtracking algo-rithm is presented. The computation complexity of the algorithm is O (N) where N is the number of roles in the authorized role set of a user.

Keywords: ORBAC, separation of duties, least privilege, constraint, public/private key, multi-domain access control, credential

1. INTRODUCTION

In distributed computing environments, users share resources and communicate with others so that may work more efficiently. With the increase of the shared re-sources in distributed systems, unauthorized access to information by illegal users has also increased. To protect the resources in a distributed computing environment, it is necessary to secure the data through a user authentication and access control policy.

Access control is comprised of three different categories, Discretionary Access Con-trol (DAC), Mandatory Access Control (MAC), and Role-based Access Control (RBAC). MAC enforces access control on the basis of information security labels attached to users and objects. It shows an access control relationship that cannot be changed by the object owner. MAC can consistently determine all kinds of access controls between subjects and objects. Security labels have to be granted to all subjects and objects by the system supervisor, and can be changed only in accordance with the content of the object. Nowadays, MAC is mostly applied in military and government. As MAC policy is not flexible, it is not suitable for use in commercial areas. In the case of DAC, each object has an access control list, indicating all the authorized accesses by those subjects for such

Received August 30, 2001; accepted April 18, 2002. Communicated by Jang-Ping Sheu, Makato Takizawa and Myongsoon Park.

CHANG N. ZHANG AND CUNGANG YANG

872

those subjects for such objects. However, in a large distributed system there are millions of objects, each of which is assigned to thousands of subjects, so the access control list is enormous and its maintenance is difficult and costly.To give an acceptable solution, Role-Based-Access-Control (RBAC) as a key security technology was proposed [1].

Compared with DAC, RBAC determines access permissions that roles can perform, and assigns roles to users. Users can access objects according to the roles assigned to them. As a result, the organization can not only preserve access control policy appro-priate to its characteristics consistently, but also maintain access control relationship be-tween subjects and objects independently. The central notion of RBAC is that users do not directly access enterprise objects, but instead, access privileges that are associated with roles, and each user is assigned to one or multiple members of appropriate roles. This idea greatly simplifies management of authorization while provides great flexibility in specifying and enforcing enterprise-specific protection policies and reduces the man-agement cost. Users can be assigned to members of roles as determined by their re-sponsibilities and qualifications. They can be easily reassigned without modifying the underlying access structure.

Moreover, RBAC supports two basic security principles, least privilege and separa-tion of duties.

The principle of least privilege has been described as important for meeting security objectives [2], and requires that a user is given no more privileges than necessary to per-form a job. Ensuring least privilege requires identifying what the user’s job is, deter-mining the minimum set of privileges required to perform that job, and restricting the user to a domain with those privileges and nothing more.

RBAC mechanisms can be used by a system administrator in enforcing a policy of separation of duties. A fraud can occur if an opportunity exists for collaboration be-tween various job related capabilities. The most commonly used example is the sepa-rate roles needed to initiate a payment and to authorize a payment. No single individual should be capable of executing both roles. Separation of duties can be either static or dynamic. Consider the case of initiating and authorizing payments. A static policy could require that no individual who can serve as payment initiator can also serve as the payment authorizer. Such a policy may be too rigid for some commercial uses, where more flexibility could be given by a dynamic policy that allows the same individual to take on both initiator and authorizer roles, except that they can be activated at the same time.

In the last few years, the fundamentals of RBAC policies have been identified [1], and a number of RBAC models have been proposed to satisfy security requirements in different areas, such as role-based access control administration model [3-5], lat-tice-based access control model [6], but they are all concept models and do not effi-ciently represented the real world.

In this paper, we propose a new variation of RBAC model called Object-Oriented RBAC (ORBAC). We use object technology to model application-level users access control because (1) object-oriented technology has been widely used in analysis and de-sign of large and complex distributed applications in which access control and security management are significant and complicated components. An object-oriented access control model should act as a critical part of a whole system model. (2) While different applications are diversified, their access controls have some common characteristics. Object-oriented technology is used to model these characteristics to reduce the burden of repeated development.

ORBAC MODEL FOR DISTRIBUTED NETWORKS

873

ORBAC differs from traditional ones as follows: (1) The model is object-oriented, making use of the advantage of object-oriented technology to further describe the origi-nal RBAC model. (2) The model extends access control from one administrative domain to multi-domain distributed applications. (3) It supports dynamic role authorization. (4) In this model, public role and private role are introduced, which are used to further sup-port the principle of least privilege. Moreover, role constraints, especially the constraint of separation of duty problem, are also presented and implemented by the model.

The rest of the paper is organized as follows. Section 2 introduces the decentral-ized security manager architecture. Section 3 explains every element of the proposed object-oriented role-based access control model. An automatic intelligent role assign-ment backtracking algorithm is also described in section 3. Finally, section 4 concludes the paper.

2. A DECENTRALIZED SECURITY MANAGEMENT ARCHITECTURE

For distributed systems, producing a secure authorization for a multi-domain system is a difficult task. Centralized network administration is costly and inflexible. To solve this problem, we propose an Object-oriented Role-based Access Control model (ORBAC) which extends the original RBAC model from one administrative domain to multiple access control domains that may be administrated by different security policies such as DAC, MAC, RBAC or ORBAC. A decentralized management architecture of the proposed ORBAC is shown in Fig 1. Assume domain1 is under the management of ORBAC and is comprised of multiple local domains. Foreign domains, such as foreign domain1, foreign domain2, and foreign domain3 can be administrated by DAC, MAC, RBAC or ORBAC.

In an enterprise environment, such as domain 1, all different local domains obey the same security policy. This architecture allows us to maintain a single domain security policy administrated by a domain security manager. Each local domain contains a par-tial set of this domain security policy. The basic elements for domain1 include a do-main security manager, a foreign security manager and multiple local domains which are comprised of a local domain security manager, multiple servers and clients. The main functions of each element are described below.

Foreign security manager: In distributed systems, a user may want to access re-sources located outside his/her administrative domain. The problem is how to provide authorization to a resource that is being accessed by a user from a foreign domain. In ORBAC, the main functions of the foreign domain are accepting the resource require-ments of other foreign domain users and return the results to the user under its foreign security policies.

Domain security manager: Define and maintain the ORBAC security policies, in-cluding domain and foreign security policies, establish security policy for every local domain management system and pre-define the inter-relationships among different local domains.

Local domain security manager: The main goals of the local domain security man-ager are authorizing local domain roles and resources to its local domain users, estab-lishing the relationships between different local domains and permitting access control form one local domain to another according to its local domain security policy.

CHANG N. ZHANG AND CUNGANG YANG

874

Fig. 1. Block diagram of decentralized management architecture of ORBAC.

Client: Accept the requirement of its local domain user to gain access to its local domain resource, other local domains or foreign domain resources, and returning the results back to the user.

Server: Check the local domain or a foreign domain user’s resource requirement and judge whether to authorize the access to the user or not.

ORBAC MODEL FOR DISTRIBUTED NETWORKS

875

3. AN OBJECT-ORIENTED ROLE-BASED ACCESS CONTROL MODEL (ORBAC)

The proposed Object-oriented Role-based Access Control model (ORBAC) de-scribed in Fig. 2 fully realizes the original RBAC functions. Also, it can be imple-mented on multi-domain distributed environments. A number of different viewpoints about RBAC have been discussed [7-9]. The abstract model defined in this paper in-tends to capture the essential features of RBAC and to extend it to satisfy the require-ments in the distributed environment.

In Fig. 2, Part I, which is administrated by the local domain security manager, de-scribes the relationships of each element in the local domain and the interrelationship between different local domains. Every element of part I is described in subsections 3.1 to 3.6. Part II is under the administration of foreign domain security manager, and de-tails of it are introduced in subsections 3.7 and 3.8. The domain security manager is in charge of defining every element of the model and their relationships.

Fig. 2. An object-oriented role-based access control model (ORBAC).

3.1 Domain Role Hierarchy and Local Domain Role Hierarchy

In the proposed model, the domain security manager creates the domain role hier-archy. The model is comprised of multiple local domain role hierarchies that are ad-ministrated by their local domain security managers. Fig. 3 shows an example of do-main role hierarchy which includes two local domain role hierarchies. Fig. 4 gives its two local domain role hierarchies.

CHANG N. ZHANG AND CUNGANG YANG

876

Fig. 3. Example of domain role hierarchy.

Fig. 4. Two local domain role hierarchies.

Generally speaking, in an enterprise environment, a role in one local domain may take on some tasks on another local domain, so it is necessary to establish the interrela-tionship among the roles in different local domains. For example, in Fig. 4, role C in domain 1 can be assigned access to role G in local domain 2. We call this kind of role C as extended parent role and role G an extended child role. The authentication and authorization procedure for an extended parent role will be carried out by both local do-main security managers [10, 11].

3.2 Public Role and Private Role

Generally, a senior role will inherit all the privileges of its child roles. Sometimes, it is useful in role hierarchies to limit the scope of inheritance. Consider the following situation. A project supervisor role is senior to both the test engineer role and the pro-grammer role. In the general condition, the project supervisor does not need to inherit all the privileges of the test engineers and programmers. For example, access to incom-plete work in progress may not be appropriate for the senior role. This situation can be accommodated by defining a new type of role called private role. For a certain role in the role hierarchy, we can also regard some of its child roles as private roles because they

ORBAC MODEL FOR DISTRIBUTED NETWORKS

877

are not used frequently, and others of its child roles as public roles. Public roles and their child roles are comprised of a public role sub hierarchy, private roles, and their child roles are comprised of private role sub hierarchy. An example of the public and private sub hierarchy is shown in Fig. 5.

Fig. 5. An example of public and private roles.

Public roles are always the general duties for the authorized users. At the same time, they can get their private roles if they apply. The introduced public and private roles further correspond with the principle of lease privileges and enhance the flexibility of the system.

In order to simplify the role assignment procedure on ORBAC, we suggest the following role authorization principle. Definition 1. Role authorization principle: If a user is authorized a role (public, private, or both), he will get all the privileges of the role.

To provide user with enough privileges to take on a task. This definition guaran-tees that if a user applies for a role, he will get all the privileges of the role. Property 1: If a user is authorized a role, the user will be authorized all the privileges of the role including its public and private role sets. Property 2: According to the principle of least privilege and definitions of public and private roles, by default, a user can get only the privileges of his public roles. The pri-vate roles should be applied separately.

CHANG N. ZHANG AND CUNGANG YANG

878

Property 3: If a privilege is shared by a user’s public and private roles, it belongs to both the user’s public role set and private role set.

Table 1 demonstrates the role authorization in a role hierarchy (public role sub hierarchy, private role sub hierarchy, and shared role sub hierarchy) where authorized role set means the role set which the local security manager preassigned to its local domain users. Applied roles indicates the roles a user applies for in a session. Authorized active roles represents all the child roles the user can get in the session.

Table 1. Privilege distribution for roles in Fig. 5.

Authorized Role Set

Applied Roles Authorized Active Roles Privileges

A A B, D, E 1, 2, 3, 4, 6 A A, C B, C, D, E, F 1, 2, 3, 4, 5, 6, 7 A B, E B, D, E 1, 2, 3, 4, 6

Example 1. Consider an example shown in Fig. 5 where user X’s authorized role set is {A}. The public role set of X is {B}, and his private role set is {C}. Privileges 1, 2, 3 are directly assigned to role D, privileges 4 and 6 are assigned to role E, privilege 5 is assigned to role C, privilege 6 and privilege 7 are assigned to role F. We have a role hierarchy as follows: A→ B, A→ C, B→ D, B→ E, C→ E, C→ F. Assume that the public role sub hierarchy of X is {B, D, E}, the private role sub hierarchy of X is {C, E, F}, the shared role hierarchy is {E}. From this we can compute the privileges of vari-ous roles and obtain the corresponding privilege distribution shown in Table 1. Assume X applies roles for three times. In the first time he applies for role {A}; the authorized active role set will be {B, D, E}. In the second time he applies for roles {A, C}, the authorized active role set will be {B, C, D, E, F}. In the last time he applies for the role set {B, E} and the authorized active role set will be {B, D, E}.

3.3 Four Basic Elements: User, Role, Session, Privilege

In the proposed model, a user is a human being or an autonomous agent, a role is a collection of privileges needed to perform a certain job, a privilege is an access mode that can be exercised on an object in the system, and a session relates a user to possibly many roles. A user can be assigned a number of different roles, and a role can have mul-tiple members. A role may have many privileges, and the same privilege can be associ-ated with different roles. ORBAC introduces role hierarchies to reflect an organization level of authority and responsibility. A hierarchy is defined by: If r i > r j , then role ri

will inherit the privileges of role rj, for example, in Fig. 3, A > B, A > C, B > D, B > E, etc.

Class User is a many-to-many relationship with class Role, and class Role is a many-to-many relationship with class Privilege. Class User is defined as

User id: identification of the user. Roles: refer to all the role objects of the user. Sessions: refer to all the session objects of the user.

ORBAC MODEL FOR DISTRIBUTED NETWORKS

879

We define class Role as

Role id: identification of the role. Public role set: refers to all his public roles. Private role set: refers to all his private roles Privileges: refer to all privilege objects of the role. Users: refer to all user objects of this role. Parent roles: refer to all direct parent roles. Child roles: refer to all direct child roles. Class role has functions such as adding, deleting, and modifying parent or child

roles, adding roles to users, adding, and deleting privilege objects. Also, class role can call multiple constraint functions, and they are used to check role authorization and solve role-role related problems, such as separation of duty problems. In order to better de-scribe the domain and local domain role hierarchy, a role description language is pro-vided in the Appendix.

A privilege is an approval of a particular operation to be performed on one or more objects. The relationship between roles and privileges is also many-to-many, as shown in Fig. 2. Class Privilege is defined as

Privilege id: identification of the privilege. Actions: define the actions of the privilege. Objects: objects which actions apply. Roles: refer to all role objects of this privilege.

Functions of class privilege include adding privileges to roles and deleting privilege

from roles. Class Session is described as

Session id: identification of the session. User: refers to the user object of the session. Roles: refer to all the role objects held by the session. Functions of the class include adding roles to session, dropping roles from session,

etc.

3.4 Role Constraints:

ORBAC assigns constraints to user-role authorization. One of the important themes of ORBAC is separation of duty or conflict of interest constraints. The goal of separation of duty is to improve security by requiring collusion among two or more users, where otherwise one user would be sufficient to perform some illegal activities.

Another example of the user assignment constraint is that a role may have a limited number of members. For instance, there is only one person in the role of chairman of a department. Similarly, the number of roles to which an individual user can have could also be limited. We call these constraints cardinality constraints.

CHANG N. ZHANG AND CUNGANG YANG

880

The concept of prerequisite roles is based on competency and appropriateness, whereby a user can be assigned to role A only if the user is already a member of role B. For example, only those users who are already member of the project role can be as-signed to the testing task role within that project. In this example the prerequisite role is junior to the new role being assumed.

Moreover, there still exist many other constraints besides the above three major types, such as time constraint which is concerned with how long the roles can be acti-vated.

D (Role set ) : Dynamic separation of duty constraint E ( Role set ) : Static separation of duty constraint T ( Start Time, End Time ) : Time constraint C ( Number ) : Cardinality constraint P ( Role set ) : Prerequisite role constraint

Fig. 6. An example of role constraints.

In Fig. 6, we show a single role hierarchy where arrows are used to represent inherited relationships (from parent to child) over four major constraints in which role A has a static separation of duty constraint with role E: (E (E)). Cardinality constraint is applied to role F, B and C. Time constraint to role E is (T (10:20, 6:00)), prerequisite constraint to role D is (P (A)). Also, dynamic separation of duty applied to role F is (D (E, A)), and static separation of duty to role C is (E(A)).

According to the role authorization principle, if a user passes the role constraints, he or she will get all the privileges of the role and its child roles. In the following we take Fig. 6 as an example to describe how ORBAC solves role constraints, especially separa-tion of duty constraints, using object model.

Example 2. Assume user 1 is authorized a role set {A, B}, user 2 is authorized a role set {D, E}, user 3 is authorized a role set {F}. The role hierarchy of Fig. 6 can be repre-sented as an object model shown in Fig. 7.

Assume that the security system is just started and object UR receives a series of users’ applications for roles.

ORBAC MODEL FOR DISTRIBUTED NETWORKS

881

Fig. 7. Implementation of role constraints using object model

● User 1 applies for roles A and B, checking Fig. 6 for the constraints and they are passed, Role A and B are authorized for user 1, and object session 1 is created.

● User 2 applies for roles D and E, because user 2 hasn’t satisfied the prerequisite role constraint for role D, so the request is refused.

● User 3 applies for roles A and B, their constraints are passed. Role A and role B are assigned to user 3, session 2 is created.

● User 2 applies for roles A and B, object UR checks role B, and finds user 1 and user 3 are using Role B in session 1 and session 2. So user 2’s application is refused again.

● User 3 applies for role E, in session 2 of user 3, object UR finds Role A has been authorized to user 3, role E and role A are separation of duty roles, so user 3’s appli-cation is refused.

3.5 UR

Association class UR defines user assignments between users and roles, and can be described as:

User id: identification of the user. Role id: identification of the role. The main function of UR is to realize role authorization by calling constraint func-

tions. A general implementation method was discussed in [10, 11].

3.6 Automatic Intelligent Role Assignment Backtracking Algorithm

Using an object model, we have realized role assignment in a dynamic environment,

CHANG N. ZHANG AND CUNGANG YANG

882

but the disadvantage of the method is that if a user’s application is refused the user should apply again using the same role set or different role set. Usually the user cannot judge what the system’s current status is and when it is suitable for him/her to apply, so in order to reduce the user’s manual operation for role application we present two auto-matic intelligent role assignment backtracking algorithms which are described below.

In the normal conditions, a user needs not apply for more senior roles to take on a regular task. The algorithms automatically realizes the role assignment procedure and further guarantees the principle of least privilege by the following new search strategies:

1. Strategy 1: Search child roles, then backtrack and search their parent roles. 2. Strategy 2: Search parent roles first, then backtrack and search their child roles.

The new strategies are reasonable for a role tree hierarchy because ● The user is authorized to get all his child roles. ● Usually a senior user may apply for a junior role sets to finish a task, senior

roles still available.

Property 4: The conditions of a search end:

● The user receives the authorized privileges of the role. ● User gets a refuse message when role constraints cannot be satisfied and all

search paths reach the dead-end roles or the roles he is not authorized. Definition 2. Dead-end role: a role that has no parent roles, such as role F and role A in Fig. 8.

Fig. 8. Role hierarchy for user T.

Moreover, a passed-table, an unpassed-table and an unpassedrole-table are intro-duced to make the search more efficiently.

Algorithm 1. Automatic intelligent role-assignment backtracking algorithm for strategy 1.

ORBAC MODEL FOR DISTRIBUTED NETWORKS

883

Input : user-id : identification of the user Role A: the role the user applies for.

Output : all privileges user get or refuse message. { int passed-table [ ] = 0, unpassed-table [ ] = 0, unpassedrole-table[ ] = 0 if (constraints of role A passed) go to 3: 1: searches its direct child roles (skip the roles if they exist in unpassed-table) and checks their constraints, then passed roles are added to the passed-table. For each unpassed role go to 1: Add all unpassed roles to unpassedrole-table and unpassed-table 2: For each role C∈ unpassedrole-table { 5: For each role C’s parent role D (D ≠ Dead-end role), skip the role if D exists in unpassed-table { if (role D ⊆ passed-table) goto 2 if ( constraints of role D not passed) { add role D to unpassed-table goto 5. } if (constraints of role D passed) goto 2. } } if (each role C in the unpassedrole-table passed its constraints) goto 3 Backtrack to role A

For A’s each parent role B (B ≠ Dead-end role), skip the role if B exists in unpassed-table.

{ if (constraints of role B passed) go to 3: } goto 4: }

3: return authorized privileges of role A to the user 4: return refuse messag Algorithm 2. Automatic Intelligent role assignment backtracking algorithm for Strategy 2.

Input: user-id: identification of the user Role A: the role the user applies for.

Output: all privileges user get or refuse message. { int passed-table [ ] = 0, unpassed-table [ ] = 0, unpassedrole-table[] = 0 if (constraints of role A passed) go to 3:

For A’s each parent role B (B ≠ Dead-end role), skip the role if B exists in unpassed-table. {

if (constraints of role B is not passed) add role to unpassed-table else go to 3:

CHANG N. ZHANG AND CUNGANG YANG

884

} Backtrack to role A 1: searches its direct child roles (skip the roles if they exist in unpassed-table) and checks their constraints, then passed roles are added to the passed-table. For each unpassed role go to 1: Add all unpassed roles to unpassedrole-table and unpassed-table 2: For each role C∈ unpassedrole-table { 5: For each role C’s parent role D (D ≠ Dead-end role), skip the role if D exists in unpassed-table { if (role D ⊆ passed-table) goto 2 if ( constraints of role D not passed) { add role D to unpassed-table goto 5. } if (constraints of role D passed) goto 2. } } if (each role C in the unpassedrole-table passed its constraints) goto 3 else goto 4: } 3: return authorized privileges of role A to the user 4: return refuse message

}

Example 3. Suppose user T’s assigned role set is {B, F} as in Fig. 8, and T applies for role E for a certain task. Assume strategy 1 is used. The longest search path of role E for user T is shown in Fig. 9 where role F is a dead-end role.

Fig. 9. Search path for automatic intelligent role-assignment backtracking algorithm.

ORBAC MODEL FOR DISTRIBUTED NETWORKS

885

The search path is comprised of three parts: I, II, III. Assume user T has not passed the constraints of role E. In part I search all child roles of role E: G, H, I. We assume user T passed role G, H, but failed role I, then role G, H are added to the passed-table. Next we check the child roles of Role I: L, M and N, we assume L and M are passed and N failed. In part II algorithm checks the parent roles of role N. If any of his parent roles: I, J, F has passed the role constraints, the required privileges of role E will be assigned to user T. Otherwise, backtracking to role E in part III and search par-ent roles of role E, B. If role B passes the role constraint, then the privileges of role E will be assigned, otherwise, user T’s application will be refused. The implementation of strategy 2 is similar with strategy 1.

Generally, a user may apply many roles for a task. In the worst condition, the al-gorithm 1 and algorithm 2 will search all the roles of the user’s authorized role set. We assume the number of the authorized role set for the user is N, the computation complex-ity of both algorithms will be O (N).

3.7 Foreign Domain User, Foreign Domain Role Hierarchy, Foreign Domain Privi-lege and Trust Credential Constraint

In our multi-domain distributed system, some domain privileges are open to foreign domain users. The privileges shared with foreign domain users are called foreign domain privileges. Foreign domain users share part of domain privileges under the trust cre-dential constraints which constrain what and how the privileges can be accessed by for-eign domain users.

Nowadays, multi-domain distributed systems face the problem of determining one another’s trustworthiness. Credentials make it feasible to manage trust establishment efficiently. Digital credentials are the online counterparts of paper credentials that peo-ple use in their daily lives, such as a driver’s license. They are signed by authorized parties and can be made verifiable and unforgeable. For example, the on-line library contains books, journals and conference proceedings that can be divided into three cata-gories: generally accessible, accessible to ACM members only, and accessible to IEEE members only. When a user wants to read a paper in ACM Transactions on Information and System Security, it is sufficient to prove that he / she is actually a member of ACM. All domain privileges can be divided into three groups:

1. The privileges that cannot be accessed by any foreign domain users. 2. General privileges that can be accessed by foreign domain users without any

constraints. 3. The privileges that can be accessed by foreign domain users under different

credential trust constraints. The privileges in group (3) may require different credential trust constraints which

should be satisfied if required. Class foreign domain privilege can be described as

Privilege id: identification of the privilege. Actions: defines the actions of the privilege. Objects: objects to which actions apply. Trust credential constraint: credentials required for foreign users. Foreign roles: refer to all foreign role objects of this privilege.

CHANG N. ZHANG AND CUNGANG YANG

886

In order to simplify the administration of foreign domain privileges, a foreign role hierarchy is presented to represent the establishment of a trust relationship based on cre-dentials. An example is shown in Fig. 10. The foreign domain privileges are divided into different groups, like the relationships of directories and files. We call foreign roles according to their shared characters, such as the image files, journals, books, audio files, etc. Different foreign domain privileges may require different credentials. The trust credential constraints of a foreign role are the union of its foreign domain privi-leges’ credentials. Similarly, the senior foreign role will inherit the credentials of its child foreign roles. The introduction of foreign role hierarchy will be much easier for foreign users to access. They can choose: (1) foreign roles only, (2) foreign privileges only, or (3) foreign roles and foreign privileges. Class foreign role is described as

Fig. 10. An example of foreign domain role hierarchy.

Foreign role id: identification of the foreign role. Child roles: refer to its child foreign roles. Trust credential constraint: credential required for foreign users. Foreign domain privileges: refer to all foreign domain privileged objects of the role.

Example 4. Consider an example shown in Fig. 10 where privileges 3, 5, 8 cannot be authorized to foreign domain users, while privilege 2 and 4 can be authorized to foreign

ORBAC MODEL FOR DISTRIBUTED NETWORKS

887

domain users unconditionally. Privilege 1 is authorized to role D under credential con-straint C1; privileges 6 and 7 are authorized to E under the credential constraint C2; privilege 9 is authorized to F under credential constraint C3. Every foreign role in the foreign role hierarchy inherits role G, which privileges can be accessed unconditionally. A sample relationship of foreign role, trust credential and foreign domain privilege is shown in Table 2.

Table 2. Relationship of foreign role, trust credential and foreign domain privileges of Fig. 10.

Foreign Role Trust Credentials Foreign Domain Privileges A C1 ^ C2 ^ C3 1, 2, 4, 6, 7, 9 B C1 ^ C2 1, 2, 4, 6, 7 C C2 ^ C3 2, 4, 6, 7, 9

D, F C1 ^ C3 1, 2, 4, 9 F, B C1 ^ C2 ^ C3 1, 2, 4, 6, 7, 9

3.8 URF

Association class URF deals with foreign domain access requirements (a foreign domain user accesses a local domain resource). A general implementation was discussed in [10, 11]. Class URF can be described as

Foreign user id: identify the foreign user. Foreign role: foreign role required by the foreign user. Foreign domain privilege: foreign domain privilege required by the foreign user.

The main function of class URF is to accept the foreign user’s foreign role/privilege requirements, evaluate the trust credentials provided, and return the authorized foreign domain privileges to the foreign user.

To reduce communication complexity, we provide a credential base for every for-eign domain user. As many credentials have a valid date, the credential base will be checked first. Credentials will not need to be checked during their valid time period.

4. CONCLUSIONS AND FUTURE WORK

In this paper we have presented an Objected-Oriented RBAC model (ORBAC). The driving motivation is to simplify security policy administration. The main contri-butions of this paper are that we have proposed a decentralized security management architecture, and based on it, we have realized multiple-domain access control. More-over, the introduced private role and an automatic intelligent role-assignment backtrack-ing algorithm are introduced to further enhance the principle of least principle on OR-BAC.

In large enterprise-wide systems, the number of roles and privileges can be in the hundreds or thousands, and user can be in the tens or hundreds of thousands. Managing these roles, privileges, users and their interrelationship is a formidable task. Moreover,

CHANG N. ZHANG AND CUNGANG YANG

888

How to maintain the secure status of our role hierarchy, for every basic element of OR-BAC, such as users, roles and privileges and how to add them, delete them, or change them without violate any constraint of the role, such as separation of duty, is still a prob-lem to be solved and suitable algorithms should also be presented.

REFERENCES

1. R. S. Sandhu, E. J. Coyne, H. L. Feinseein, and C. E. Younman, Proceedings of the First ACM Workshop on Role-Based-Access Control, ACM, 1996.

2. R. Sandhu and V. Bhamidipati, “The URA97 model for role-based administration of user-role assignment,” in T. Y. Lin and X. Qian, ed., Database Security: Status and Prospects, 1997, pp. 262-275.

3. R. Sandhu and V. Bhamidipati, “The ARBAC97 model for role-based administration of roles: preliminary description and outline,” Second ACM Workshop on Role- Based-Access-Control, 1997, pp. 41-54.

4. T. Jaeger and Frederquegiraud, “A role-based access control model for protection domain derivation and management,” Second ACM Workshop on Role-Based-Ac-cess-Control, 1997, pp. 6-7.

5. R. S. Sandhu, “Lattice-based access control,” Computer, Vol. 26, 1993, pp. 9-19. 6. D. Ferraiolo, J. Cugini, and D. R. Kulin, “Role based access control: Features and

motivacation,” in Annual Computer Security Applications Conference, IEEE Com-puter Society Press, 1995, pp. 241-248.

7. S. Sborn and Y. Guo, “Modeling users in role-based access control,” Fifth ACM Workshop on Role-Based Access Control, 2000, pp. 26-27.

8. R. Sandhu, D. Ferraiodo, and R. Kulin, “The NIST model for role-based access con-trol: towards a unified standard,” Fifth ACM Workshop on Role-Based Access Con-trol, 2000, pp. 26-27.

9. “Integrity in automated information systems,” Technical Report, No. p-2316, Na-tional Computer Security Center, 1991, pp. 79-91.

10. C. N. Zhang and C. Yang, “Specification and enforcement of object-oriented RBAC model,” 2001 IEEE Canadian Conference on Electrical and Computer Engineering, 2001, pp. 65-77.

11. C. N. Zhang and C. Yang, “An object-oriented RBAC model for distributed system,” 2001 IEEE/IFIP Conference on Software Architecture, WICSA 2001, pp. 11. 24-32.

Appendix: Role description language < Role Specification > : : = Role < Role Name > { < parent roles >; < child roles >; < public roles>; < private roles >; < privileges >; < constraints >; < parent extended roles >; < child extended roles >;

ORBAC MODEL FOR DISTRIBUTED NETWORKS

889

} < Parent roles > : : = < Role Names > < Child roles > : : = < Role Names > < Public roles > : : = < Role Names > < Private roles > : : = < Role Names > < Privileges > : : = < privilege > | < privilege >, < privilege > < Privilege > : : = ( < object >, < action > ) < Constraints > : : = < constraint > | < constraint >, < constraint > < Constraint > : : = ( constraint id : parameters ) < Parent extended roles > : : = < Role Names > < Child extended roles > : : = < Role Names > < Role Names > : : = < Role Name > | < Role Name >, < Role Name > < Role Name > : : = < Char > < object > : : = < Char > < action > : : = R | W | RW | Constraint id : : = < Char > Parameters : : = < parameter > | < parameter >, < parameter > Parameter : : = < Char > < Char > : : = A | B | … | 2 | a | b | … | 2 | 0 | 1 | … | - | #

Chang N. Zhang received the BSc degree in Applied Math from University of Science Technology, China, and the Ph.D. degree in Computer Science and Engineering from Southern Methodist University. In 1989, he joined Concordia University as a research assistant professor in Department of Computer Science. Since 1990, he has been with University of Regina, Canada, in Department of Computer Science. Cur-rently he is a full professor and leads a research group in paral-lel processing, data security and neural networks.

Cungang Yang received the M.S. degree in computer sci-ence from Jilin University of Technology, China. From 1999, he has been a Ph.D candidate in computer science from univer-sity of Regina, Canada. His research areas include role-based access control, information flow control, data security and pri-vacy, data encryption and web security.