role based access control - overview

Role Based Access Control:

What is it, why bother and how to implement it?

© 2014 Hitachi ID Systems, Inc. All rights reserved.

http://Hitachi-ID.com/

http://Hitachi.com/

Contents

1 Introduction 1

2 What is Role Based Access Control? 2

2.1 Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2.2 The NIST Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2.3 Introducing Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.4 RBAC and Enforcement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.4.1 Batch Enforcement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.4.2 Change Control / Security Administration with Roles . . . . . . . . . . . . . . . . . 6

2.5 Approved Exceptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.6 Automatic Role Assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.7 Separation of Duties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.8 Business Roles, Technical Roles and Role Hierarchy . . . . . . . . . . . . . . . . . . . . . . 11

2.9 Summary, RBAC Artifacts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3 Business Reasons for Deploying an RBAC System 14

3.1 Simplifying Security Change Requests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

3.2 Eliminating Privilege Accumulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

3.3 Standardizing Security Privileges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3.4 Cascading Changes to User Privileges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3.5 Simplifying Application Migrations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3.6 Coarse-Grained Separation of Duties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

4 RBAC Deployment Process 17

4.1 Role Modeling and Mining . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

4.1.1 Top-Down (Roles from Business Function) . . . . . . . . . . . . . . . . . . . . . . 17

4.1.2 Bottom-Up (Roles from Technical Analysis) . . . . . . . . . . . . . . . . . . . . . . 17

4.1.3 Mixed Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

4.2 Phased Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

5 RBAC Ongoing Maintenance 20

5.1 Change Authorization Workflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

i

RBAC: What, Why and How?

5.2 Periodic Certification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

5.2.1 User Privileges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

5.2.2 Role Assignments and Approved Exceptions . . . . . . . . . . . . . . . . . . . . . 21

5.2.3 Role Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

5.3 Managing Role Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

5.4 Adding Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

5.5 Retiring Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

5.6 System Migrations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

6 Organizational Impact 24

6.1 New Function: Role Analysts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

6.2 Managers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

6.3 Security Administrators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

6.4 End Users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

6.5 The Help Desk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

6.6 IT Auditors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

APPENDICES 27

A About Hitachi ID Systems 28

© 2014 Hitachi ID Systems, Inc. All rights reserved.



1 Introduction

This document is intended to introduce readers to role based access control (RBAC), as applied to largenumbers of users and multiple IT systems. It is organized into five distinct parts:

1. Development of RBAC concepts from a simple model to a complex but realistic privilege managementinfrastructure.

2. Business drivers to motivate organizations to use an RBAC system to manage security privileges.

3. Process for deploying RBAC into an organization.

4. Maintenance tasks for keeping a deployed RBAC system functioning smoothly.

5. Organizational impact of the deployment project and of the running RBAC system.

© 2014 Hitachi ID Systems, Inc.. All rights reserved. 1


2 What is Role Based Access Control?

2.1 Definitions

It is appropriate to start any discussion of role based access control (RBAC) with some definitions, toeliminate ambiguity. Following are some important concepts that will be used later:

User The electronic representation of a human being or an automated service.

Resource An IT asset – typically data or a function – which users may wish to access.

Privilege The ability granted to a user to access a resource.

Login account One type of privilege – a record that enables a user to sign into a particular system.

Security group A type of resource. Privileges are often granted to security groups, as this is more efficientthan assigning privileges to individual users.

Group membership Another type of privilege – a record that indicates that a user belongs to a securitygroup, and therefore has the privileges as those assigned to the security group.

Target system A system containing resources and on which privileges are managed. For example, anActive Directory domain, a RACF security database, a database, an SAP R/3 system/client instance,etc.

Security change request A request to change the privileges of a user.

Requester The user who submits a change request.

Recipient The user whose security privileges will be changed if a security change request is approved andapplied.

Authorizer A user who must approve a change request before it will be applied to the recipient.

Security administrator A user with the ability to submit change requests that require no authorization.

2.2 The NIST Model

Role based access control was popularized and given mathematical rigor by researchers working for theNational Institute of Standards and Technologies. Their work on RBAC is available at the following web site:

http://csrc.nist.gov/rbac/

The RBAC concepts in this document are loosely based on the definitions and concepts in the NIST RBACwork.


http://csrc.nist.gov/rbac/


2.3 Introducing Roles

To understand RBAC, one first has to understand the administrative burden of assigning privileges to indi-vidual users.

Consider an organization with 10,000 users and 10,000 resources and where each resource is accessedby an average of 20 users:

1. Security administrators must manage about 200,000 individual privileges (10,000 resources x 20users).

2. An average user has about 20 privileges (200,000 privileges / 10,000 users).

Continuing with this example, if users can be collected into groups of about 100 users each, where membersof each user group have identical access requirements, then:

1. There will be about 100 groups of similar users (10,000 users / 100 users/group).

2. Each group of users will have the same number of privileges as any of its member users had – about20.

3. In total, 2,000 individual privileges will have to be managed (100 groups x 20 privileges/group).

4. In addition, each user will have to be associated with a group – about 10,000 associations.

In other words, if user privileges are highly regular, as in our example, then 200,000 privileges can bereplaced by 2,000 privileges plus 10,000 user-to-group associations. This reduced complexity is the mainmotivation for RBAC.

These concepts are illustrated in the following figures.

1. Managing a single user’s privileges is illustrated in Figure 1.

Figure 1: A single user with privileges to multiple resources.

2. The same model, when scaled up to many users, creates administrative problems, as illustrated inFigure 2.



Figure 2: Managing user privileges directly for many users.

3. If roles are introduced then managing privileges for a single user is slightly more complex than man-aging privileges directly. This is illustrated in Figure 3.

Figure 3: Using a role to abstract a single user’s privileges.

4. Managing many users’ privileges is simplified by using roles, so long as many users have identicalrequirements. This is illustrated in Figure 4.

Figure 4: Reducing administrative burden for similar users with roles.



2.4 RBAC and Enforcement

RBAC is not built into every application. Moreover, few off-the-shelf applications are able to externalize theirruntime security enforcement decisions (i.e., “is user X allowed to access resource Y?”). As a result, RBACis typically overlaid on top of existing security models. This is done as follows:

1. Define roles as collections of privileges to access resources, where each privilege exists on a singleapplication.

2. Assign roles to users.

3. Using this model, predict which users should get which privileges on each application.

4. Extract from each application a list of privileges that each user actually has.

5. Calculate the difference between the predicted and actual user privileges.

6. Correct user privileges on each system, to make them match privileges predicted by each user’sassigned roles.

This enforcement process may be implemented in two ways:

1. Batch enforcement: the process is applied to every user, regularly. An example is an automatednightly process that brings users into compliance with the role model.

2. Change control / security administration: the security management user interface is changed sothat users or security administrators choose roles for recipients, rather than individual privileges.

2.4.1 Batch Enforcement

Batch enforcement is illustrated in greater detail in Figure 5.

In the Figure:

1. An automated process runs connectors to extract a list of users, resources and privileges from eachtarget system.

2. User assignment to roles is combined with role definitions to predict the privileges that each usershould have.

3. Actual user privileges, as discovered on target systems in the first step, are compared to predictedprivileges.

4. Any differences between actual and predicted user privileges are applied back to target systems, toremove the variance and bring actual user privileges into compliance with the role model.



Figure 5: Simple batch enforcement of RBAC privilege model.

2.4.2 Change Control / Security Administration with Roles

Normally batch enforcement is combined with a role-centric security management process. The idea is toreplace security administration by assigning individual privileges to users with assignment of roles to users.

This is illustrated in Figure 6.

In the Figure:

1. If a self-service work-flow system is used, end users request and approve changes.

2. Security administrators make direct changes (without waiting for authorization).

3. All changes are expressed in terms of roles. For example:

(a) Create new user X using role R.

(b) Delete user X (i.e., remove all roles from user X).

(c) Remove role R1 from user X and add R2.

4. The RBAC engine maps role changes such as the above, to privilege changes (create/delete login



Figure 6: Security administration using roles.

IDs, attach users to security groups on target systems, remove users from security groups on targetsystems).

5. Connectors apply those changes to target systems.

2.5 Approved Exceptions

The simple model described in Subsection 2.3 on Page 3 and Subsection 2.4 on Page 5 can be quitedifficult to manage in practice, since user privilege requirements are often unique.

If every user has at least one unique requirement, and a pure role model such as the one described inSubsection 2.3 on Page 3 is used, then there will be as many roles as there are users. When this happens,RBAC adds a layer of complexity without providing any leverage to simplify user administration. In otherwords, as the number of roles approaches the number of users, RBAC reverts to direct user managementand provides no benefit.

To address this issue, practical RBAC systems should incorporate a concept of approved exceptions. Thisallows users to have privileges that diverge from what their role assignment predicts and for the organizationto approve these exceptions, so that the enforcement engine (shown in Figure 5 on Page 6) does not“correct” those variances.

A user’s privileges may vary from what his assigned roles predict in several ways:

1. Extra account: The user may have an extra login account.



2. Extra group: The user may have an extra membership in a security group.

3. Missing account: The role may call for a login account on a system to which the user does not haveaccess.

4. Missing group: The role may call for a security group membership which the user does not have.

By incorporating support for approved exceptions, users whose privilege requirements closely resemble butdo not perfectly match a role’s definition can be assigned an existing role, rather than requiring that a newrole be defined to capture the user’s exact requirements. This can significantly reduce the number of rolesneeded to implement RBAC in an organization.

User privilege management with a combination of roles and approved exceptions is illustrated in Figure 7.

Figure 7: Privilege management with a combination of roles and approved exceptions

The enforcement engine must then be enhanced, to remove approved exceptions from the corrections thatare applied to target systems. This is illustrated in Figure 8.

The administration user interface must also change, as it must now be able to manage the set of approvedexceptions as well as user-to-role assignments. This is illustrated in Figure 9.

2.6 Automatic Role Assignment

A useful improvement to the basic role model described in Subsection 2.3 on Page 3 and Subsection 2.4on Page 5 is to replace manual assignment of roles to users with an automated process. In short, if a user’srole can be predicted based on other user attributes – such as the user’s location, department, job title, etc.,then it makes sense to automate role assignment and further simplify security administration.

Automated role assignment normally takes the form of boolean expressions or simple rules. For example,“every user in department D1 and job code J1 should get role R1.” RBAC enforcement using rules toautomatically assign roles to users is illustrated in Figure 10.



Figure 8: Batch enforcement of RBAC privilege model with exceptions.

Figure 9: Security administration using roles and exceptions.



Figure 10: Batch enforcement with automated role assignment.



2.7 Separation of Duties

Another improvement to the role model is to introduce policies regarding separation of duties (SoD). Sepa-ration of duties rules are intended to prevent fraud, by requiring that two different people in an organizationperform work on a transaction to complete it. This reduces the likelihood of fraud by requiring collusion byat least two parties.

An example of separation of duties is a requirement that the same individual cannot simultaneously approvean invoice and issue payment for that invoice.

Separation of duties may be static – i.e., reflected in the type of transactions that a user may perform, ordynamic – i.e., a requirement that distinct individuals perform different tasks relating to the same transaction,but without necessarily limiting which individuals are allowed to perform which tasks.

Continuing with the example above, with static enforcement of separation of duties, one group of workersmay be allowed to approve invoices while another group may be allowed to issue payments. The sameindividual cannot be assigned to both groups.

Alternately, with dynamic enforcement of separation of duties, a single group of workers may be allowedboth to approve invoices and issue payments, but the same individual cannot perform both functions on thesame transaction.

Role-based access control can be used to enforce static separation of duties rules. To do this, rules areintroduced that specify roles or privileges that cannot be simultaneously assigned to the same user. Thesecurity administration user interface must be aware of these rules and prevent assignment of conflictingroles or privileges to the same user. The batch enforcement process can scan for users who have, throughsome out-of-band process, acquired roles or privileges that violate policy. It can then either remove all suchroles or privileges or – taking a less disruptive approach – warn a security officer of the policy violation andwait for a human being to either correct the offending privileges or adjust the policy.

Note that RBAC cannot enforce transactional or dynamic separation of duties rules – that can only be doneby the applications themselves.

Separation of duties rules may also allow for approved exceptions – i.e., specific users are allowed to haveroles or privileges that violate the policy, perhaps for a limited period.

RBAC enforcement using separation of duties rules is illustrated in Figure 11.

2.8 Business Roles, Technical Roles and Role Hierarchy

Roles may be thought of as the intersection between business responsibilities and the technical privilegesneeded to fulfill them. Nevertheless, it may be helpful to think about roles either as primarily businessoriented – i.e., business roles that represent job functions or responsibilities, or as primarily technical – i.e.,collections of privileges that are shared by groups of like users.

One way to combine these approaches is to introduce a role hierarchy. To do this, the definition of a rolefrom Subsection 2.3 on Page 3 is extended to allow roles to include other roles, in addition to discreteprivileges (login accounts and group memberships).

Using a role hierarchy, business roles can be defined by nontechnical workers, to represent job functions.



Figure 11: Batch enforcement with separation of duties.

IT workers can define technical roles, to represent commonly assigned sets of privileges. The two types ofroles are combined using a hierarchy, where business roles incorporate technical rules.

Using a role hierarchy can reduce the work required to construct and maintain the privilege model, sinceone role is often the same as another, plus some extra privileges.

A role hierarchy can also be useful to model an organizational hierarchy. For example, a manager’s rolemay be the same as that of his immediate subordinates, plus some additional “manager only” privileges.Rather than creating a whole new role for the manager from scratch, it can be more convenient to definethe manager’s role as a combination of the roles of his subordinates plus extra privileges that are relevantonly to the manager.

2.9 Summary, RBAC Artifacts

The preceding sections introduced a broad array of concepts that, together, form an RBAC system. Theseconcepts are summarized here:

Role A collection of privileges that may be assigned to one or more users.

Business role A collection of similar users.

Technical role A collection of privileges that are often assigned to users concurrently.

Role hierarchy Role definitions that allow one role to include another.

Variance The difference between a user’s actual privileges on target systems and the privileges that therole model predicts the user should have.

Role enforcement A process that identifies variances and attempts to eliminate them on target systems.



Approved exception A variance that has been approved, such that the role enforcement engine will ignoreit.

Identity attribute Informational data about users, such as their name, location, department, job code, etc.

Automatic role assignment A set of rules, based on users’ identity attributes, used to automatically assignroles to users.

Separation of duties A set of rules defining mutually exclusive roles or resources, typically used to preventfraud.

Enforcement of an RBAC policy that includes separation of duties and automatic role assignment, with anallowance for approved exceptions, is illustrated in Figure 11 on Page 12.



3 Business Reasons for Deploying an RBAC System

Organizations may pursue a role based approach to managing security privileges for a number of reasons,as described in the following sections.

3.1 Simplifying Security Change Requests

Most users are not familiar with the technical details of what security rights are required to perform a givenbusiness function. As a result, when they request security changes – such as creation of a new securityprofile for a new employee or changes to an existing user’s profile to reflect new responsibilities – theytypically make a request with a reference to an existing user with the appropriate privileges.

For example, a manager might request that a new hire be given the same privileges as another, existinguser, because the new hire will perform the same job function as the existing user.

This approach – of cloning an existing user when creating a new user – is undesirable since the existinguser’s profile may have accumulated no-longer-appropriate security privileges over time. By cloning such aprofile, inappropriate privileges which were previously assigned to just one user are now assigned to two,which magnifies the problem.

A preferable approach is to enable those users who make security requests to make those requests interms of a business function, which they do understand. If roles are named after well understood businessfunctions, or if roles are automatically assigned to users based on their documented business function, thenit is easier for users to submit correct security change requests.

3.2 Eliminating Privilege Accumulation

Periodically, users’ security needs change. This happens when users are promoted, transferred, changejob functions, relocate, etc. These business events normally trigger security change requests.

When security administrators receive change requests, they often add new privileges but cannot safely re-move old (unneeded) ones. This is because security administrators do not normally have complete knowl-edge of a user’s job function or requirements, so they cannot tell which of a user’s old privileges are stillrequired and which can be safely removed. This problem is illustrated in Figure 12.

The outcome of this change management process is that users accumulate privileges over time, rarelyrelinquishing them. This can lead to violation of policies such as separation of duties (See Subsection 2.7on Page 11).

By deploying RBAC, it is possible to associate each of the security privileges of a given user with roles.Changes in business responsibilities then map to changes in role assignments, and it is possible to deter-mine which old privileges can be safely removed. This is illustrated in Figure 13.



Figure 12: Without RBAC, changes in user responsibility lead toprivilege accumulation.

Figure 13: With RBAC, it is possible to determine which old privileges can besafely removed.

3.3 Standardizing Security Privileges

When security privileges are manually assigned to users, different users with the same job function maybe inadvertently assigned different privileges. This is the result of human error and of different securityadministrators having a different understanding of requirements at different times.

Organizations wishing to standardize user privileges based on job functions may deploy an RBAC systemin order to define those standards and ensure that users are assigned privileges based on policy, ratherthan the judgment of security administrators.

3.4 Cascading Changes to User Privileges

If user privileges are modeled using roles, then it becomes possible to change a role definition and havethat change apply to all users who have been assigned that role. For example, if users in a given role should



all be granted access to a new application or security group, then it suffices to change the role definitionto include the new privilege and run the enforcement engine. The engine will then detect violations for theusers in question (missing privilege in this example) and make suitable corrections.

3.5 Simplifying Application Migrations

Systems and applications change. Old applications inevitably are either upgraded or replaced. When thishappens, users who had access to an old application have to be granted access to new ones.

When user privileges are managed directly, reprovisioning them is a big job. When RBAC is used, migra-tions can be as simple as changing the role definitions that apply to users of the old application to includeaccess rights on the new application. Once this is done, the enforcement engine will cascade the secu-rity changes from the role to the users, automatically granting all the appropriate users access to the newapplication. This reduces the effort required to migrate users from an old to a new application.

3.6 Coarse-Grained Separation of Duties

While separation of duties rules may be applied directly to fine-grained privileges, some organizations preferto articulate rules in the form “users assigned role R1 may not also be assigned role R2.” For this to work,roles must be defined and users assigned roles – i.e., security management using RBAC.



4 RBAC Deployment Process

RBAC is normally implemented by an organization to supplement or replace a pre-existing process for man-aging users and privileges. Consequently, a process is required to migrate from fine-grained administrationto RBAC.

4.1 Role Modeling and Mining

The first step in implementing an RBAC system is to define roles (i.e., named collections of privileges) andto assign roles to users. This creates a model predicting the privileges that each user should have.

The process of developing a set of roles and assigning them to users is called role modeling. Rolemodeling may be carried out by analyzing existing user privileges – i.e., by looking for sets of users andprivileges that already exhibit role-like connections. Analysis of existing user privileges as a means todefining and assigning roles is called role mining.

4.1.1 Top-Down (Roles from Business Function)

One approach to role modeling is to use a set of identity attributes to identify users whose security privilegesought to be similar. The identity attributes may be things like department code, location code, job code, etc.Users whose identity attributes have the same value (i.e., same department, same location, same job code,etc.) are expected to have the same privileges and therefore the same role.

In top-down analysis, first every meaningful combination of the key identity attributes is identified. For everysuch combination, appropriate privileges are defined. Actual user privileges are then corrected so that theymatch the role model.

This approach can yield not only a role definition but also a rule for automatically assigning the role to users,as described in Subsection 2.6 on Page 8.

The main weakness of this approach is that while business users (typically managers) can articulate that agiven set of users perform the same job function and therefore should have the same role, they normally donot know what security privileges those users need.

A second problem with this approach is that mistakes can easily be made when defining a role “fromscratch.” When the RBAC engine applies a mis-configured role to users, privileges that the users need fortheir jobs will be (mistakenly) removed and work will be interrupted until the role definition is corrected.

4.1.2 Bottom-Up (Roles from Technical Analysis)

Another approach to role modeling is to look for clusters of users who have identical, or at least very similarprivileges. These clusters represent candidate roles:

1. The privileges shared by the users in question constitute a role definition.



2. The users in the cluster assigned the new role.

If the users have the same identity attributes, then a rule can also be drafted to automatically apply the newrole to similar users in the future.

Weaknesses of this approach include:

1. Users who ought to have identical privileges often do not, because of privilege accumulation, incon-sistent security administration, etc. A technical analysis will fail to identify such users as candidatesfor a new role.

2. It is possible for users who actually have different business responsibilities to have very similar priv-ileges. In this case, a bottom-up analysis might mistakenly identify them as candidates for a sharedrole.

3. A technical analysis identifies users who have similar privileges, but cannot distinguish between privi-leges that users happen to have from those that they actually need. As a result, it can yield roles thatcontain more privileges than actually required.

4.1.3 Mixed Analysis

The problems with a purely bottom-up and a purely top-down approach are due to data quality (up to 30%of privileges assigned to users may be inappropriate) and to a disconnect between a technical analysis (ofprivileges) and a business analysis (of users who do the same job).

A third approach is therefore to try to combine the business and technical analysis. For example, managersmight identify users who report to them and are expected to perform the same business function. Oncesuch clusters of like users have been identified, a technical role analyst can compare the privileges of usersin the cluster. Privileges that they have in common may form the basis of a role, while privileges that differmay be inappropriate (should be corrected) or required (should be approved as exceptions).

This approach is generally more practical than either a purely top-down or a purely bottom-up approach:

1. It leverages the knowledge of both business users and technicians.

2. It can yield corrections to current privileges, in addition to role definitions and user-to-role classifica-tion.

3. It can yield approved exceptions, where current user privileges are correct but are not preciselymapped out by a coarse grained role model.

4. It at least has the potential to identify privileges that, while shared by a group of like users prior todeployment, are not actually needed by those users.

4.2 Phased Deployment

It can months or even years to complete a role modeling project, yielding role definitions, user-to-roleassignment, rules to auto-assign roles and approved exceptions for every user in a large organization. Such



a lengthy deployment process, combined with constant change in organizations, means that the model maynever be 100% complete.

This means that it makes sense to start applying the role model to users – i.e., to start enforcement – beforethe role model is complete. To do this, a mechanism is required to limit the scope of enforcement to coverjust those users and resources that have been fully analyzed. Without such a mechanism, the enforcementengine would incorrectly conclude that users who have not yet been analyzed should have no privileges,and deprovision them.

A simple approach to phased deployment is to set a flag on each user, which indicates whether or not theuser should be impacted by the RBAC enforcement engine. The flag should be set for every user that haspassed through the role modeling process.



5 RBAC Ongoing Maintenance

Once an RBAC system has been deployed, it requires ongoing maintenance. Without this, over time,business rules, role definitions, user to role assignments and more will become obsolete and the systemwill enforce the wrong rules, for the wrong users, at the wrong time. If that happens, the RBAC system willno longer bring benefit to the organization, but rather create problems for security administrators.

The following sections highlight some of the ongoing maintenance tasks required.

5.1 Change Authorization Workflow

Required changes to user privileges identified by the RBAC enforcement engine may have to be approvedbefore they are applied to actual user profiles on target systems. Changes may include:

1. Creating a new login ID for a user.

2. Attaching a user to a security group.

3. Disabling or deleting an existing login ID.

4. Removing a user from a group.

5. Approving exceptions to the model:

(a) Extra login IDs.

(b) Extra group memberships.

(c) Missing login IDs.

(d) Missing group memberships.

Such changes must be subjected to authorization business logic:

1. Authorization required?

Is approval by business users required before the change will take effect?

2. Selecting authorizers (request routing):

If approval is required, by whom?

3. Consensus:

If multiple authorizers are identified, how many of them are sufficient to approve a given changerequest? (e.g., 2 of 5).

4. Veto:

If an authorizer rejects a request, does that block it entirely, or does it only block those resources forwhich that authorizer is responsible?



5. Reminder timing:

If authorizers fail to respond, how often should they be reminded?

6. Escalation path:

If authorizers fail to respond for an extended period of time, what alternate authorizers should beselected to act in their place?

Over time, the business rules regarding authorization will change. It is the responsibility of the RBAC systemadministrator to ensure that these rules continue to reflect business needs.

5.2 Periodic Certification

It makes sense to periodically review both user security rights and the role model itself, to ensure that bothare configured in a manner that is appropriate to current business needs. Such periodic reviews are calledcertifications and may be carried out as follows:

5.2.1 User Privileges

This is a certification of the specific privileges – i.e., login accounts and membership in security groups –assigned to individual users. This type of certification does not require an role model and may be carriedout prior to development of the role model.

Running a detailed review and cleanup of user privileges prior to role modeling reduces the number ofinappropriate privileges held by users and consequently makes bottom-up role modeling easier, since userswho ought to have the same privileges are more likely to actually have the same privileges after the cleanup.

User privilege certification may be carried out by managers (i.e., reviewing their direct reports), by applica-tion owners (i.e., of users who have login IDs on their applications) or by group owners (i.e., of membershipin their groups).

5.2.2 Role Assignments and Approved Exceptions

Individual users typically have many fine-grained entitlements, but only one or two assigned roles and fewif any approved exceptions. It can be easier for managers to certify users’ role assignments plus approvedexceptions than privileges.

5.2.3 Role Definitions

In addition to reviewing and either certifying or correcting user assignment to roles and approved excep-tions, it makes sense to also periodically review the definitions of the roles themselves – i.e., are they stillappropriate?

This sort of review should be carried out by role owners, who may be managers in the case of organizationalroles or technical staff (such as application administrators) in the case of technical roles.



5.3 Managing Role Changes

One of the reasons for deploying an RBAC system is to have security privileges assigned to users morequickly and reliably reflect changes in the business responsibilities of users. Technically, this means man-aging changes in user-role assignment.

When a user changes roles, some of his old privileges should be removed, others should be retained andnew privileges should be added. This is illustrated in Figure 13.

One problem that may arise during role changes is determining precisely when to remove old privileges,that appear in the old role but not the new one. This is a problem because when users change jobs, theyoften continue to perform their old job in some backup capacity, for some time.

Three ways to handle this are:

1. Remove the old privileges immediately, essentially preventing reassigned users from assisting theirreplacements.

2. Keep the old role for some time, and remove it when it is really no longer required.

The problem with this approach is that end users do not volunteer to remove old privileges, so maynever ask to remove the old role. Certification, as described in Subsubsection 5.2.2 on Page 21 maybe the main solution to this problem.

3. Remove the old role immediately but defer removal of privileges associated with that role. For ex-ample, the enforcement engine could detect that a user no longer requires a privilege, but insteadof removing it immediately, could submit a security change request to the authorization workflow toremove the privilege at a later date (e.g., in 30 days).

5.4 Adding Applications

Applications may be added to the role model either because of a phased deployment (i.e., the applicationwas in use prior to the RBAC system but integration was deferred) or because they are new.

In either case, an important part of the ongoing maintenance of any RBAC system is a process to addapplications. When this is done:

1. New roles may be defined, relating purely to the new application.

2. Existing roles may be extended, to include access to the application.

3. Existing roles may be split into two or more more new roles, since users in the old role may have thesame privilege requirements everywhere except on the new application.

The last point above is especially problematic, since it can cause an explosion in the number of roles asnew applications are added.



5.5 Retiring Applications

When applications that were already part of the RBAC system are retired, they must be promptly removedfrom the model. Otherwise, the enforcement engine will continually raise exceptions about users not havinglogins on the (now gone) application.

Retiring applications can lead to role consolidation, where roles that previously differed only in terms ofprivileges within the retired application become identical.

5.6 System Migrations

Applications are often migrated from one version or product to another. Migrations impact the role modelin exactly the same way as (a) removing an old application and (b) adding a new application. In otherwords, they can be implemented by changing role definitions and allowing the RBAC engine to cascade thechanges to user profiles.



6 Organizational Impact

Using a role-based access control strategy to manage the security privileges of users has wide-rangingimpact on how an organization functions:

6.1 New Function: Role Analysts

The most obvious impact, evident when an RBAC project begins, is that a new business function is required– that of role analysts.

Some organizations attempt to delegate the tasks of developing role definitions, of assigning roles to usersand of approving exceptional privileges to managers or IT staff. In practice, such delegation is often unsat-isfactory:

1. Managers do not understand the technical requirements of their subordinates. While they can identifywhich of their subordinates perform the same job function, they normally cannot say what securityprivileges those employees and contractors require.

2. IT staff, such as system administrators and application owners, are often able to match security priv-ileges, such as login accounts and membership in security groups, to functional capabilities in eachapplication, but they cannot say with confidence which users in the business organization should haveaccess to those functions or data.

The role analyst’s function is therefore to bridge the gap between business-savvy but technically-ignorantmanagers and technically-savvy but business-ignorant IT staff.

Hiring and retaining role analysts can be expensive and this is one of the fundamental costs of an RBACdeployment. As a very rough measure, one might estimate that an average role will have ten members andwill require an hour of a role analyst’s time to develop plus 30 minutes per year to review and correct.

Using these metrics, we can estimate that in an organization with 20,000 users:

1. There will be about 2,000 fine-grained roles.

2. About 2,000 hours, or about one person-year, will be required to develop the roles.

3. About 1,000 hours/year, or about 1/2 of an FTE, will be required to maintain the role model after it isfully deployed.

4. Since most organizations evolve rapidly, it may make sense to hire 3 or 4 role analysts for a fewmonths, and retain one in a permanent capacity.

It should be noted that the above figures are intended only to give a sense of the order of magnitude of therole modeling task, rather than to predict the exact effort required in any single organization.



6.2 Managers

When an RBAC system is first deployed, each manager is likely to be contacted to assist in the developmentof the role model:

1. In some organizations, there is no complete or reliable data connecting users to their direct managers.Managers may therefore be asked to review and correct org-chart data before any other analysis canproceed.

2. At a minimum, managers should indicate which of their direct subordinates share the same job func-tion (and so should be assigned a single role).

3. A role analyst will typically point out various discrepancies, where users who supposedly perform thesame job function actually have different security rights. In each case, the manager will have to:

(a) Indicate that the variance is likely an error, and should be corrected; or

(b) Indicate that the user, in reality, does not perform the same job function as his previously identifiedpeers, and should be assigned a different role; or

(c) Indicate that the user does perform largely the same function as his previously identified peers,but does have a minor difference in responsibilities, which should be approved as an exception;or

(d) Indicate that the variance is inconsequential, and should be approved not only for this user, butfor any other user in the same nominal job function.

Once the RBAC system has been deployed, managers will have to use it:

1. When requesting access for new employees or contractors, they will have to choose a role. In mostorganizations this is different from previous methods, such as instructing the help desk to create anew user profile “just like” an existing user.

2. When requesting that an employee or contractor be transferred from one job function to another,managers should specify whether and for how long the user’s old roles should be retained, which newroles to assign and when to assign them.

3. Periodically, managers should be asked to review user privileges, which will be expressed in termsof role assignments and approved exceptions, rather than in terms of fine-grained security privilegesassigned to each user.

4. Some managers may be designated “role owners” and should periodically be asked to review the setof privileges assigned to each role for which they are responsible and the list of users who have beenassigned that role.

6.3 Security Administrators

Once an RBAC system has been implemented, security administrators will be asked to stop managing userprivileges directly and instead assign roles to users. This means an end to routine use of native securityadministration tools and learning to use the RBAC system’s console instead.



6.4 End Users

During the RBAC system’s deployment process, user privileges will be corrected in order to bring them intocompliance with the role model. Inevitably, mistakes will be made, which means that users will be assignedexcessive or inadequate privileges:

1. If users are assigned excessive privileges, they will likely not notice. Note: this is a security problem,rather than a usability problem for users.

2. If needed user privileges are mistakenly removed, users will be unable to use applications to performtheir job functions. These users will lose productivity and will call the help desk for assistance.

6.5 The Help Desk

The help desk organization must be aware of the RBAC deployment project, since users will inevitably losesome required privileges and will call for assistance:

1. It is helpful for role analysts to notify the help desk of which users have been added to the role model,when they were added and what security rights were added to or removed from each user.

2. Help desk analysts must be trained to identify problems that may have resulted from inappropriatechanges to user privileges.

3. Help desk analysts should know how to check whether a given help desk caller had recently beenimpacted by the RBAC deployment and - if so - what changes were made.

4. Help desk analysts must be able to escalate security problems to the role analyst, who must be ableto correct such problems.

6.6 IT Auditors

Auditors benefit from an RBAC system because they can review what security privileges a group of usersis supposed to have, in addition to what they were previously able to do – namely to review what securityprivileges individual users do have.

While not strictly a part of the RBAC system, a feature that often accompanies RBAC is enforcement ofseparation of duties policies, as described in Subsection 2.7 on Page 11. With this features, auditors areable to review SoD rules as well as role definitions and role assignments.



APPENDICES



A About Hitachi ID Systems

This white paper was written and published by Hitachi ID Systems – an identity management softwarevendor.

Hitachi ID Systems publishes a range of identity management software, including Hitachi ID Identity Manager:a user provisioning program capable of implementing role based access control spanning multiple IT sys-tems.

To learn more about Hitachi ID Systems, please visit http://Hitachi-ID.com/

To learn more about Identity Manager, please visit http://Hitachi-ID.com/Identity-Manager/



http://Hitachi-ID.com/Identity-Manager/


www.Hitachi-ID.com

500, 1401 - 1 Street SE, Calgary AB Canada T2G 2J3 Tel: 1.403.233.0740 Fax: 1.403.233.0725 E-Mail: [email protected]

File: /pub/wp/documents/rbac-overview/rbac-overview-3.texDate: 2007-11-24


role based access control - overview

Technology