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.

Contents
1 Introduction 1
2 What is Role Based Access Control? 2
2.1 Deﬁnitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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 Workﬂow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
i

RBAC: What, Why and How?
5.2 Periodic Certiﬁcation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
5.2.1 User Privileges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
5.2.2 Role Assignments and Approved Exceptions . . . . . . . . . . . . . . . . . . . . . 21
5.2.3 Role Deﬁnitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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 large
numbers of users and multiple IT systems. It is organized into ﬁve distinct parts:
1. Development of RBAC concepts from a simple model to a complex but realistic privilege management
infrastructure.
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, to
eliminate 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 efficient
than assigning privileges to individual users.
Group membership Another type of privilege – a record that indicates that a user belongs to a security
group, 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, an
Active 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 and
applied.
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 the
National 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 RBAC
work.

2.3 Introducing Roles
To understand RBAC, one ﬁrst 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 accessed
by an average of 20 users:
1. Security administrators must manage about 200,000 individual privileges (10,000 resources x 20
users).
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 members
of 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 – about
20.
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 be
replaced by 2,000 privileges plus 10,000 user-to-group associations. This reduced complexity is the main
motivation for RBAC.
These concepts are illustrated in the following ﬁgures.
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 in
Figure 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 simpliﬁed by using roles, so long as many users have identical
requirements. 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 their
runtime security enforcement decisions (i.e., “is user X allowed to access resource Y?”). As a result, RBAC
is 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 single
application.
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’s
assigned 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 automated
nightly process that brings users into compliance with the role model.
2. Change control / security administration: the security management user interface is changed so
that 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 each
target system.
2. User assignment to roles is combined with role definitions to predict the privileges that each user
should have.
3. Actual user privileges, as discovered on target systems in the first step, are compared to predicted
privileges.
4. Any differences between actual and predicted user privileges are applied back to target systems, to
remove 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 to
replace 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-ﬂow 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 target
systems).
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 quite
difﬁcult 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 in
Subsection 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 other
words, as the number of roles approaches the number of users, RBAC reverts to direct user management
and provides no beneﬁt.
To address this issue, practical RBAC systems should incorporate a concept of approved exceptions. This
allows users to have privileges that diverge from what their role assignment predicts and for the organization
to 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 have
access.
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 but
do not perfectly match a role’s definition can be assigned an existing role, rather than requiring that a new
role be defined to capture the user’s exact requirements. This can significantly reduce the number of roles
needed 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 that
are 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 approved
exceptions 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.4
on Page 5 is to replace manual assignment of roles to users with an automated process. In short, if a user’s
role 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 to
automatically 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 organization
perform work on a transaction to complete it. This reduces the likelihood of fraud by requiring collusion by
at least two parties.
An example of separation of duties is a requirement that the same individual cannot simultaneously approve
an 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, or
dynamic – 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 workers
may be allowed to approve invoices while another group may be allowed to issue payments. The same
individual cannot be assigned to both groups.
Alternately, with dynamic enforcement of separation of duties, a single group of workers may be allowed
both to approve invoices and issue payments, but the same individual cannot perform both functions on the
same transaction.
Role-based access control can be used to enforce static separation of duties rules. To do this, rules are
introduced that specify roles or privileges that cannot be simultaneously assigned to the same user. The
security administration user interface must be aware of these rules and prevent assignment of conflicting
roles or privileges to the same user. The batch enforcement process can scan for users who have, through
some out-of-band process, acquired roles or privileges that violate policy. It can then either remove all such
roles or privileges or – taking a less disruptive approach – warn a security officer of the policy violation and
wait 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 done
by the applications themselves.
Separation of duties rules may also allow for approved exceptions – i.e., specific users are allowed to have
roles 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 privileges
needed to fulfill them. Nevertheless, it may be helpful to think about roles either as primarily business
oriented – 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 role
from Subsection 2.3 on Page 3 is extended to allow roles to include other roles, in addition to discrete
privileges (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 of
roles 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, since
one 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 role
may 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 define
the manager’s role as a combination of the roles of his subordinates plus extra privileges that are relevant
only to the manager.
2.9 Summary, RBAC Artifacts
The preceding sections introduced a broad array of concepts that, together, form an RBAC system. These
concepts 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 the
role 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 ignore
it.
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 assign
roles to users.
Separation of duties A set of rules deﬁning mutually exclusive roles or resources, typically used to prevent
fraud.
Enforcement of an RBAC policy that includes separation of duties and automatic role assignment, with an
allowance 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 given
business function. As a result, when they request security changes – such as creation of a new security
profile for a new employee or changes to an existing user’s profile to reflect new responsibilities – they
typically 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, existing
user, 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 existing
user’s profile may have accumulated no-longer-appropriate security privileges over time. By cloning such a
profile, 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 in
terms of a business function, which they do understand. If roles are named after well understood business
functions, or if roles are automatically assigned to users based on their documented business function, then
it 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, change
job 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 still
required 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, rarely
relinquishing them. This can lead to violation of policies such as separation of duties (See Subsection 2.7
on 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 may
be inadvertently assigned different privileges. This is the result of human error and of different security
administrators having a different understanding of requirements at different times.
Organizations wishing to standardize user privileges based on job functions may deploy an RBAC system
in order to deﬁne those standards and ensure that users are assigned privileges based on policy, rather
than 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 deﬁnition and have
that 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 definition
to include the new privilege and run the enforcement engine. The engine will then detect violations for the
users 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 this
happens, 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 include
access 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 new
application. 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 prefer
to 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 administration
to 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) and
to 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. Role
modeling may be carried out by analyzing existing user privileges – i.e., by looking for sets of users and
privileges that already exhibit role-like connections. Analysis of existing user privileges as a means to
defining 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 privileges
ought 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 every
such combination, appropriate privileges are defined. Actual user privileges are then corrected so that they
match 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 a
given set of users perform the same job function and therefore should have the same role, they normally do
not know what security privileges those users need.
A second problem with this approach is that mistakes can easily be made when defining a role “from
scratch.” When the RBAC engine applies a mis-configured role to users, privileges that the users need for
their 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 similar
privileges. 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 new
role 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 candidates
for 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 shared
role.
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 that
contain 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 (of
privileges) 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, managers
might identify users who report to them and are expected to perform the same business function. Once
such clusters of like users have been identified, a technical role analyst can compare the privileges of users
in the cluster. Privileges that they have in common may form the basis of a role, while privileges that differ
may 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 precisely
mapped 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 to
deployment, 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-role
assignment, 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 may
never be 100% complete.
This means that it makes sense to start applying the role model to users – i.e., to start enforcement – before
the role model is complete. To do this, a mechanism is required to limit the scope of enforcement to cover
just those users and resources that have been fully analyzed. Without such a mechanism, the enforcement
engine 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 ﬂag on each user, which indicates whether or not the
user should be impacted by the RBAC enforcement engine. The ﬂag should be set for every user that has
passed 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 system
will enforce the wrong rules, for the wrong users, at the wrong time. If that happens, the RBAC system will
no 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 approved
before 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 change
request? (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 for
which 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 be
selected to act in their place?
Over time, the business rules regarding authorization will change. It is the responsibility of the RBAC system
administrator 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 both
are configured in a manner that is appropriate to current business needs. Such periodic reviews are called
certifications 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 carried
out prior to development of the role model.
Running a detailed review and cleanup of user privileges prior to role modeling reduces the number of
inappropriate privileges held by users and consequently makes bottom-up role modeling easier, since users
who 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 membership
in 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 few
if any approved exceptions. It can be easier for managers to certify users’ role assignments plus approved
exceptions 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 still
appropriate?
This sort of review should be carried out by role owners, who may be managers in the case of organizational
roles 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 more
quickly 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 and
new 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, they
often 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 their
replacements.
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 may
never ask to remove the old role. Certification, as described in Subsubsection 5.2.2 on Page 21 may
be 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 instead
of removing it immediately, could submit a security change request to the authorization workflow to
remove 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 application
was 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 add
applications. 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 the
same 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 as
new applications are added.

5.5 Retiring Applications
When applications that were already part of the RBAC system are retired, they must be promptly removed
from the model. Otherwise, the enforcement engine will continually raise exceptions about users not having
logins on the (now gone) application.
Retiring applications can lead to role consolidation, where roles that previously differed only in terms of
privileges 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 model
in exactly the same way as (a) removing an old application and (b) adding a new application. In other
words, they can be implemented by changing role deﬁnitions and allowing the RBAC engine to cascade the
changes to user proﬁles.

6 Organizational Impact
Using a role-based access control strategy to manage the security privileges of users has wide-ranging
impact 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 users
and 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 identify
which of their subordinates perform the same job function, they normally cannot say what security
privileges 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 each
application, but they cannot say with confidence which users in the business organization should have
access to those functions or data.
The role analyst’s function is therefore to bridge the gap between business-savvy but technically-ignorant
managers 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 RBAC
deployment. As a very rough measure, one might estimate that an average role will have ten members and
will 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 is
fully deployed.
4. Since most organizations evolve rapidly, it may make sense to hire 3 or 4 role analysts for a few
months, 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 the
role 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 development
of 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 can
proceed.
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 the
same 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 identified
peers, 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, but
for 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 most
organizations this is different from previous methods, such as instructing the help desk to create a
new 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 new
roles to assign and when to assign them.
3. Periodically, managers should be asked to review user privileges, which will be expressed in terms
of role assignments and approved exceptions, rather than in terms of fine-grained security privileges
assigned to each user.
4. Some managers may be designated “role owners” and should periodically be asked to review the set
of privileges assigned to each role for which they are responsible and the list of users who have been
assigned that role.
6.3 Security Administrators
Once an RBAC system has been implemented, security administrators will be asked to stop managing user
privileges directly and instead assign roles to users. This means an end to routine use of native security
administration 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 into
compliance with the role model. Inevitably, mistakes will be made, which means that users will be assigned
excessive 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 perform
their 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 lose
some 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 inappropriate
changes to user privileges.
3. Help desk analysts should know how to check whether a given help desk caller had recently been
impacted 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 able
to correct such problems.
6.6 IT Auditors
Auditors beneﬁt from an RBAC system because they can review what security privileges a group of users
is supposed to have, in addition to what they were previously able to do – namely to review what security
privileges individual users do have.
While not strictly a part of the RBAC system, a feature that often accompanies RBAC is enforcement of
separation of duties policies, as described in Subsection 2.7 on Page 11. With this features, auditors are
able to review SoD rules as well as role deﬁnitions and role assignments.

APPENDICES

A About Hitachi ID Systems
This white paper was written and published by Hitachi ID Systems – an identity management software
vendor.
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/

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: sales@Hitachi-ID.com
File: /pub/wp/documents/rbac-overview/rbac-overview-3.tex
Date: 2007-11-24

Role Based Access Control - Overview

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (14)

Similar to Role Based Access Control - Overview

Similar to Role Based Access Control - Overview (20)

More from Hitachi ID Systems, Inc.

More from Hitachi ID Systems, Inc. (20)

Recently uploaded

Recently uploaded (20)

Role Based Access Control - Overview