Role based access control in a telecommunications operations and maintenance network

(1)

Role based access control in a

telecommunications operations and

maintenance network

Performed for Ericsson AB

by

Peter Gunnarsson LITH-IDA-EX–05/012–SE

(2)

(3)

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¨opings universitet

(4)

(5)

Abstract

Ericsson develops and builds mobile telecommunication networks. These networks consists of a large number of equipment. Each telecommunica-tion 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 telecom-munication 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

(6)

(7)

Acknowledgements

The work behind and the writing of this thesis was done at Ericsson AB in Link¨oping 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.

(8)

(9)

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¨oping during the fall of 2004. It is the final part of my studies towards a masters degree in computer engi-neering at Link¨oping university, Sweden.

1.2 Motivation

Ericsson provides systems for mobile communications to telecommunica-tions operators around the world.

Thousands of radio base stations and other equipment may be dis-tributed over vast areas. Mobile access is provided for cities, countries and continents. To keep such networks running a large number of employ-ees are needed. These employemploy-ees, 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

(14)

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 com-plex 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 fre-quently. These changes should not mean lots of changes to en-tities in the role database.

(15)

• A suitable tool for administration of the proposed RBAC model is

needed. Is there an available solution suited for the target environ-ment 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 accord-ing 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.

(16)

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 telecom-munications.

Chapter 4 RBAC for O&M networks gives an analysis of the require-ments placed on a access control model in the target environment. Existing models are considered and new alternatives to them pre-sented.

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

(17)

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 organiza-tion and users can be assigned to them based on their qualificaorganiza-tions and

(18)

2.2. Why is RBAC is needed?

positions.

Further information about the building blocks in possible RBAC imple-mentations 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 adminis-trators have less relations to administer.

Besides this, RBAC can be used to enforcing the principle-of-least-privilege 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.

(19)

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 origi-nate. Flat RBAC consists of the four components[11]: users, roles,

permis-sions and sespermis-sions, 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 per-mission 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.

(20)

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

(21)

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.

(22)

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].

(23)

Both static and dynamic constraints can exist. Static constraints are enforced when a user is assigned a role while dynamic constraints are en-forced 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 syn-chronization of roles, accounts and permissions have to be handled by an implementation.

(24)

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 de-scribed 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

(25)

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 admin-istrative 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.

(26)

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, administra-tive 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.

(27)

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 pro-cess.

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? Certifi-cates 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.

(28)

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 Wide-band 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 net-work of radio base stations, RBS, is deployed throughout the community[35][4]. These RBSes comprise of radio antennas and equipment for communica-tion.

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,

(29)

(30)

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 con-figure and operate the radio network. Administrative functionality is pro-vided 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]. Admin-istrative 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 redun-dant 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.

(31)

• 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 Proto-col (IP). To maintain the structure of this network, standard servers such as DHCP, DNS, NTP, FTP servers exist.

(32)

3.3. Infrastructure

(33)

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 alter-native 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.

(34)

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 study-ing the available documentation regardstudy-ing 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 imple-mentation 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 ad-minister a subset of machines.

2 Types of administration privileges; administrators should be able to specialize in different tasks, e.g user management, user-role assignment, user-role-permission assignment. This may lead to more effective administration.

(35)

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

up-graded, 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 af-fected 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.

(36)

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 tar-gets, 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 ex-isting 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

bet-ter 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.

(37)

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 abstrac-tion 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. Inheri-tance 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 administra-tor privileges. The scope of these are controlled by special administraadministra-tor targets mapping subsets of e.g roles, targets and permissions.

(38)

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 ab-straction 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 up-dated 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 be-tween 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 im-plicitly assigned to them through inheritance.

(39)

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 ab-straction 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 differ-ence is the organization entity.

(40)

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 struc-ture 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 authoriza-tions are controlled by this model. These targets can be ordered hierarchal implicitly forming groups. Different contexts may need different hierar-chies 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 demon-strates 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.

(41)

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.

(42)

4.6. Model B

Figure 4.6: In this example the user from figure 4.5 is to be granted some priv-ileges 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.

(43)

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.

(44)

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 or-ganizational 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 profile-permission 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 sub-organizations in many levels.

(45)

4.6.3 Possible extensions

Sessions and dynamic constraints can be added to this model in an im-plementation. 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 administra-tion of roles of many hosts. Both model A and B introduces targets

(46)

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 pro-vide role hierarchies and thus meet objective A.4.

B.1 Delegated administrator privileges

Model A provide no explicit means for delegating administrator priv-ileges 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 tar-gets 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.

(47)

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 ab-straction level of permissions of both model A and B improves handling of permissions in large evolving systems. Model B provides a superior han-dling 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

(48)

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.

(49)

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 organi-zations.

6 Target inheritance, targets should be arranged into hierarchies or groups.

7 Dimensions, targets should be arranged in different ways de-pending 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.

(50)

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 as-signed to a role through inheritance. This will help adminis-trators understand the possibilities and limitations with inheri-tance.

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 administra-tor 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 As-sociates eTrust Admin. Other tools were studied more briefly and they are presented in section 5.3.

(51)

5.2.1 Sun Java Identity Server

The main target of this solution is identity management for large enter-prises. 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 admin-istration.

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.

(52)

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 admin-istration 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.

(53)

Management can be delegated in several ways to improve administra-tors’ 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 autho-rization of users.

This solution focus on password provisioning which is an important function identity management solutions today. One part of password pro-visioning 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. Below are three interesting tools which are worth mention.

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 han-dled by provided modules[16] but can also be done by third-party applica-tions 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 deter-mine 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 sev-eral aspects needed for my model, such as role hierarchies and constraints,

(54)

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 candi-date 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 dif-ference 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.

(55)

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.

(56)

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 direc-tories 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.

(57)

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.

(58)

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 explic-itly 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-to-permission assignments. It also divides the role-to-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” con-cept. 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 pro-cess 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 con-ducted to find out which major tools existed. It showed that several tools

(59)

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 admin-istration 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

mainte-nance 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

(60)

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 tar-get 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 oth-erwise.

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 admin-istrative 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 op-erations and maintenance networks in telecommunications networks. Re-quirements 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 con-trol 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.

(61)

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.

Erics-son 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

as-signments. 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 role-based access control within a corporate intranet. pages 77–82, 1997. [9] David F. Ferraiolo, John F. Barkley, and D. Richard Kuhn. A

(62)

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

Pro-ceedings 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 crite-ria, tivoli software, February 2004. Available from IBM web page. [16] G¨unter 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

applica-tions 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,

Role based access control in a telecommunications operations and maintenance network

Role based access control in a

telecommunications operations and

maintenance network

telecommunications operations and

maintenance network

Abstract

Acknowledgements

Contents

Chapter 1

Introduction

1.1

About this thesis

1.2

Motivation

1.3

Problem description

1.4

Contributions

1.5

Limitations

1.6

Outline

1.7

Reading instructions

Chapter 2

Role based access control

(RBAC)

2.1

Background

2.2

Why is RBAC is needed?

2.3

NIST reference models

2.3.1

Flat RBAC

2.3.2

Hierarchal RBAC

2.3.3

Constrained RBAC

2.4

Enterprise RBAC (ERBAC)

2.5

The role versus the group concept

2.6

Administration of RBAC

2.7

The OM-AM concept

2.8

Summary

Chapter 3

Target environment

3.1

WCDMA and GSM networks

3.2

Operations and maintenance

3.3

Infrastructure

Chapter 4

RBAC for O&M networks

4.1

Methodology

4.2

Objective

4.3

Shortcomings of existing models

4.4

Modifying existing models to create

bet-ter ones

4.5

Model A

4.5.1

Description

4.5.2

Motivation

4.6

Model B

4.6.1

Description

4.6.2