Role based access control in a telecommunications operations and maintenance network

Final thesis Role based access control in a telecommunications operations and maintenance network Performed for Ericsson AB by Peter Gunnarsson LITH-IDA-EX 05/012 SE 2005-03-01

Final thesis Role based access control in a telecommunications operations and maintenance network by Peter Gunnarsson LiTH-IDA-EX 05/012 SE Supervisor: Mats Gustafsson Ericsson AB Examiner: Nahid Shahmehri Department of Computer and Information Science at Linköpings universitet

iii Abstract Ericsson develops and builds mobile telecommunication networks. These networks consists of a large number of equipment. Each telecommunication company has a staff of administrators appointed to manage respective networks. In this thesis, we investigate the requirements for an access control model to manage the large number of permissions and equipment in telecommunication networks. Moreover, we show that the existing models do not satisfy the identified requirements. Therefore, we propose a novel RBAC model which is adapted for these conditions. We also investigate some of the most common used commercial tools for administrating RBAC, and evaluate their effectiveness in coping with our new proposed model. However, we find the existing tools limited, and thereby design and partly implement a RBAC managing system which is better suited to the requirements posed by our new model. Keywords: Role Based Access Control, RBAC, security, authorization model, administration tools

v Acknowledgements The work behind and the writing of this thesis was done at Ericsson AB in Linköping during the fall of 2004. I would like to thank the people at the department for which I did this work. They have all been helpfull in various ways. I also would like to thank my examiner Nahid Shahmehri for valuable comments on my report. This thesis would not have been possible without my supervisor Mats Gustafsson. Thank you.

vii Contents 1 Introduction 1 1.1 About this thesis........................ 1 1.2 Motivation........................... 1 1.3 Problem description...................... 2 1.4 Contributions.......................... 3 1.5 Limitations........................... 3 1.6 Outline............................. 3 1.7 Reading instructions...................... 4 2 Role based access control (RBAC) 5 2.1 Background........................... 5 2.2 Why is RBAC is needed?................... 6 2.3 NIST reference models..................... 6 2.3.1 Flat RBAC....................... 7 2.3.2 Hierarchal RBAC.................... 8 2.3.3 Constrained RBAC................... 10 2.4 Enterprise RBAC (ERBAC).................. 11 2.5 The role versus the group concept.............. 12 2.6 Administration of RBAC................... 12 2.7 The OM-AM concept..................... 14 2.8 Summary............................ 15 3 Target environment 16 3.1 WCDMA and GSM networks................. 16

CONTENTS 3.2 Operations and maintenance................. 18 3.3 Infrastructure.......................... 19 4 RBAC for O&M networks 21 4.1 Methodology.......................... 21 4.2 Objective............................ 22 4.3 Shortcomings of existing models............... 23 4.4 Modifying existing models to create better ones....... 24 4.5 Model A............................. 25 4.5.1 Description....................... 25 4.5.2 Motivation....................... 26 4.6 Model B............................. 27 4.6.1 Description....................... 27 4.6.2 Motivation....................... 32 4.6.3 Possible extensions................... 33 4.7 Comparison........................... 33 4.8 Summary............................ 35 5 Evaluation of administrative tools 36 5.1 Evaluation criteria....................... 36 5.2 Evaluated tools......................... 38 5.2.1 Sun Java Identity Server................ 39 5.2.2 Computer Associates etrust Admin......... 40 5.3 Other tools........................... 41 5.3.1 IBM Tivoli access manager.............. 41 5.3.2 SAM Jupiter...................... 42 5.3.3 Calendra........................ 42 5.4 Evaluation summary...................... 42 5.5 LDAP directories versus relational databases........ 44 6 Conclusions and future work 45 6.1 Access control model for operations and maintenance networks 45 6.2 Evaluation of Administrative RBAC tools.......... 46 6.3 Future work........................... 47 6.3.1 Access control model for operations and maintenance networks......................... 47

ix 6.3.2 Evaluation of Administrative RBAC tools...... 48 6.4 Conclusions........................... 48 A RoleGUI 53 A.1 Requirements.......................... 53 A.2 Solution............................. 54 A.2.1 Database........................ 55 A.2.2 GUI........................... 55 A.3 Result.............................. 57 A.4 Similar work.......................... 57 B A formal description of model B 62 B.1 Definitions............................ 62 B.2 Predicates............................ 65

CONTENTS

1 Chapter 1 Introduction This chapter briefly describes the purpose and structure of this thesis. Reading instructions are given at the end of this chapter. 1.1 About this thesis This work was done at Ericsson in Linköping during the fall of 2004. It is the final part of my studies towards a masters degree in computer engineering at Linköping university, Sweden. 1.2 Motivation Ericsson provides systems for mobile communications to telecommunications operators around the world. Thousands of radio base stations and other equipment may be distributed over vast areas. Mobile access is provided for cities, countries and continents. To keep such networks running a large number of employees are needed. These employees, later referred to as users, perform various tasks, such as software and hardware upgrades. A telecommunications network must be running with practically no down-time. This creates a need for good access control. A user must be

1.3. Problem description prevented from performing tasks not meant for her. Users with the wrong privileges may knowingly or unknowingly cause great harm to the network, and thus preventing it to function properly. With traditional access control a user s permissions can be hard to determine. Permissions are assigned per object and to obtain a complete list of a users permissions, all objects must be examined. This means more work for security administrators. Role based access control, or short RBAC, can be used to reduce this work[31]. With RBAC, users are assigned to one or many roles. Each role is granted some permissions and users are indirectly assigned to these through the role. Available research suggest this will improve scalability of access control and offer more flexible means for administration of access control[2]. Ericsson is interested in how RBAC could be applied to operations and maintenance networks for telecommunications. 1.3 Problem description This thesis will investigate two problems: A model for RBAC that suits the needs of large distributed systems, such as the O&M from Ericsson is needed. The model should address some shortcomings found in available models, e.g: We expect some permissions in the target enviroment to be complex and hard to understand. An administrator should not be dealing directly with these permissions since this would require her to know complex details about the target environment. Available models try to fit all scenarios. This makes them hard to understand and work with in more complex environments. Would a specialized model be more effective? Available models assume that permissions are changing slowly. However, we expect changes to permissions to occur quite frequently. These changes should not mean lots of changes to entities in the role database.

3 A suitable tool for administration of the proposed RBAC model is needed. Is there an available solution suited for the target environment or should a new tool be developed? 1.4 Contributions This thesis investigates what a suitable model for role based access control would look like. Available models are investigated and evaluated according to a set of formulated criteria in the context of telecommunications networks. A new model, partly based upon existing ones, is constructed. A short market survey has been conducted to find a suitable tool for administering RBAC in the target environment. Some of the tools on the market are briefly evaluated. Requirements for such tools are first created. In the process of finding requirements, a simple prototype tool was developed. In the evaluation, focus is put on the ability to express the model found. The main contribution of this thesis is the access control model. Also the formulation of criteria for access control models and administrative tools is important. 1.5 Limitations No practical evaluation of the access control model is conducted. The model only includes high level aspects, and thus ignores issues relating to implementation of such models. Due to time constraints two tools is evaluated more thoroughly. 1.6 Outline This thesis covers three areas: RBAC theory, development of a model for the target environment and evaluation of tools for administration of RBAC models. The remainder of this thesis is as follows:

1.7. Reading instructions Chapter 2 Role based access control describes the theory behind role based access control. Chapter 3 Target environment gives a brief introduction to the target environment, the operation and maintenance networks for telecommunications. Chapter 4 RBAC for O&M networks gives an analysis of the requirements placed on a access control model in the target environment. Existing models are considered and new alternatives to them presented. Chapter 5 Evaluation of administrative tools presents available tools for administration of RBAC. Two tools are evaluated. Chapter 6 Conclusions summarizes the results and presents suggestions for further work. Appendix A RoleGUI describes a tool for RBAC administration. This tool has been developed for the administration of one of the RBAC models developed in chapter 4. Appendix B A formal description of model B gives a more thorough presentation of the preferred model developed in chapter 4. 1.7 Reading instructions Below are some suggestions to how to read this thesis: If you are interested in Read chapter General RBAC 2 Suitable models for the target environment 2, (3), 4, (appendix B), 6 Available tools for RBAC 5, (appendix A), 6

5 Chapter 2 Role based access control (RBAC) This chapter describes the concept of role based access control. Various aspects relevant to this thesis is presented. 2.1 Background Traditionally, user access has often been granted by adding permissions per object[31]. In large or complex organizations, users might have to be granted a large number of permissions in order to perform their work tasks. This becomes even more complex when users are spread over a large number of computers and perhaps over a number of locations. As a consequence of the complexity, it may become hard to determine which users have rights to do what. Administration of users and their permissions can quickly become hard to manage. Role Based Access Control, or RBAC[2], is an attempt to address these problems. By aggregating permissions into roles and then assigning users to one or many roles, RBAC simplifies permission handling. Roles can be created to fit various job functions within an organization and users can be assigned to them based on their qualifications and

2.2. Why is RBAC is needed? positions. Further information about the building blocks in possible RBAC implementations can be found in [14] by Mats Gustafsson. 2.2 Why is RBAC is needed? RBAC has been proposed by many authors as an alternative to traditional access control to simplify administration, such as [2], [32] and [11]. In large systems, the amount of permissions assigned to a user may become high. It may become hard to keep track of all permissions. When a user moves between positions in the company, her permissions are changed according to her new tasks because administrators do not have a clear view over the users permissions. They may fail to revoke all permissions that are not longer needed. Figure 2.1 shows how RBAC can be used to simplify administration of permissions. Permissions are aggregated into roles and administrators assign users to roles instead of users to permissions. In this way administrators have less relations to administer. Besides this, RBAC can be used to enforcing the principle-of-leastprivilege by using sessions. Sessions let the user activate only a needed subset of her roles. 2.3 NIST reference models RBAC is a complex topic and many different opinions of what it is and how it should be described have been presented over the years. For example ERBAC and ARBAC, both described later in this chapter, are two models for RBAC. In an attempt to create a unified view, Sandhu and colleagues, in [11], have proposed standard. It has been submitted to NIST, US National Institute of Standards and Technology and have become an ANSI standard. The standard provides three basic models for RBAC. They are described in the following sections.

7 Figure 2.1: All users have permissions on three resources and one user has permissions on an additional resource. On the left this is implemented without roles and on the right with roles. 2.3.1 Flat RBAC Flat RBAC is the fundamental model from which the other models originate. Flat RBAC consists of the four components[11]: users, roles, permissions and sessions, shown in figure 2.2. A user is a human being, a host or a process. It is the actions of the user which will be subject to access control. A role is a function within an organization. Many roles can be played by each user and every role can be played by several users. Permission is an abstract tuple consisting of an operation and an object. Each role is granted one or many permissions and each permission can be granted to many roles. Several instances of a connection to a system can exist. For each instance, the user can chose which of her roles to be active. A session is the particular instance of a connection and defines which roles are active.

2.3. NIST reference models Figure 2.2: Flat RBAC, each user can be assigned to many roles and each role can be assigned to many permissions. If a user is assigned to a powerful role, it is good practice to activate this role only when needed. This reduces the risk of damage due to user mistakes or session hijacking. Flat RBAC includes requirements for user-role review, i.e it should be easy to list the roles of a user and the permissions of a role. This is an important step to give administrators a better view of the permissions assignments in the system. 2.3.2 Hierarchal RBAC Hierarchal RBAC extends Flat RBAC, from the previous section, by adding hierarchies to roles, as shown in figure 2.3. A role inherits permissions from its parents. This allows new roles to be created by combining or extending existing roles. An example is given in figure 2.4. The proposed standard support two types of inheritance: multiple and limited[32]. Multiple inheritance permits inheritance in multiple steps; in figure 2.4 surgeon role inherits permissions from the nurse role. Limited inheritance imposes a limit of some kind, typically only inheritance in one step is allowed, thus preventing surgeons from inheriting permissions from nurses. The surgeon role will inherit only the doctor role. The two concepts may be mixed to achieve the best result. While role inheritance have advantages, some pitfalls exist. Some people would argue that the CEO of a company should be able to do everything his

9 Figure 2.3: Hierarchal RBAC extends flat RBAC by adding a hierarchy to roles. Figure 2.4: Inheritance can be used to combine or extend roles. In the example, a doctor has all permissions a nurse has plus some additional. At the same time a doctor is not allowed to perform surgery nor treat heart disease.

2.3. NIST reference models employees has permissions to. In most companies there are situations when this would be a bad thing. Consider figure 2.5, where the CEO inherits some undesired privileges. In a hospital it is not desirable to give the CEO permissions to prescript medication or view medical records. Figure 2.5: In this figure the CEO inherits permissions from the rest of the staff. In this case this have undesired effects; the CEO could view medical records, prescribe medication or worse perform surgery. 2.3.3 Constrained RBAC Sometimes it is relevant to impose regulations on how roles and permissions are assigned or activated. Various types of constraints have been proposed, below are some common constraints relevant to this thesis. Separation of duty intends to reduce the risk of fraud by preventing the same user from playing two certain roles. For example, it is relevant to prevent a user from being both CEO and auditor of the same organization. Another constraint may be controlling cardinality, e.g an organization may not have more than one chairman[32]. A temporal constraint may prevent users from playing certain roles at some hours[2].

11 Both static and dynamic constraints can exist. Static constraints are enforced when a user is assigned a role while dynamic constraints are enforced when a user attempts to activate a role. 2.4 Enterprise RBAC (ERBAC) ERBAC, or enterprise RBAC, is an extension of hierarchal RBAC. Large enterprises have systems of many various kinds, e.g Windows, Unix and web applications. ERBAC is developed to provide entire enterprises with RBAC. Kern presents ERBAC in [17]. When a user is assigned to a role in an ERBAC system the proper accounts automatically gets created on the target systems. These accounts are then granted local permissions based on the role-permission connections at enterprise level, see figure 2.6. One difference from traditional RBAC is the lack of sessions in the model. Generally there is no need to include sessions in the model but in this case the model makes implementation of global sessions harder. Sessions are managed by each target system in its own specific way. A benefit of ERBAC is that a large amount of target systems can be used without much reconfiguration. One drawback of ERBAC is that synchronization of roles, accounts and permissions have to be handled by an implementation. Figure 2.6: ERBAC, users and permissions are propagated to affected systems.

2.5. The role versus the group concept 2.5 The role versus the group concept Many operating systems provide the notion of groups. A common way to let a set of users share some resource is to make all of them members of a group, this group is then given permissions to that resource. Roles are instead a collection of users and permissions[32]. Users and permissions are assigned to roles. Users obtain their privileges through the roles. A permission can be assigned to an arbitrary number of roles. This far roles and groups may seem to achieve the same thing, in fact groups can in some situations actually be used to implement roles as described in [31]. In [31] Sandhu and colleagues explains the difference between roles and groups in the following way. On Unix systems, group membership is defined in the files /etc/passwd and /etc/group. It is easy to list members of a group by reading these files. It is equally easy to determine which groups a user is member of. But it is hard to determine which permissions groups, and thus users, have. Permissions are typically assigned per object and to establish a complete list of a group s or a user s permissions, all objects must be examined. This means examining every single file and catalog in the system. This becomes even harder in a distributed environment. On the contrary with roles it is easy to determine both assigned users and permissions. Each role keep track of its member and its permissions. 2.6 Administration of RBAC RBAC has been described so far, as a model for administering users and their permissions. But administrators should get their permissions from somewhere too. One way to address this issue is to assign administrators with special administrator privileges which are valid in the administration tools. These privileges control what administrators can do or not do. This can be done more or less complex. Simple ACLs could be used for this. Some papers, for instance [32] and [8], suggest that RBAC should be used to administer RBAC. This would especially be valuable in systems

13 with many decentralized administrators. Special roles with permissions to administer various parts of RBAC could be created. Administrative RBAC, or short ARBAC, described in section 2.6, is an example of this. ARBAC [32] developed by Sandhu and colleagues was the first model specially designed to administer RBAC models. Several revisions of ARBAC has been presented through the years. The base structures of all these are the same, see figure 2.7. Flat, hierarchal or constrained RBAC is extended by my mirroring roles and permissions to add administrative roles and permissions. These roles and permissions are used for delegating administrative rights on the model itself. The administrative roles and permissions are separated from regular ones. Users can be assigned to both regular and administrative roles. Figure 2.7: ARBAC96 was one of the first models to use RBAC to administer itself[32]. It can be interpreted as two RBAC sub models sharing the same users. The both sub models does not have to be of the same type.

2.7. The OM-AM concept The sub model for administrative roles does not have to be the same as for regular roles, e.g if regular roles are ordered hierarchically, administrative roles can be ordered without a hierarchy. ARBAC has been revised several times. The major difference between them is how rules for assignment handling looks like. A notion called prerequisite roles is used[30]. It prevents some roles to be assigned to users not already assigned to specific roles, e.g a user could be prevented from being assigned to the nurse role without first being assigned to the employee role. The latest ARBAC model, ARBAC02, described in [25], extends AR- BAC with user pools and permission pools. This is claimed to improve administration by giving structure to users and permissions. 2.7 The OM-AM concept Sandhu has proposed a reference framework for access control design called OM-AM (Objective Model - Architecture Mechanisms)[29], which consist of four abstraction layers: objective, model, architecture and mechanisms. However, the framework, is not limited to access control. For instance security solutions for the music industry[37] have been described with OM- AM. Figure 2.8: The OM-AM framework from [29]. Objective and model describe what to be done, while architecture and mechanisms describe how to do it.

15 Figure 2.8 illustrates OM-AM. No clear boundary between the layers exist, OM-AM is used to describe design and some aspects may be located on several layers. OM-AM can be used when designs are to be compared, transforming designs to a common form like OM-AM can help in the process. Below are the layers described in the RBAC context. Objectives Goals and requirements on the access control is identified. Model The model to address the objectives. This can be a derivative of any RBAC model. Many different models may fit here. Architecture The model can be realized in many ways. Should users contact a central server for authorization and authentication? Should servers providing services query some database in order to grant or deny access for users? Mechanisms Which mechanisms would be used to implement the solution? Certificates and encrypted communication may be two of the mechanisms to be used. 2.8 Summary This chapter has introduced the reader to Role Based Access Control (RBAC) and shown some of its benefits of RBAC. The NIST model and its variations have been described. Also ARBAC and ERBAC had been presented. Chapter 4 will find a suitable RBAC model by first examining how well these models fit the target environment. But first chapter 3 will make a brief presentation of the target environment.

Chapter 3 Target environment This chapter describes the intended target environment, operation and maintenance networks in telecommunications networks. Some introduction to the WCDMA network is also given. 3.1 WCDMA and GSM networks Recent years telecommunications operators have begun to deploy Wideband Code Division Multiple Access (WCDMA). In networks for mobile telephony and data transfers WCDMA is one of several 3G technologies. 2G (GSM) and 3G has similar network topologies. This section describe a simplified view of the WCDMA network but most of it applies to GSM as well. The Ericsson WCDMA radio access network, RAN, is shown in figure 3.1. To serve user equipment like mobile phones and other handhelds, a network of radio base stations, RBS, is deployed throughout the community[35][4]. These RBSes comprise of radio antennas and equipment for communication. Each radio base station is connected to a radio network controller, RNC. The RNC manages radio links, radio resources and handovers of mobile users between RBSes. Among other things the RNC also provides SMS,

Figure 3.1: WCDMA RAN 17

3.2. Operations and maintenance positioning and localization services to end users. All the RNCs are connected to the core network, CN, and the operations and maintenance, O&M, network. The core network provides access to both circuit switched and packet data networks. It contains many key elements for communication which is out of scope for this thesis. 3.2 Operations and maintenance The operations and maintenance network is used by administrators to configure and operate the radio network. Administrative functionality is provided by command line interfaces and various graphical interfaces. An operator can access a network element directly or via the Operations Support System for Radio and Core (OSS-RC)[33]. It supports centralized operation and maintenance of both core network and WCDMA as well as other radio networks, including GSM. Operators typically connect to the O&M network with thin clients over ICA, a proprietary protocol for running remote applications[36]. Administrative applications, mostly graphical, are used[7]. Every element of the radio and core network can be managed in this way. Management tasks are divided into four main areas: Configuration management This area covers installation and upgrade of software and hardware. Also backup of RAN software and configuration parameters. Various network configurations belong here as well. This area can be further divided into sub areas since many types and levels of networks and hardware exist. Fault management Faults are detected, reported and dealt with. Additional and redundant equipment can be activated to recover from failure. Performance management Radio network performance is monitored and stored. This data can for example be used for various optimizations of the network.

19 Security management This area covers administration of security features. Users and their access privileges to the management system are handled. There are several categories of employees working within these areas. Work tasks may be very different from one category to another and thus their need of software and authorizations vary. 3.3 Infrastructure Application servers and the OSS-RC master server provide operators with functionality. A certificate authority and a single login server are present to secure the solution by providing authentication of hosts and applications and authorization of hosts, users and applications[20]. Certificates and asymmetric keys are used in this process. When a user logs on to the system the single login server queries an LDAP server acting as a user repository. The O&M network, shown in figure 3.2, is based on the Internet Protocol (IP). To maintain the structure of this network, standard servers such as DHCP, DNS, NTP, FTP servers exist.

Figure 3.2: Operations & maintenance network 3.3. Infrastructure

21 Chapter 4 RBAC for O&M networks A model for management of the network described in chapter 3 is needed. This chapter presents an analysis of requirements on such model and how a model that fulfills them would look like. At the end of the chapter a suitable model is presented. The chapter is structured according to the OM-AM reference model, described in section 2.7, and presents the objective followed by two alternative models. Since this thesis strive to solve the task on a high level, the two lower layers, i.e architecture and mechanisms, are not addressed here. 4.1 Methodology In order to get to a suitable access control model for the target environment we have taken these steps: 1. A set of requirements, or objectives, is constructed by studying the target environment through various documents. 2. Existing models are evaluated with respect to these requirements. The result is that none is suitable, see section 4.3, therefore new models are created. 3. Two new models are created in an attempt to fulfill the requirements.

4.2. Objective 4. Models are evaluated to find the best solution among them. 4.2 Objective Several requirements need to be fulfilled in order to create a suitable access model for O&M networks. These requirements were identified by studying the available documentation regarding the operation and maintenance environment The requirements are: A Anticipated security objectives a network operator may have. 1 Temporal constraints; a user may receive temporal additional privileges while working a watch shift. Also a user may lose some of her privileges outside working hours. 2 Many hosts; a user should be able to have different permissions when connected to different hosts. 3 RBAC to administer RBAC; the model should be able to express administrator privileges on itself. 4 Role hierarchy; roles should be arranged in hierarchies. Role inheritance reduces the amount of explicit assignment and eases the work of administrators. 5 Principle-of-least-privilege; the model should support an implementation where users may chose to activate only a few of their roles. B Additional objectives relevant within context. 1 Delegated administrator privileges; administrator privileges should be granted on sub trees of entities, e.g an administrator may administer a subset of machines. 2 Types of administration privileges; administrators should be able to specialize in different tasks, e.g user management, userrole assignment, role-permission assignment. This may lead to more effective administration.

23 3 Organization structure; the structure of the organization should determine where users have their permissions. This helps when delegating administrators to different parts of a company. 4 Flexible hardware changes; when hardware is being added or removed, a minimum of entities should be directly affected. 5 Flexible software changes; when software is being added or upgraded, a minimum of entities should be directly affected. 6 Easy to use; the model should be as simple as possible. If the model is too complex it will not be used in the right way or not at all. 4.3 Shortcomings of existing models At first a couple of existing access models, e.g ARBAC and ERBAC, seem to fulfill the requirements above. However, this section points out some shortcomings with these models when applied to the target environment. Available models are based on NIST RBAC, described in section 2.3. Users are assigned to permissions through their role assignments, see figure 4.1. There are two drawbacks with this arrangement. Figure 4.1: The core of the available RBAC models consists of three entities; users, roles and permissions. They rely on the assumption that relation r1 will change more rapidly than relation r2. But if r2 changes fast this layout would be bad. Administrators will have to spend a lot of time administering the r2 relation. Firstly, each time a permission is changed, removed or added, all affected role-to-permission assignments need to be changed. In a system where permissions change often, this can lead to plenty of extra work for the administrators and thus objective B.5 is not met.

4.4. Modifying existing models to create better ones Secondly, if the number of permissions is high, administrators may not be familiar with all permissions. We anticipate permissions to be complex in the target environment. This can lead to mistakes when role-to-permission assignments are made. The target environment consists of a large number of systems, or targets, and permissions may need to be assigned per system. Existing models does not explicitly support permissions being granted on a per system basis. For example, one of the mobile networks in Germany is divided into a few regions. At normal daytime operation, administrators have privileges on equipment in their region. At night the same administrators may have privileges on equipment in the entire network. An implementation with existing models would generate a great number of special crafted permissions to achieve this. The conclusion is that it would be best if a new model for access control could be constructed to address these issues. The rest of this chapter presents two candidates for such. 4.4 Modifying existing models to create better ones The major critique, in the previous section, of the existing models is about the relation between roles and permissions. Work is initially concentrated on this relation and the result is a new abstraction level between roles and permissions. This is later shown in figure 4.3, where figure 4.1 shows the original relation. A model should support granting permissions on a per system basis. The two developed models make different attempts to add this.

25 4.5 Model A The first approach is depicted in figure 4.2. Figure 4.2: Model A; hierarchal RBAC is extended with targets and an abstraction of permissions. 4.5.1 Description Hierarchal RBAC, see section 2.3.2, is extended with the notion of targets and an abstraction level is added to the permissions. A hierarchy is added to the permissions as well. Sessions and constraints are omitted since they easily can be implemented at a lower abstraction level later on. Targets are the hosts or computers on which access control is applied. Each user is assigned to some roles and each role is assigned to some action profiles on a set of targets. Inheritance among targets is used to arrange targets into sets. Action profiles are assigned to some permissions. Inheritance among permissions is used to arrange permissions into sets. The inheritance among targets such that if a role is assigned to an action profile on a target, then the role is assigned to the action profile on all targets which are children to the first target. Permission inheritance works in a similar way. Action profiles assigned to a permission is implicitly assigned to all children permissions as well. Administrator privileges are given through a set of special administrator privileges. The scope of these are controlled by special administrator targets mapping subsets of e.g roles, targets and permissions.

4.5. Model A 4.5.2 Motivation This model have evolved from hierarchal RBAC and focuses on how roles and permissions are related to each other. Permissions can be assigned per target. Further, the new abstraction level among permissions have some advantages. Figure 4.3: To mitigate the impact of rapidly changing permissions a new abstraction level is added. The rapid changes are in many cases isolated to relation r3 while r1 and r2 remains unchanged. Software upgrades may change the available permissions. If roles were directly connected to permissions, all affected roles would had to be updated due to the upgrade. Action profiles prevents this by isolating changes to the connection between permissions and action profiles, see figure 4.3. This leads to less changes in the database. The abstraction of permissions has one more motivation. In a large system, an administrator may not know all details of how applications are used. Since some permissions in the target environment would deal with radio frequencies and other complex mechanisms, it would be hard for an administrator to assign permissions to roles if the administrator does not know any details of the permissions. Instead, by letting application developers or application specialists assign permissions to action profiles, the administrator can concentrate on assigning roles to action profiles. Some software upgrades may not even need updated connections between action profiles and permissions. The permission inheritance can help when new permissions are added. If new permissions are added deep down in the hierarchy, action profiles assigned to permissions further up are implicitly assigned to them through inheritance. Targets are the machines on which permissions are granted. Roles are

27 assigned to action profiles but also to targets, this is to establish where the action profile is valid. Telecommunications networks may grow rapidly and thus the amount of targets. To mitigate the impact on role assignments, targets can be arranged in trees. A new target may be added in the bottom of the tree; all roles assigned to targets further up in the hierarchy will automatically get access to the new target. This can also be used to create groups of targets. 4.6 Model B Like the previous model, this one introduces an abstraction level among permissions. In an attempt to model the real world, organizations and targets are added to the model. Figure 4.4: Model B, this model extends Hierarchal RBAC by adding an abstraction level to permissions. Organizations are added to improve manageability of the model. Later in this chapter, the model is illustrated using an alternative, more intuitive, view. 4.6.1 Description Some aspects of the previous model are also used here. The mayor difference is the organization entity.

4.6. Model B The organization, figure 4.5, has been the focus of this model. In real life, an organization owns or works on some equipment, e.g radio base stations at some location. Every employee within the organization has rights on the equipment, but which rights an employee has is decided by which role she is designated within the organization. Organizations can contain organizational units and can be modeled hierarchically. Typically organizations in the model are supposed to reflect the structure of the real life organizations. Large enterprises consist of smaller units which can be divided further, this is the case with the organization in the model as well. Users are stored in a flat structure with no dependencies upon each other. When a user is connected to an organization, a role is also selected. This is the role the user is assigned to within this context. With the role comes the permissions which the user can exercise on equipment, or targets of the organization. Several roles may be associated to each user in a organization. Users can be assigned to several organizational units. Targets are the systems, machines and platforms for which authorizations are controlled by this model. These targets can be ordered hierarchal implicitly forming groups. Different contexts may need different hierarchies and permissions. Targets can contain several types of servers and it could be practical to order servers in different ways, e.g geographically, topographically, logically or by type. In the model each order is called a dimension and each target can be member of several dimensions but can only exist once in each dimension. An example is given in figure 4.7. An organization which is connected to a specific target is indirectly, through inheritance, connected to the target s children. Figure 4.6 demonstrates this. User obtains permissions through roles and action profiles. Scope of administrator rights is determined by organizational structure within the model. A more thorough description of this model can be found in appendix B.

Figure 4.5: The user is employed as role 2 at organization A. The organization has access to targets in the group c, these may for example be the workstations located at the office. The user has the privileges of role 2 on all targets in group c. 29

4.6. Model B Figure 4.6: In this example the user from figure 4.5 is to be granted some privileges on some radio base stations, i.e group b. A sub organization, C, has been created to give this user access to the radio base stations. The user is assigned to role 1 on sub organization C, however role 2, 3 and 4 are indirectly assigned through role inheritance. Note that other employees at organization A will not have access to targets b unless they are associated with the sub organization.

31 Figure 4.7: Targets can be placed into groups and groups can further be grouped. These aggregations can be based upon several factors and it is possible for the same target to be part of more than one. A target can only exist once in each dimension. At the bottom the connection from roles, through access profiles, to permissions are illustrated. Roles and action profiles may be connected to permissions of many dimensions.

4.6. Model B 4.6.2 Motivation Employees work within organizations and it is natural to make connections between organizations and targets. Organizations can be made up by organizational units. Using organization in the model is an intuitive way of expressing where a user has her rights since it would reflect the real life situation. To reduce the knowledge requirements put on administrators of the model, permissions are grouped into action profiles. In this way application specialists may administrate the action profile to permission assignments. This also reduces the impact software upgrades can have on role to permission relations, see figure 4.3. Changes are limited to action profilepermission relations leaving role-action profile intact. In contrast to the model A, this model does not support permission hierarchies. A reason for this is to minimize complexity of the model. Also, no empirical study of permission hierarchies has been conducted. Dimensions let administrators group targets in different ways depending on the context. A target may have functions interacting with other targets, thus groups can be useful when delegating privileges. The same target may provide several distinct services interacting with different sets of targets. This leads to the need of several groupings for the same target. To reduce the number of assignable permissions each is bound to a dimension. This should improve administration effectiveness and help avoid mistakes. The model may be configured to let some administrators control the permissions administrators has on entities within the model. Several roles for administering the model can exist, e.g one to control user-organization assignments, another to control role-access profile assignment and a third to control organization relations. A user playing an administrative role has got privileges in organizations where she is assigned to that particular role. Organizations helps define on where, e.g roles, targets and relations, an administrator has got her rights. This is where the organization inheritance is useful. An administrator may be assigned to administer users at a large organization with many suborganizations in many levels.

33 4.6.3 Possible extensions Sessions and dynamic constraints can be added to this model in an implementation. Sessions can be used to let users activate only a subset of their roles. The principle-of-least-privilege, is dependent on users abilities to limit their set of active roles, it should be enforced to mitigate possible effects of user mistakes and session hi-jacking. A session is a structure where the user can choose to use a set of valid roles. If a user, who is also an administrator, is to print a document it is preferable she not is logged on with full administrators privileges. Instead she only activates those roles which let her print the document. It is possible to put constraints on users abilities to use certain roles under certain criteria. For example, it would be desirable to restrict usage of some roles outside working hours. Sessions indicate which roles are active for a user for the moment in the current connection instance. When a role is to be associated with a session, the implementation should dynamically examine if the role has any constraints. If the a role has a constraint preventing it to be used at the moment, the role to session assignment should fail. The primary reason for adding constraints to the model is to support temporal restrictions upon roles. 4.7 Comparison The both models are extensions of NIST RBAC. While the objectives are the same, the approaches to get there are somewhat different. We here give a comparison of the models and relate to the criteria in section 4.2. A.1 & A.5 Temporal constraints and principle of least privilege Constraints and sessions are assumed to be defined at a lower level. None of the models hinder a possible implementation, thus objectives A.1 and A.5 are met by both models. A.2 Many hosts Existing models fail in providing manageable means for administration of roles of many hosts. Both model A and B introduces targets

4.7. Comparison to remedy this. The solutions differ but both models met objective A.2. A.3 Self administration Nothing prevent the RBAC models from administrating themselves. Both models fulfills A.3 but model B with its organizations is better suited to generate a good implementation for this. A.4 Role hierarchy Since both models are extensions of hierarchal RBAC, they both provide role hierarchies and thus meet objective A.4. B.1 Delegated administrator privileges Model A provide no explicit means for delegating administrator privileges on subsets of users, roles etc. Model B is well suited for this objective. B.2 Types of administrator privileges Both models support implementations dividing administrator tasks into different types. B.2 is met. B.3 Organization structure Model A is not made to support organization structure although targets may be ordered in such way. Model B is created to express organization structure and thus meet objective B.3. B.4 Flexible hardware changes Target hierarchies of both models help to meet this objective. If changes are made deep down in a tree and users are assigned to relatives further up, nothing has to be done to update this relation. B.5 Flexible software changes Both models meet the objective by providing a new abstraction level among permissions.

35 B.6 Easy to use This objective is hard to measure. We anticipate the two models to be easy to use relative existing ones. Of the two, model B is considered to be most easy. 4.8 Summary The comparison suggests model B as the preferred model. The extra abstraction level of permissions of both model A and B improves handling of permissions in large evolving systems. Model B provides a superior handling of systems with several targets, and at the same time introduces to organization entity which helps delegation of administration privileges. One may ask why not combine the two models into a new improved model. The main difference between the models is the location of where the target relation connects to the rest of the model. This means that the two cannot be combined without modifying one of them. Further work may provide a combined model regarding the other aspects. Below is a summary of how well both models meet the objectives. Objective Model A Model B A.1 Temporal constraints yes yes A.2 Many hosts yes yes A.3 RBAC to administer RBAC yes yes A.4 Role hierarchy yes yes A.5 Principle-of-least-privilege yes yes B.1 Delegated administrator privileges partly yes B.2 Types of administrator privileges yes yes B.3 Organization structure no yes B.4 Flexible hardware changes yes yes B.5 Flexible software changes yes yes B.6 Easy to use partly yes

Chapter 5 Evaluation of administrative tools Given the model B, proposed in the previous chapter, the question arises how it can be administered and implemented in the target environment. Concrete questions are: Which tools for RBAC are available on the market? Are the available tools suitable for the proposed model within the target environment? This chapter investigates these questions by first establishing a list of criteria for tool evaluation and then examines a selection of available tools with respect to the formulated criteria. 5.1 Evaluation criteria In order to get the most out of this evaluation some criteria are needed. Emphasis is put on means to express the model, presented in section 4.6. The graphical user interface is also important.

37 To get a better perspective on what requirements to be placed upon the tools, a prototype tool has been developed. The tool is called RoleGUI and the work is described in appendix A. The criteria were mainly formulated during this process. M Model support, these criteria measures how well a tool can express the model and general RBAC. 1 Roles, the tool should handle roles. 2 Role hierarchy, the tool should be able to arrange roles into hierarchies. 3 Abstract permissions, to ease administration of role permission assignments, an abstraction of permissions should be used. This refers to action profiles in the model. 4 Permissions per target, users should be able to have different permissions on different hosts. 5 User-organization relation, users should be assigned to organizations. 6 Target inheritance, targets should be arranged into hierarchies or groups. 7 Dimensions, targets should be arranged in different ways depending on the situation. Different contexts may need different groupings. 8 User catalog, the tool should provide means for searching for and browsing users. 9 User-role relation, user-role relation should be administered via the tool. 10 User-role-organization relation, user-role-organization relations should be administered via the tool. 11 Principle-of-least-privilege, a possible implementation of user sessions should not be limited by the tool. U User interface, these criteria evaluates how intuitive and effective the graphical user interface is.

5.2. Evaluated tools 1 User overview, a clear view with the user and her roles and other assignments. This helps prevent administrators from making mistakes. 2 Role overview, a view of a the permissions of a role and/or action profiles. 3 Organization overview, a view of which targets and users are assigned to an organization. 4 Role hierarchy overview that shows how roles are related. It should be clear how a particular permission have become assigned to a role through inheritance. This will help administrators understand the possibilities and limitations with inheritance. 5 Adaptive interface, the user interface should adapt depending on the set of active roles the administrator has. Only functions which an administrator is authorized to use, should be visible. This can help reduce complexity experienced by the administrator and steepen the learning curve. 6 Simplicity, the user interface should only show options relevant to day-to-day activities. Other functions or operations should be available through menus or other means. As with U.5 this will reduce complexity and improve effectiveness. T Technical, other relevant terms related to technical issues. 1 Platform independence, the tool should be able to run on the most common operating systems. 5.2 Evaluated tools A short market survey showed that several tools offer similar functionality. For these reasons we have conducted a more in-depth study only for two systems. The tools studied were Sun Java Identity Manager and Computer Associates etrust Admin. Other tools were studied more briefly and they are presented in section 5.3.

39 5.2.1 Sun Java Identity Server The main target of this solution is identity management for large enterprises. It provides a web based interface for administration which makes it platform independent and mobile[22][21], a view of the application is shown in figure 5.1. This product was installed on a Solaris 9 system for evaluation. Identity Server can store information about employees and customers. If it is not preconfigured for a specific type of data, Identity Server is highly configurable and expandable to fit in various environments. Users can be organized in groups, roles and organizations. The server side is implemented as a collection of jsp scripts. To run them a web server or Suns Application Server is needed. Sun Directory Server, a LDAP directory, is used for data storage. All users, groups, roles and other data are stored in an LDAP directory. Administrators have to have knowledge of the underlying data structures and their names to perform some tasks. Figure 5.1: Sun Java Identity Server provides a web based interface for administration. Administration of users and roles is supported, see figure 5.2. Users can be assigned to several roles and each role is assignable to several users.

5.2. Evaluated tools However, the notion of permissions is lacking so an interpretation of what a role means is not available by default. Plug-ins can be developed to achieve this. This means that Identity Server is probably not suited for expressing our RBAC model without major customization and development of plug-in modules. Figure 5.2: A simple RBAC model is supported, permissions are not managed by Identity Server by default though. The user interface is powerful but does not provide easy overviews of relations between roles and users. Instead, focus has been placed on identity management, it seems like relations were not a priority when designing the GUI. Since there are weaknesses in how roles and permissions are handled, this solution is not ready for RBAC as described in the previous chapter. 5.2.2 Computer Associates etrust Admin This product is aimed at identity and password management for large enterprises[1]. A variety of computer systems can be managed using etrust Admin. etrust Admin is available both as a web based and a regular administration tool. No opportunity was given to try the web based tool but screenshots found on the Internet indicate the interface to be similar to the one of Java Identity Server. etrust Admin Server 8.0 has been installed on a Windows XP laptop. The fact that this tool is not web based has given the tool developers more freedom and possibilities when creating it. The tool feels more powerful than web based solutions. Unfortunately, in this case, with power comes complexity. The interface contains many tabs and options, and can be confusing at times.

41 Management can be delegated in several ways to improve administrators effectiveness, e.g administrators can be granted to administrate a set of roles and their members. Users can be assigned to roles and roles are assigned to one or many policies. A policy defines, where and when certain tasks can be performed. Several policies comes with etrust Admin. These can be used for authorization of users. This solution focus on password provisioning which is an important function identity management solutions today. One part of password provisioning is to allow users to reset their passwords themselves, this entails that many help desk calls can be avoided. The RBAC functionality is limited and is not ready to support more complex models, like model B. Hence, this solution is not ready for RBAC without some work. 5.3 Other tools A number of other tools are available on the market. interesting tools which are worth mention. Below are three 5.3.1 IBM Tivoli access manager Tivoli access manager[15] provides a complete solution for authentication, identity management and access control. Access control decisions are handled by provided modules[16] but can also be done by third-party applications using a standardized API. Administration is platform independent via a web interface. Access control is based on access control lists, ACLs, which for each object, or group of objects, state which permissions a user or group has on it. Karjoth, in [16], claims that a limited role based access control can be implemented in Tivoli access manager, without hierarchies though. As this RBAC implementation is based on per object ACLs, to determine a user s complete set of permissions all objects have to be traversed, hence this is not RBAC as stated in section 2.5. Further, realization of several aspects needed for my model, such as role hierarchies and constraints,

5.4. Evaluation summary have to be implemented using plug-ins[16]. My conclusion is that an implementation of the model with Tivoli access manager would be infeasible. 5.3.2 SAM Jupiter SAM Jupiter[17][18] implements the ERBAC model for RBAC. This candidate was dismissed early since ERBAC is not suitable to express the model. ERBAC, described in section 2.4, does not support an extra abstraction level among permissions. 5.3.3 Calendra No opportunity was given to take a closer look at this product[5]. The company claims to provide RBAC support but this has not been verified. Except for standard identity management function this product provide support for viewing users and resources on maps. 5.4 Evaluation summary Our investigation reaffirms the conclusion of Archie Reed in [28] that many solutions do not provide full RBAC support. The primary purpose of the investigated products seems to be to provide a central catalog of identities and their privileges. All the solutions studied use some form of LDAP directory backend. Many companies already use LDAP directories to store users so solution developers have chosen to support it. However other types of databases would be better suited for RBAC since relations are implemented on a meta level in LDAP directories. There is a striking resemblance between all studied products. The difference lies in which extra features are supported. Mainly all products try to implement as many features as possible, but user interface usability seems to have been forgotten. Sometimes administrators need to know the underlying data structures and naming conventions in order to perform certain tasks.

43 Below is a table which summarizes how well the tools meet the criteria set out in section 5.1. IBM Tivoli and SAM Jupiter are not included since no thorough evaluation where conducted. Criterion etrust Admin Java Identity server M.1 Roles yes yes M.2 Role hierarchy no no M.3 Abstract permissions no* no* M.4 Permissions per host no* no* M.5 User-organization relation no limited** M.6 Target inheritance no no M.7 Dimensions no no M.8 User catalog yes yes M.9 User-role relation yes yes M.10 User-role-organization relation no limited** M.11 Principle-of-least-privilege yes yes U.1 User overview fair fair U.2 Role overview good n/a U.3 Organization overview n/a n/a U.4 Role hierarchy overview n/a n/a U.5 Adaptive interface good good U.6 Simplicity no no T.1 Platform independence no*** yes * This can be implemented using the provided API ** A user can only be part of one organization *** This table refers to the Windows version of etrust Admin Although no tools are suitable for the task, all are highly customizable and may be used after some extra work. I estimate this work to be large.

5.5. LDAP directories versus relational databases 5.5 LDAP directories versus relational databases Many available solutions use LDAP directories, also called LDAP catalogs, for data storage. LDAP directories provide hierarchal storage of elements, a structure comparable to most file systems. They are optimized for high speed reads of single data structures or sub-trees. This makes LDAP directories suitable for storing information like phone books and medical records. RBAC includes several relations between entities. These relations are sometimes too complex for LDAP. I feel relational databases are better suited for role-based access control.

45 Chapter 6 Conclusions and future work This chapter summarizes the goals and findings of this thesis and gives pointers to our future work. Since the work with access control models and the work with tool evaluation are quite different, the two topics are handled separately in this chapter. 6.1 Access control model for operations and maintenance networks The goal with this part was to find a role based access control model suitable for the target environment. We expect the amount of permissions in the target environment to be high. How much this is compared to other systems has not been investigated yet. A large number of permissions leads to complex role-to-permission relation management. This part included a study of the most known available models, such as ARBAC, ERBAC and NIST RBAC. It showed that little had been done to make role-to-permission assignments flexible and we believe that this may cause problems in our target environment.

6.2. Evaluation of Administrative RBAC tools During large software upgrades or installations, lots of role-to-permission assignments had to be changed or created. Further, when the amount of permissions is very high and permissions are complex in that sense that they are hard to understand, we believe administrators may get confused; an administrator may not know the implications of certain permissions and may need help to perform her task, or worse, assign wrong permissions to the wrong roles. The target environment consist of many hosts on which different groups of people may need different permissions. Available models did not explicitly support this. Two models, Model A and Model B, have been created in order to address these issues. The proposed models extend established models found in the literature. At the end of chapter 4, both models were compared and Model B was considered to be the best of the two. An extra abstraction level in model B, among permissions has been added. This reduces the amount of changes needed to be done to role-topermission assignments. It also divides the role-to-permission relation into two parts, making it easier to maintain. Further, complex permissions can be handled by specialized personnel via profiles at build time. To better support many hosts, we have added the organization concept. Users are assigned to roles within organizations and organizations are associated with some groups of hosts or targets. A side effect of this is that administration rights on the model can be better determined. 6.2 Evaluation of Administrative RBAC tools A tool for administering role based access control is needed. This part of thesis thesis aimed at finding a suitable tool available on the market, which could support the model created in this thesis. It is important to put good and realistic demands on the tools. In the process of creating requirements, a tool prototype was developed. This process resulted in, among others, several GUI requirements which probably would not be considered otherwise. When a list of requirements was ready, a short market survey was conducted to find out which major tools existed. It showed that several tools

47 were related to each other and offered very similar functionality. Due to this fact only two products were selected for further evaluation: Sun Java Identity Server and etrust Admin. Different degrees of support of RBAC can be offered by the administration tools and the current tools only included basic support. Role hierarchies and effective permission management functions were missing. No tool was close to fulfill the requirements needed to support the RBAC model developed in this thesis. Only the most simple RBAC models could be administered using these tools. Additionally, some shortcomings in how the GUI was designed were identified. One such shortcoming were that there were no possibilities to get good overviews of roles and permissions. Another shortcoming were that too many selectable alternatives were displayed at the same time, this may confuse administrators. The tools offer much unnecessary functionality, which in the long run probably affects both price and performance negatively. Because of shortcomings in model support and in the GUI, adaptations of these tools could be time consuming. This part comes to the conclusion that a suitable tool for the target environment is not available without first customizing it. The amount of work the customization implies may motivate the development of a completely new tool for the purpose. 6.3 Future work 6.3.1 Access control model for operations and maintenance networks The model evaluation is not based on any empirical tests. In order to get more accurate evaluation results models could be tested in a simulation of the target environment. This can be done by creating framework for an administration tool. The framework can then be used to create one administration tool for each model to be evaluated. Then a collection of use case scenarios can be performed on each tool. Several work such as [25] by Sandhu et. al. present sets of constraints and rules upon the respective models. The reason for these constraints and

6.4. Conclusions rules is to clarify which administrators can perform which tasks, e.g which are allowed to assign users to certain roles. An investigation should find out which constraints and rules are needed for the model proposed in this thesis. No thorough investigation of which constraints are needed in the target environment have been performed. Temporal constraints to limit the use of some roles at certain hours have been identified as useful. Further investigations need to be done in order to find other constraints needed in the target environment. 6.3.2 Evaluation of Administrative RBAC tools Little time was given to evaluation of existing tools. A more thorough investigation may find suitable tools even though this report indicates otherwise. This work has shown that usability of the evaluated tools is poor. A study can be performed to create a better user interface for this kind administrative tools. Further work can be done on the tool prototype developed during this work. 6.4 Conclusions This thesis was to find a suitable role based access control model for operations and maintenance networks in telecommunications networks. Requirements of such model have been constructed and a suitable model which fulfill them have been presented. Requirements for a tool for administration of the proposed access control model have been constructed. A short market survey have come up with two candidates which have been evaluated. This evaluation shows that neither of them are suitable without extensive modification.

49 Bibliography [1] Computer Associates. etrust Admin r8 datasheet, 2004. [2] Elisa Bertino. RBAC models - concepts and trends. Computers & Security, 22(6):511 514, September 2003. [3] Stefan Bilaniuk. A problem course in mathematical logic, 2003. http: //euclid.trentu.ca/math/sb/pcml/welcome.html. [4] Anders Birkedal, Eddie Corbett, Karim Jamal, and Keith Woodfield. Experiences of operating a pre-commercial WCDMA network. Ericsson Review, (2), 2002. [5] Calendra. Identity management with Calendra directory manager homepage, January 2005. http://www.calendra.com/us/iam.htm. [6] Peter Epstein and Ravi Sandhu. Engineering of role/permission assignments. In Annual Computer Security Applications Conference, 2001. [7] Ericsson. Operation and maintenance WCDMA RAN Rev. A. In Ericsson internal document. Ericsson AB, 2004. [8] David F. Ferraiolo and John Barkley. Specifying and managing rolebased access control within a corporate intranet. pages 77 82, 1997. [9] David F. Ferraiolo, John F. Barkley, and D. Richard Kuhn. A rolebased access control model and reference implementation within a cor-

BIBLIOGRAPHY porate intranet. ACM Transactions on Information System Security, 2(1):34 64, 1999. [10] David F. Ferraiolo, R. Chandramouli, Gail-Joon Ahn, and Serban I. Gavrila. The role control center: features and case studies. In Proceedings of the eighth ACM symposium on Access control models and technologies, pages 12 20. ACM Press, 2003. [11] David F. Ferraiolo, Ravi S. Sandhu, Serban I. Gavrila, D. Richard Kuhn, and Ramaswamy Chandramouli. Proposed NIST standard for role-based access control. Information and System Security, 4(3):224 274, 2001. [12] Jarek Gawor. LDAP Browser/editor 2.8.2, 2001. http://www-unix. mcs.anl.gov/~gawor/ldap. [13] L. Giuri and P. Iglio. A formal model for role-based access control with constraints. In Computer Security Foundations Workshop, pages 136 145. IEEE Press, 1996. [14] Mats Gustafsson. Bringing role-based access control to distributed systems. Technical report, 1997. LiU-TEK-LIC-1997:54, Thesis No. 653. [15] IBM. Security management solutions, buyers guide: purchasing criteria, tivoli software, February 2004. Available from IBM web page. [16] Günter Karjoth. Access control with IBM Tivoli access manager. ACM Trans. Inf. Syst. Secur., 6(2):232 257, 2003. [17] Axel Kern. Advanced features for enterprise-wide role-based access control. In Proceedings of the 18th annual computer security applications conference, pages 333 342, 2002. [18] Axel Kern, Martin Kuhlmann, Rainer Kuropka, and Andreas Ruthert. A meta model for authorisations in application security systems and their integration into RBAC administration. In Proceedings of the ninth ACM symposium on Access control models and technologies, pages 87 96. ACM Press, 2004.

51 [19] Axel Kern, Andreas Schaad, and Jonathan Moffett. An administration concept for the enterprise role-based access control model. In Proceedings of the eighth ACM symposium on Access control models and technologies, pages 3 11. ACM Press, 2003. [20] Lennart Löfgren. White paper: Security solutions for management of cellular networks. In Ericsson internal document. Ericsson AB, 2001. [21] Sun Microsystems. Identity server administration guide. Sun Java System, 2004Q2, 2004. [22] Sun Microsystems. Identity server technical overview. Sun Java System, 2004Q2, 2004. [23] Christer Nilsson. COMInf description Rev. C. In Ericsson internal document. Ericsson AB, 2004. [24] Matunda Nyanchama and Sylvia Osborn. The role graph model and conflict of interest. ACM Trans. Inf. Syst. Secur., 2(1):3 33, 1999. [25] Sejong Oh, Ravi Sandhu, and Xinwen Zhang. An effective role administration model using organization structure. In ACM Transactions on Information and System Security, 2003. [26] Larry L. Peterson and Bruce S. Davie. Computer networks, a systems approach, 2nd ed. Morgan Kaufmann publishers, 2000. [27] Karin Rappe. Roles and role management in role-based access control- model, design and implementation. Master s thesis, Linköping university, 1997. LITH-IDA-Ex-9652. [28] Archie Reed. The definitive guide to Identity Management. realtimepublishers.com, 2002. [29] Ravi Sandhu. Engineering authority and trust in cyberspace: the OM-AM and RBAC way. In Proceedings of the fifth ACM workshop on Role-based access control, pages 111 119. ACM Press, 2000. [30] Ravi Sandhu and Qamar Munawer. The ARBAC99 model for administration of roles. ACSAC, 1999.

BIBLIOGRAPHY [31] Ravi S. Sandhu. Role-based access control. In M. Zerkowitz, editor, Advances in Computers, volume 48. Academic Press, 1998. [32] Ravi S. Sandhu, Edward J. Coyne, Hal L. Feinstein, and Charles E. Youman. Role-based access control models. IEEE Computer, 29(2):38 47, 1996. [33] Pam Sheridan. Introduction to OSS-RC, description. In Ericsson internal document. Ericsson AB, 2004. [34] Richard T. Simon and Mary Ellen Zurko. Separation of duty in rolebased environments. In IEEE Computer Security Foundations Workshop, pages 183 194, 1997. [35] Rinke Terpstra. System description WCDMA RAN. In Ericsson internal document. Ericsson AB, 2004. [36] Wikipedia. Independent computing architecture, march 2005. http:// en.wikipedia.org/wiki/independent_computing_architecture. [37] S. Xu and R. Sandhu. Applying OM-AM to analyze digital rights management. In 7th International Conference on E-Commerce Research, 2004.

53 Appendix A RoleGUI To get a better understanding of the demands on administrative tools for RBAC, I developed a prototype. This chapter describes the process and results. This work began early during my thesis work. At the time only my first RBAC model, model A, described in section 4.5 on page 25, was available. A.1 Requirements The following requirements where considered. The tool should be easy and fast to implement. The tool should provide an easy-to-use GUI. The tool should be able to create, delete and edit users, roles and targets. Access profiles should be browseable. Administration of connections between users and roles should be possible.

A.2. Solution Administration of connections between roles, targets and access profiles should be possible. Administration of role hierarchies should be possible. Administration of target hierarchies should be possible. The purpose of the implementation was to obtain a feel for what requirements can be placed on a third party too. This can be achieved without implementing fully functional tool. Below are some limitations to speed up the development process. Constraints should not be treated. Permissions should not be treated. Sanity checks of user input and actions could be omitted. No requirements on database design and performance. User authentication and authorization could be omitted. A.2 Solution Based on previous experience, I chose Java as a development language in order to quickly get an implementation ready. The Java SDK provides many complete classes to construct various GUI functionality. I used Idea, an integrated development environment from IntelliJ that provides many features that help speed up the development process. Being an interface prototype, the implementation does not include any security functionality that would be required in a real-life implementation. This makes tool development a bit less time-consuming. The solution is depicted in figure A.1. A database had to be constructed in order to store user actions.

55 Figure A.1: Schematic view over the implementation. RoleGUI, incorporates both tool and database. The implementation, A.2.1 Database Some third-party systems use LDAP databases[16][22] but I use MySQL relational database. The main reason is that relational databases are well suited for expressing the access control model used. Figure A.2 shows an ER diagram of the database. Figure A.2: ER diagram of the database. This is a simplification of the diagram in figure 4.2. A.2.2 GUI The GUI has been designed using tools within IntelliJ IDEA. Emphasis has been put on usability. Throughout the user interface, dialogs and controls

A.2. Solution for similar functions are designed to look and function in the same way. This is to make newcomers feel comfortable with the controls more quickly. The main view, shown in figure A.3, shows users on the left and information about the selected user on the right. To quickly find the right user, a search function is provided, this is shown in figure A.4. Similar search functions are provided for roles, access profiles and targets as well. Figure A.3: Main view Information about a specific user can be edited in a separate dialog window, shown in figure A.5. Similar dialogs are provided where appropriate. The role assignments of users can be handled with a few clicks with the mouse. The role view, shown in figures A.7 and A.8, is similar to the user view. This is to simplify the development process and shorten the learning curve of the administrators. Information about the selected role is presented on the right side. Both role and target inheritance affects which access profiles that are valid. When access profiles and targets are to be bound to a role, a dialog is

57 Figure A.4: Search function shown. This dialog is depicted in figure A.9. Only options selectable at the moment are shown in order to make the GUI as self-explaining as possible. Targets can be arranged in hierarchies, shown in figure A.10. The hierarchy for the selected target is presented. A similar view is available for roles. Access profiles are not handled in this prototype but a view, shown in figure A.11, is provided by the application. A.3 Result An intuitive and easy-to-use user interface is important. An administrator should easily be able to get an overview of users, roles and permissions. The prototype developed provides all this. A.4 Similar work Some similar attempts have been documented. Rappe, to mention one, in [27] describes her administrative tool. That tool provides similar functionality but has not addressed usability aspects.

A.4. Similar work Figure A.5: User information Figure A.6: Role assignments

59 Figure A.7: Role view Figure A.8: A role has been selected.

A.4. Similar work Figure A.9: Dialog to select an access profile and a target to bind to a role. Figure A.10: Target hierarchies. Users with rights to Linköping office will have rights to the laser printer and the xerox machine through target inheritance.

Figure A.11: Access profiles 61

Appendix B A formal description of model B This chapter gives a more formal description of model B than the one given in section 4.6.1. Readers with no special interest may skip this as no new information is added. B.1 Definitions An introduction to some of the notation can be found in [3]. Entity sets These are the building blocks of the model, see figure B.1. User, U People which are to be given access to certain systems. This category can for instance include employees, administrators and trusted customers and partners. Organizational units, O

63 Figure B.1: Model B. Organizations are made up of hierarchies of organizational units. Role, R A role is the entity connecting both users and action profiles. Action Profile, A An action profile define a set of permissions. Permission, P Permissions are tuples of operation names and are defined at a low level by application providers. Target, T A target is a set of machines. Dimension, D Targets can be grouped in different ways depending on the situation. Each aspect of grouping is called a dimension and a target can exist in several dimensions. Permissions may be bound to a certain dimension.

B.1. Definitions Organizational units Organizations may include any number of sub organizations including zero. (o, ȯ) O sub iffȯ is a subunit of o. This relation is transitive, so (o 1, o 2 ) O sub (o 2, o 3 ) O sub... (o ξ 1, o ξ ) O sub (o 1, o ξ ) O sub. O sub is reflective. Role hierarchy Roles may be organized in a tree-like structure. Descendants are entities that direct or indirect are children of a certain entity. (r, ṙ) R sub iff ṙ is a descendant of r. This relation is transitive. (r, r) R sub is a tautology. Target hierarchy Targets may be organized in a tree-like structure. (t, ṫ) T sub iff ṫ is a descendant of t. This relation is transitive. (t, t) T sub is a tautology. User-role-organization assignment URA : U R O. A ternary relation that express an assignment between a user, an organization and a role. Access profile-permission assignment APA : A P. An access profile is assigned to a permission. Role-access profile assignment RAA : R A. A role is assigned to an access profile. An assignment (r, a) RAA also indirectly selects any access profiles assigned to roles from which r inherit.

65 Organization-target assignment OT A : O T. An organization is assigned to a target. An assignment (o, t) OT A indirectly assigns any sub target, i.e t((o, t) OT A (t, t) T sub (o, t) OT A). Dimension assignment DRA : D R DT A : D T Session and constraint Sessions and constraints are defined on a lower level and does not belong here. Sessions contain a set of roles and targets currently active. Sessions are volatile data structures existing for a relatively short period. They are created and deleted at users discretion. Constraints are checked by an implementation when a session is to be assigned to a role. B.2 Predicates The semantics for how model data shall be interpreted are presented here. hasp ermission(u, p) = r a(a, p) APA (r, a) RAA (u, r) URA hasp ermissionon(u, p, t) = hasp ermission(u, p) ( o(u, o) URA (o, t) OT A) This is to be used to determine administrative permissions on organizations. hasp ermissiononorg(u, p, o) = hasp ermission(u, p) ( ó(u, ó) URA (o, ó) O sub ) To implement sessions, similar predicates can be created with session instead of user.

Avdelning, Institution Division, Department IISLAB, Dept. of Computer and Information Science 581 83 Linköping Datum Date 2005-03-01 Språk Language Svenska/Swedish Engelska/English Rapporttyp Report category Licentiatavhandling Examensarbete C-uppsats D-uppsats Övrig rapport ISBN ISRN LITH-IDA-EX 05/012 SE Serietitel och serienummer Title of series, numbering ISSN URL för elektronisk version http://www.ep.liu.se/exjobb/ida/ Titel Title Rollbaserad behörighetskontroll i ett drift- och underhållssystem för telekommunikation Role based access control in a telecommunications operations and maintenance network Författare Author Peter Gunnarsson Sammanfattning Abstract Ericsson develops and builds mobile telecommunication networks. These networks consists of a large number of equipment. Each telecommunication company has a staff of administrators appointed to manage respective networks. In this thesis, we investigate the requirements for an access control model to manage the large number of permissions and equipment in telecommunication networks. Moreover, we show that the existing models do not satisfy the identified requirements. Therefore, we propose a novel RBAC model which is adapted for these conditions. We also investigate some of the most common used commercial tools for administrating RBAC, and evaluate their effectiveness in coping with our new proposed model. However, we find the existing tools limited, and thereby design and partly implement a RBAC managing system which is better suited to the requirements posed by our new model. Nyckelord Keywords Role Based Access Control, RBAC, security, authorization model, administration tools

Copyright Svenska Detta dokument hålls tillgängligt på Internet - eller dess framtida ersättare - under en längre tid från publiceringsdatum under förutsättning att inga extra-ordinära omständigheter uppstår. Tillgång till dokumentet innebär tillstånd för var och en att läsa, ladda ner, skriva ut enstaka kopior för enskilt bruk och att använda det oförändrat för ickekommersiell forskning och för undervisning. Överföring av upphovsrätten vid en senare tidpunkt kan inte upphäva detta tillstånd. All annan användning av dokumentet kräver upphovsmannens medgivande. För att garantera äktheten, säkerheten och tillgängligheten finns det lösningar av teknisk och administrativ art. Upphovsmannens ideella rätt innefattar rätt att bli nämnd som upphovsman i den omfattning som god sed kräver vid användning av dokumentet på ovan beskrivna sätt samt skydd mot att dokumentet ändras eller presenteras i sådan form eller i sådant sammanhang som är kränkande för upphovsmannens litterära eller konstnärliga anseende eller egenart. För ytterligare information om Linköping University Electronic Press se förlagets hemsida http://www.ep.liu.se/ English The publishers will keep this document online on the Internet - or its possible replacement - for a considerable time from the date of publication barring exceptional circumstances. The online availability of the document implies a permanent permission for anyone to read, to download, to print out single copies for your own use and to use it unchanged for any non-commercial research and educational purpose. Subsequent transfers of copyright cannot revoke this permission. All other uses of the document are conditional on the consent of the copyright owner. The publisher has taken technical and administrative measures to assure authenticity, security and accessibility. According to intellectual property law the author has the right to be mentioned when his/her work is accessed as described above and to be protected against infringement. For additional information about the Linköping University Electronic Press and its procedures for publication and for assurance of document integrity, please refer to its WWW home page: http://www.ep.liu.se/ c Peter Gunnarsson Linköping, 10th March 2005