Implementation of Role-Based Delegation Model/Flat Roles (RBDM0)

Transcription

1 Implementation of Role-Based Delegation Model/Flat Roles (RBDM0) Ezedin Barka, College of Information Technology, Alaa Aly, College of Information Technology, Wadhah Kuda imi, College of Information Technology, Kadem Hayawi College of Information Technology U.A.E. University, Al-Ain, P.O. Box: 17555, U.A.E. Abstract In the information security arena, one of the most interesting and promising techniques proposed is Role-Based Access Control (RBAC). In the last few years, much work has been done in the definition and implementation of RBAC. However, so far the concept of delegation in RBAC has not been studied. The basic idea behind delegation is that some active entity in a system delegates authority to another active entity in order to carry out some functions on behalf of the former. User delegation in RBAC is the ability of one user (called the delegating user) who is a member of the delegated role to authorize another user (called the delegate user) to become a member of the delegated role. This paper extends a series of simple but practically useful models for delegation, described in the literature by Barka and Sandhu [3], and starts the development of a scheme of prototype implementation in order to validate these models. More specifically, this paper reviews the most recent Role-Based Access Control (RBAC) Implementations, analyzes the implementation techniques used in other forms of delegations (other than the human-to-human delegation), and designes and develops prototype implementations of user-to-user role delegation based on the Role-Based Delegation Models, in flat roles (RBDM0), and in hierarchical roles (RBDM1). Keywords: Access Control, Temporary Self-Acted "Role" Delegation, Permanent "Role" Delegation, Revocation. RBAC, LDAP, X.509 (Certificate), XML, Authentication, Authorization. 1. INTRODUCTION In recent years significant work has been done on role-based based access control model, most of which has provided extensions to the model to address areas like constraints and delegations. Barka and Sandhu [3] presented a comprehensive approach to role-based delegation. More specifically, they identified the characteristics related to delegation, which can be used to develop delegation models. They used a systematic approach to reduce a large number of possible cases to smaller sensible ones, formally defined and developed some delegation models using roles based on those cases. In this paper, we were motivated by the need to carry out this work further and develop a prototype implementation of the role-based delegation models developed by Barka and Sandhu in order to validate these models and to show how they can be implemented in today's corporate networks. To avoid starting from zero, we have decided to study some of several works that have been done in the area of RBAC implementation and use them for our implementation of role-based delegation models [10], [13], [3], [4], [11], etc. We have adopted the PERMIS model [13] to start our work. The main idea of the PERMIS model is that user s role is stored in ACs, access control decisions are driven by an authorization policy, and the authorization policy is also stored in an AC. We have developed a delegation control engine that can make decisions according to a delegation policy. A demo system has also been developed. We emphasis that the scope of our work is to address the authorization of delegation only and not controlling the access (access control decisions are assumed to be addressed by RBAC). This paper is organized as follow ing: Section 2 overviews RBAC, RBDM, LDAP, and the PERMIS technologies. Section 3 describes our approach while Section 4 describes the demo system. Finally, Section 5 summarizes the conclusions and mentions some future work. CIT - 90 The Sixth Annual U.A.E. University Research Conference

2 2. Basic Technologies Used 2.1 Role Based Access Control (RBAC) College of Information Technology Role-based access control (RBAC) is well known and recognized as one of the most efficient models for controlling access in large organizations. The RBAC96 model, which was developed by Sandhu, et al.[10], is based on three sets of entities called Users (U), Roles (R), and Permissions (P) (see Figure 1). A user (U) is a human being or an autonomous agent. A role (R) is a job title or a job function in the organization with associated semantics concerning responsibility and authority. A permission (P) is a description of the type of authorized interactions a subject can have with one or more objects. Access control policy is embodied in RABC components such as user-role, role-permission, and role-role relationships. These RBAC components determine whether a particular user is allowed access to a specific piece of system data. A user can be assigned many roles, and a role can be assigned to many users. The many-to-many assignment relation User -Assignment (UA) captures this property. A role can be assigned many permissions, and permission can be assigned to many roles. The many-to-many assignment relation Permission -Assignment (PA) captures this property.. RH Role Hierarchy U Users UA User Assignment PA Permission Assignment R Roles P Permissions Constraints Fig. 1: Simplified Version of RBAC96 Model Definition 1.1: The RBAC96 model has the following components: 1. U, R, P, which are, respectively, the sets of users, roles, and permissions. 2. UA U x R, which is a many -to-many User -Assignment relation assigning a user to roles. 3. PA P x R, which is a many-to-many, Permission -Assignment relation assigning permissions to roles. 4. RH P x R is a partial order on R called role hierarchy. We have omitted the session concept from RBAC96 for simplicity, since it is not relevant to the work in this paper. The Sixth Annual U.A.E. University Research Conference CIT - 91

3 2.2 Role-Based Delegation Models (RBDM) In today's business environment, most organizations have some policies and rules that control these policies. Among these rules is what is known as delegation. The basic idea behind delegation is that some active entity in a system delegates authority to another active entity to carry out some functions on behalf of the former. Delegation in computers can be human-to-human, human-to-machine, machine-to-machine, and perhaps even machine-to-human. Most delegation models in the literature address human-to-machine and machine-to-machine delegation [3]. The role-based delegation models (RBDMs) focus is on human-tohuman delegation. Specifically, consider the ability of a user who belongs to a certain role to delegate a role "an authority" to another user who belongs to another role. For example, a professor in a university who is also a member in an advising committee role can delegate his/her membership in the advising committee role to another professor who belongs to another committee role. This delegation can take the form of being either permanent or temporary delegation. Moreover, the same professor can delegate only part of his/her professor role (i.e. instructor) to his/her assistant. This delegation can be only temporary. The RBDM took a comprehensive approach towards analyzing the problem of delegation. It began by identifying a number of characteristics related to delegation between humans, used these characteristics to create an exhaustive combination of possible delegation cases, developed a framework (described in the following sub-section) for building good cases that can be used for developing potential role-based delegation models, and lastly, developed some models, based on this framework, to illustrate how to implement delegation policies based on RBAC [3]. This work involved the investigation and formalization of role-based delegation models using nine different delegation characteristics RBDM Framework development approach In RBDM, the approach to develop a framework for identifying interesting cases that can be used for building role-based delegation models between humans began with the identification of a number of characteristics related to delegation between humans. The identified characteristics comprise permanence, monotonicity, totality, administration, levels of delegation, multiple delegation, lateral agreements, cascading revocation, and grant -dependency revocation. Trying to address every characteristic as mutually exclusive is a formidable task, and it can be very complicated. Therefore, a systematic approach was used in order to reduce the large number of possible cases. These reduced cases, which can be useful in business today, were used later to build delegation models. More definition and detailed explanation of these terms are provided in [2],[3] Reduction Approach Usin g different combinations of the above characteristics will give us a very large number of possible modes in which to perform delegation. Therefore, a systematic approach was pursued in order to reduce this large number of cases into a smaller number of useful ones. The following explains the framework used to identify the useful cases for developing role-based delegation modes. First, partitioned delegation based on its permanence (permanent or temporary delegation). We believe it is useful to develop delegation models that support the implementations of the permanent and temporary delegation policies. We further partitioned both the permanent and temporary delegations. The permanent delegation was partitioned based on its monotonicity, whereas the temporary delegation was partitioned based on its level of delegation. Finally, we partitioned single step delegation of the temporary delegation based on its monotonicity. After the partitioning was done, we then added the rest of the characteristics (one at a time) to each node and tested for combinations that are useful in business today and that can be used in developing delegation models. Figure 2 shows the combinations that appear useful in practice. On the permanent side, we could make the claim that there is one clear path that can be followed to develop a delegation model. That path includes the following characteristics: permanent, non-monotonic, self-acted, and total and multi-step delegation. Other characteristics do not have much effect on the model and were therefore ignored. On the temporary side, however, there are a number of possibilities; therefore, we have to make some simplification in order to identify useful combinations and ultimately to allow us to develop one comprehensive model for formulating user-to-user delegation. The simplification is to eliminate multi-step delegation, given that dealing with multi-step delegation is a very complicated issue. CIT - 92 The Sixth Annual U.A.E. University Research Conference

4 Delegation College of Information Technology Permanent Temporary Non-monotonic Monotonic Single step Multi-step Self-acted Total Monotonic Non-Monotonic (eliminated) Others not relevant Self Total/Partial Agent Partial G.D. revocation G.Ind. revocation Cascading R. Cascading R. Multi-delegation. (Comprehensive Model) 2.3 Lightweight Directory Access Protocol (LDAP) Fig.2: Framework for Role-Based Delegation Models User information is often a fragment across the enterprise. It leads to data that are redundant, inconsistent, and expensive to manage. Directories are viewed as one of the best mechanisms to make enterprise information available to multiple different systems within an organization. Directories also make it possible for organizations to access information over the Internet. LDAP is short for Lightweight Directory Access Protocol, a set of protocols for accessing information directories. LDAP is based on the standards contained within the X.500 standard, but is significantly simpler. And unlike X.500, LDAP supports TCP/IP, which is necessary for any type of Internet access. Because it's a simpler version of X.500, LDAP is sometimes called X.500-lite [13]. Although not yet widely implemented, LDAP should eventually make it possible for almost any application running on virtually any computer platform to obtain directory information, such as addresses and public keys. Because LDAP is an open protocol, applications need not worry about the type of server hosting the directory. LDAP has many other advantages such as quick and advanced search, quick response, easy maintenance and a hierarchy view of data. Besides, LDAP server can be used in a large-scale network system over Transmission Control Protocol (TCP) / Internet protocol (IP) as well as in a distributed system. It also can be utilized to many other applications [11, 13 ]. 2.4 PERMIS PERMIS is an authorisation infrastructure from the European Commission (EC) funded PrivilEge and Role Management Infrastructure Standards validation (PERMIS) project [Permis]. The work was done at the Information Security Institute of University of Salford, UK. Its objective is to implement an X.509 role based Privilege Management Infrastructure (PMI), and it concentrates on solving identification and authorization problems [4], [13]. The Sixth Annual U.A.E. University Research Conference CIT - 93

5 The PERMIS PMI architecture comprises a privilege allocation subsystem and a privilege verification subsystem. The privilege allocation subsystem is responsible for allocating privileges to the users. The privilege verification subsystem is responsible for authenticating and authorizing the users. PERMIS PMI uses X.509 attribute certificates (ACs) to store the users roles. All access control decisions are driven by an authorization policy, which is itself stored in an X.509 AC guaranteeing its integrity. All the ACs can be stored in one or more LDAP directories, thus making them widely available. Authorization policies are written in XML according to a DTD, that has been publishing at XML.org. Authentication is performed in an application-specific manner, but authorization is performed in an application-independent manner according to the PERMIS RBAC authorization policy. In this way one policy can control access to all resources in a domain [4], [13]. 3. Implementation 3.1. System Overview Our delegation system, which is based on the PERMIS RBAC implementation, has been developed in order to facilitate the delegation of permissions from a user who is a member of a certain role to another user who is a member of another role in order for the later to do some work on behalf of the former. This is done within the framework of RBAC96, which means that what is being delegated is actually a role, and the authorization for delegation is also role-based. Our system uses X.509 Public key certificates (PKCs) and X.509 attribute certificates (ACs) to store the user's roles. The PKCs and ACs are stored as one or more LDAP directories. The authentication is implemented using each user's PKC and AC, and the delegation authorization is implemented using a can-delegate relation, which is written in JAVA. This can-delegate relation is a function that works on the delegation policies, and the subject and role policies expressed in XML. All access control authorizations are assumed to be handled through RBAC, hence are kept out of the scope of our implementation 3.2 Delegation system major Components The basic components of the RBDM system as depicted in Fig. 3 are: - Administration tool This tool, which is part of the PERMIS Implementation, is responsible for creating key pairs and their public key certificates ; creating a role attribute certificate and assigning it to a user through, binding it to a user s public key certificate; inserting a XML format access control policy into a policy attribute certificate and binds it to Source Of Authorities (SOA s) public key certificate. And creating user entity in a LDAP server in order to manage the user's public key certificates and other information. - Policy Editor It is a PERMIS graphical user interface to generate an XML file for the RBAC policy. It also includes LDAP entries for subjects, roles, actions and resources. - Privilege Allocater It is also a PERMIS tool used for viewing, creating and editing Attribute Certificates based on X.509 standard and conformant to the ITU-T X.509 Recommendation. The Privilege Allocater takes an XML policy file, produced by the Policy Editor tool, as its input and generates the Attribute Certificates described above [4]. - Delegation Function This function decides if user (say Alice) who belongs to a certain role can delegate his role (say role X) to another user (say Bob) who is a member of another role. In our implementation, User Alice is called the Delegating User, user Bob is called the Delegated user and role X is called the Delegated role. The inputs to this function are the LDAP entries for the users and the role, and the output is the decision on whether the delegation is authorized or not based on the RBDM model delegation policy. - Web Server this web server is used for user authentication. To request delegation, a user must first connect to this web server via his browser and uploads his signature file to server side for authentication. After passing the authentication process, he can submit his delegation request. - Access Control Engine This type of an engine is part of all RBAC implementation using PERMIS. It is mentioned here only because our implantation is based on RBAC, and the ultimate goal for our delegation is to allow a delegate user to access some system resource, that is controlled by some access control engine, on behalf of the delegating user. during runtime the Access Control Engine is the center of all processes, first it authenticates the delegate user with the user's PKC, second it get the user's ACs, then gets the user s roles from his ACs. It will make the decision on whether the role has the right to CIT - 94 The Sixth Annual U.A.E. University Research Conference

6 access the target recourse according to a policy or not, and in case of permission, it will access the target and return the result to the user [ITU-T,]. - System Resources. All system data stored on a Web server, data server, file system or some other format data resources. Policy ACs Role ACs Administration Tool Delegation Function RBAC Access Control Engine System Resources Users Roles Fig. 3: Overview of the Delegation system 3.3 Delegation Protocol The delegation protocol can be expressed as shown in Figure 4. When a user wants to delegate some right to another user the following steps/ exchanges are executed: - User authentication: First, through RBAC authentication, the user uploads his signature to some access control engine to be authenticated. Once the user passes the authentication, a session will be set for him if he is a valid user. - Delegation request: The delegating subject submits a delegation request to a delegation server (message 1). This message contains the delegating user LDAP entry, the role to be delegated and the delegated user LDAP entry. - Verification exchange (message 2): This exchange takes place between the delegation server and some authentication entity within the access control engine. In this exchange, the delegation function passes the delegating user LDAP DN entry to the authentication entity in order to verify that the user is legitimate. - Delegation decision (message 4): Once the requesting subject is authenticated (message 3), The server then retrieves delegating user s AC and delegated user s AC, and checks if this delegation is permitted against the delegation policy. - Delegation establishment: The administrator updates the role credentials for the delegated user to include the delegated role. This is done by modifying the AC of the delegated user. - Access to system resources: upon the establishment of delegation, t he delegated user will be allowed by the Access Control Engine to access the system resource according the permissions assigned to the newly delegated role. The Sixth Annual U.A.E. University Research Conference CIT - 95

7 Authentication 2. Authentication exchange Delegation Server 3. Policy checking Delegation Policy 1. Delegation Request 4. Delegation Decision Delegating Role Delegation Target (Delegate) Role Access Control Engine Access System Resources Fig.4: Overview of the Delegation Protocol 4. Demo System 4.1. Demo System overview Our delegation demo system was developed in order to illustrate how our approach addresses how our developed delegation models can be implemented in real world. We use the example of the engineering organization (see Figure 5) to simulate a real world scenario. It is basically an organization with a hierarchical structure. At the bottom is all the employees that belong to the organization, and which have assess to all organization public resources. At the top is the director, who inherits the access rights of all users in all roles inside the organization. In between there are other roles which will have access to system resources depending on their place within the hierarchy. For example, a member of the engineering role (E1) can access (in addition to the public resource) only the resources that are assigned to the (E1) role. The Quality engineering role member can access (in addition to the public information and the resources assigned to E1) the resources assigned to QE1, and so on. CIT - 96 The Sixth Annual U.A.E. University Research Conference

8 Director Project lead 1 Project lead 2 Production Quality Production Quality Engineer 1 Engineer 1 Engineer 2 Engineer 2 (PE1) (QE1) (PE2) (QE2) Engineer 1 Engineer 2 Engineering Department (ED) Employee (E) Fig.5: An Example Role Hierarchy XML Role Hierarchy The Organizational Role Hierarchy shown in [Figure 5] has been represented in an XML file. Each role is assigned a value which is the name of the role. The inter-relationships among the roles in the engineering organization fall into two different classes: Superior Role (SupRole) and Subordinate Role (SubRole). For example, a Director user has a role value of Director and it has a SupRole inter-relationship with ProjectLead1 and ProjectLead2. Notice that the Director is at the top of the role hierarchy so it has no superior. On the other hand, ProjectLead1 and ProjectLead2 users have role values of ProjectLead1 and ProjectLead2 respectively and a SubRole inter-relationship with the Director. In turn, ProjectLead1 has SupRole inter-relationship with both ProductionEngineer1 and QualityEngineer1. Also, ProjectLead2 has SupRole inter-relationship with both ProductionEngineer2 and QualityEngineer2. Another example, opposite to the Director role is the Employee role, which is at the bottom of the hierarchy and does not have any subordinates. A sample of the XML file is depicted in [Figure 6]. <RoleHierarchyPolicy> <RoleSpec OID=" " Type="permisRole"> <SupRole Value="Director"> <SubRole Value="ProjectLead1"/> <SubRole Value="ProjectLead2"/> <SupRole Value="ProjectLead1"> <SubRole Value="ProductionEngineer1"/> <SubRole Value="QualityEngineer1"/> <SupRole Value="ProjectLead2"> <SubRole Value="ProductionEngineer2"/> <SubRole Value="QualityEngineer2"/> <SupRole Value="ProductionEngineer1"> <SubRole Value="Engineer1"/> <SupRole Value="ProductionEngineer2"> <SubRole Value="Engineer2"/> <SupRole Value="QualityEngineer1"> <SubRole Value="Engineer1"/> The Sixth Annual U.A.E. University Research Conference CIT - 97

9 <SupRole Value="QualityEngineer2"> <SubRole Value="Engineer2"/> <SupRole Value="Engineer1"> <SubRole Value="EngineeringDept"/> <SupRole Value="Engineer2"> <SubRole Value="EngineeringDept"/> <SupRole Value="EngineeringDept"> <SubRole Value="Employee"/> <SupRole Value="Employee"/> </RoleSpec> </RoleHierarchyPolicy> Fig.6: XML Role Hierarchy Policy and Users Attribute Certificates To provide a strong binding between the user s name and its roles, an attribute certificate should be created for each user by the Privilege Allocater tool. In addition an attribute certificate is created for the whole XML policy to establish a strong binding among the rules of assigning roles to users Role Extraction The Graphical User Interface of our implementation collects the following data: Delegating user LDAP DN entry, delegated user LDAP DN entry and the value of the role to be delegated. This data is used by the role extraction function to retrieve the role credentials of each user from his/her attribute certificate. The retrieved role credentials reference a node in the role hierarchy. This is important in making the delegation decision as explained next Delegation policy The delegation policy used is the RBDM policy (Can-Delegate function) explained in [3]. Now that we have a referenced node for the delegating and delegated users role credentials, we can test the inter-relationships between them. There are three conditions to check before making the delegation authorization decisions: First Condition: Check if delegating role-node is superior to delegated role-node in the hierarchy. If this case is true it will make the delegation authorized. For example, the delegation is authorized to the Director user for his/her delegation reques t regarding his/her role to ProjectLead1 user. Second Condition: Check whether the role to be delegated by the delegating user is an original or a delegated role. The delegation is authorized only for original roles. For example, ProjectLead1 user has his/her own original role Projectlead1 and its delegated role Director. The delegation function will authorize the delegation for the original role (Projectlead1) and does not authorize it for the delegated role (Director). Third Condition: Check if the delegating role-node and delegated role-node are non-comparable (meaning they are at the same level in the hierarchy), in which case, delegation is authorized. For example, ProjectLead1 user can delegate his/her original role to ProjectLead2 user). Anot her example, QualityEngineer1 cannot delegate his/her original role to QualityEngineer2 user, because although they are on the same level, they belong to two different projects. CIT - 98 The Sixth Annual U.A.E. University Research Conference

10 CONCLUSION In this paper, we reviewed the most recent Role-Based Access Control (RBAC) implementations, analyzed the implementation techniques used in other forms of delegations, and developed prototype implementations of user-to-user role delegation based on Role-Based Delegation Model in flat roles (RBDM0) and hierarchical roles (RBDM1). We used the well known and proven LDAP to store user information. We also developed an authorization function (delegation function), using Java, in order to add some control over our delegation. Through this implementation, we have shown that our role-based delegation models can work on the real world environment. Our future work will include implementing the rest of the RBDM models, and multi-step delegation. ACKNOWLEDGEMENT This work was financially supported by the Research Affairs at the UAE University under a contract no /04. The investigator would also like to express his gratitude to the student Waleed Al Ali for his diligent work through out our project. REFERENCES [1] Martin Abadi, Michael Burrows, Butler Lampson and Gordon Plotkin. A calculus for Access Control in Distributed Systems. ACM Transactions on Programming Languages and Systems, Vol. 15, No 4, September 1993, pages [2] Ezedin Barka and Ravi Sandhu. A Role-based Delegation Model and Some Extensions. Proceedings of 23rd National Information Systems Security Conference, Pages , Baltimore, Oct , 2000 [3] Ezedin Barka and Ravi Sandhu. Framework for Role-Based Delegation Models. In Proceedings of 16th Annual Computer Security Application Conference, New Orleans, LA, December [4] D.W. Chadwick, A. Otenko, The PERMIS X.509 role based privilege management infrastructure, Future Generation Computer Systems, Volume 19, Issue 2, February 2003, Pages [5] David Ferriaolo and Richard Kuhn. Role-based access controls. In Proceedings of 15th NIST-NCSC National Computer Security Conference, pages , Baltimore, MD, October [6] Morrie Gasser, Ellen McDermott. An Architecture for practical Delegation in a Distribut ed System IEEE Computer Society Symposium on Research in Security and Privacy. Oakland, CA. May 7-9, [7] B.W. Lampson, Protection. 5th Princeton Symposium on information science and systems. Pages [8] J.S. Park, R. Sandhu, G. Ahn, Role-based access control on the web, ACM Transactions on Information and System Security, 4 (1) (2001) [9] Ravi Sandhu and Venkata Bhamidipati. Role-based administration of user-role assignment: The UR97 model and its Oracle implementation. In Proceedings of IFIP WG11.3 Workshop on Data Security. August, [10] Ravi S. Sandhu, Edward J. Coyne, Hal L. Feinstein, and Charles E. Youman. Role-based access control models. IEEE Computer, 29(2):38-47, February [11] OpenLDAP, the Open Source Lightweight Directory Access Protocol (LDAP), [12] Rec X.812 (1995) ISO/IEC :1996 Security Frameworks for open systems: Access control framework, [13] Wei Zhou, Christoph Meinel: Implement Role-Based Access Control with Attribute Certificates Universität Trier, Mathematik/Informatik, Forschungsbericht 03-03: (2003) The Sixth Annual U.A.E. University Research Conference CIT - 99