swipe to navigate

Relationship between IAM and RBAC

identity and access management (IAM) systems automate business processes to grant access to new users, revoke access when people leave an organization, manage access requests and approvals, automate access changes to reflect changing business needs, enforce policies regarding user access and more.

Some people assume that, before an IAM system can be deployed:

  1. Inappropriate entitlements must be cleaned up.
  2. Roles must be defined, to automatically assign appropriate access rights to users.

These pre-conditions to IAM deployment are a myth. Every organization, no matter how bad their access rights data, has at least manual processes to grant and revoke access and those processes work at some level. While cleaning up entitlement data is a worthwhile goal, it is in no way a pre-requisite to automating IAM processes.

On the other hand, once an IAM system is deployed, a variety of processes, including analytics, org-chart construction, data cleansing and more can be brought to bear to support the definition of roles and the automatic assignment of roles to users.

In other words, IAM does not depend on role-based access control (RBAC) and RBAC does not strictly require IAM, but RBAC is much easier to deploy once an IAM system is in place.

Role-based access control (RBAC) concepts


It is appropriate to start any discussion of role-based access control (RBAC) with some definitions, to eliminate ambiguity. The following terms will be used throughout this document:

  • User: The electronic representation of a human being or a non-human persona.

  • Profile: Alternate term for user.

  • Application: Software that one or more users wish to sign into.

  • System: The running platform on which an application runs. Typically a physical or virtualized server, running an operating system such as Windows, Linux, another Unix variant, iSeries or z/OS.

  • Resource: A general term for something users might wish to access. Typically an application or data set.

  • Directory: A type of application that aggregates data about users and resources and allows multiple systems and applications to share this data, rather than each maintaining their own version.

  • Entitlement: A security privilege granted to a user, to enable access to a resource. Entitlements may be stored on the resource itself or on a directory.

  • Access administrator: A person responsible for managing user records and assigning or revoking entitlements.

  • Account: One type of entitlement -- a record on a system, application or directory that represents a user within that scope and allows the user to sign into one or more systems or applications. Examples include login accounts on SAP, z/OS, Active Directory, other LDAP directories, Salesforce.com, etc.

  • Security group: An object on a system, application or directory used to collect multiple accounts into a set, often so that security privileges can be assigned to all the included users simultaneously.

  • Group membership: Another type of entitlement -- a record indicating that a given account is a member of a given security group.

  • Credential: A mechanism used by a user to sign into an account. Examples include passwords, security question/answer pairs, one time password systems, smart cards, PKI certificates and biometrics.

  • Identity and access management (IAM) system: A system used to manage identities, entitlements and credentials across multiple target systems, while automating standard business processes and enforcing security policies.

  • Target system: A system, directory or application where accounts, entitlements or credentials are managed by an IAM system.

  • Access request: An object in an IAM system representing a request by a user or an automated process to grant one or more entitlements to one or more users.

  • Requester: In the context of an access request, the identity of the user who filled in the request. May represent a human user or an automated process.

  • Recipient: In the context of an access request, the identity of the user who will be assigned new entitlements or whose existing entitlements may be revoked when the request is completed.

  • Authorizer: In the context of an access request, the identity of a user who must approve the request before it is completed.

  • Role: A named collection of entitlements, possibly spanning multiple target systems.

  • User class: A named collection of users, preferably identified through a rule rather than being individually named.

  • Role-based access control (RBAC): A strategy for managing entitlements via roles, rather than by assigning them directly to users.

  • RBAC policy engine: A process that compares the entitlements that users actually have on target systems to the entitlements that their assigned roles indicate they should have and automatically creates access requests to remediate any discrepancies.

  • Segregation of duties (SoD) rule: A named set of entitlements, optionally including roles, which should not be simultaneously assigned to a single user.

  • SoD preventive controls: The application of SoD rules to access requests, to block requests that would result in a user violating an SoD rule.

  • SoD detective controls: The application of SoD rules to existing entitlements, to identify already-present violations.

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:


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

Clarifying terminology: roles, groups and user classes

Different participants in the IAM marketplace -- analyst firms, software vendors, consultants -- use the same terms to mean different things. Here we clarify how terms such as roles, groups and user classes will used in this document.

Roles versus groups

It is important to differentiate between two concepts: roles and groups. Hitachi ID Systems uses these terms as follows:

  1. Groups are objects on target systems to which users are attached and which are assigned application-specific access rights.
  2. Roles are objects that exist strictly within an IAM system. They are named collections of accounts, groups and other roles (i.e., they can be nested).
  3. Users are representations of people on the IAM system and may be linked to multiple accounts on multiple target systems.

Groups are assigned to accounts while roles are assigned to users. Groups can be assigned directly to accounts or indirectly, when a user is assigned a role that includes a group. Roles can be assigned directly to users or indirectly, when a parent role is assigned to a user.

Confusingly, within some systems and applications, groups are referred to as roles or by other names, such as privileges. For consistency, all such constructs, which exist on target systems and are assigned to accounts on those systems will be referred to as groups here.

Roles versus user classes

Many participants in the IAM industry refer to two distinct concepts -- organization structure and collections of entitlements -- using the same term: role. Using one label for two concepts can lead to confusion and bad designs, which in turn can lead to implementation risk, needless cost and missed deadlines.

To avoid these problems, it is important to define clear terminology, as follows:

  • A security group is an object that exists on a managed system or directory, to which security rights have been assigned. Accounts can be made members of security groups, which is the primary mechanism of assigning security rights to users. For example, Active Directory has security groups, SAP has roles (formerly called activity groups), RAC/F has group profiles, etc. The general term for all of these and their equivalents on other systems is simply 'security group' or 'group' for short.

    On some systems, such as Active Directory and RAC/F, groups can be nested -- i.e., a group can include other groups among its members.

  • Entitlements are security rights that are normally assigned to users. On almost all systems, entitlements are either login accounts (e.g., AD account, RAC/F login, SAP user, etc.) or security group memberships assigned to accounts that are, in turn, associated with the user. While users can be assigned other rights directly, such as to files and folders, this is almost never a good idea, as it is very difficult to manage.

  • Roles are named collections of entitlements. They may contain login accounts, security groups or other roles.

    The ability of a role to contain other roles means that a role hierarchy can be defined. Another term for this is nested roles.

Note that none of the above makes any mention of an organizational structure. The terms above all relate to entitlements, either as they exist on target systems or to how they are represented in an IAM system.

There are separate terms relating to organizational structure and the relationships between people:

  • A user class is a set of users that have something in common. Users might be added to a user class individually, but more commonly users are implicitly members of a user class, by virtue of a rule which specifies their department, location, business unit, etc.

  • An organizational hierarchy is a linkage between users or containers. For example, users may be linked to their direct managers, creating a hierarchy of people. Departments may be connected to other departments, creating a hierarchy of people-containers.

Clear terminology supports clear definitions of processes, such as the following:

  • Roles or group memberships can be automatically assigned to members of user classes.
  • Members of a user class may be invited to approve the assignment of entitlements.
  • Managers may be invited to review the entitlements of their subordinates.

Managing entitlements directly and using roles

To understand RBAC, one first has to understand the administrative burden of managing entitlements at scale.

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

  1. Access administrators must manage about 500,000 individual entitlements (10,000 resources x 50 users).
  2. An average user has about 25 entitlements (500,000 entitlements / 20,000 users).

Continuing with this example, if users can be collected into sets of about 100 users each, where members of each set have identical access requirements, then:

  1. There will be about 100 set similar users (10,000 users / 100 users/set).
  2. Each set of users will have the same number of entitlements as any of its member users previously had -- about 25.
  3. In total, 2,500 individual entitlements will have to be managed (100 groups x 25 entitlements/set).
  4. In addition, each user will have to be associated with a set -- about 20,000 associations.

In other words, if entitlements are highly regular, as in our example, then 500,000 entitlements can be replaced by 2,500 entitlements plus 20,000 user-to-set associations. This reduced complexity is an important motivation for RBAC -- less things to manage.

These concepts are illustrated in the following figures.

  1. Managing a single user's entitlements is illustrated in Figure [link].

    A single user with entitlements to multiple resources

    A single user with entitlements to multiple resources

  2. The same model, when scaled up to many users, creates administrative problems, as illustrated in Figure [link].

    Managing Entitlements directly for many users

    Managing Entitlements directly for many users

  3. When roles are introduced, managing entitlements for a single user is slightly more complex than managing entitlements directly. This is illustrated in Figure [link].

    Using a role to abstract a single user's entitlements

    Using a role to abstract a single user's entitlements

  4. When many users need the same entitlements, managing them via roles simplifies the process, as illustrated in Figure [link].

    Reducing administrative burden for similar users with roles

    Reducing administrative burden for similar users with roles

Applying RBAC to existing applications

RBAC is not built into every application. Moreover, few off-the-shelf applications are able to refer to an external policy decision point to resolve security enforcement decisions at runtime (i.e., "is user X allowed to access resource Y?"). As a result, RBAC is typically layered on top of the existing security mechanism that is built into each system and application. This can be done both at access request time and periodically:

Roles in access requests

  1. Formulate access requests in terms of roles, rather than or in addition to individual entitlements.
  2. e.g., assign role R1 to user U1.
  3. e.g., remove role R2 from user U2.

This is illustrated in Figure [link].

Access administration using roles

Access administration using roles

In the Figure:

  1. Business users and access administrators request and approve changes to assigned roles. For example:
    1. Create new user X using role R.
    2. Delete user X (i.e., remove all roles from user X).
    3. Remove role R1 from user X and add R2.
  2. The RBAC policy engine maps role changes to entitlement changes (create/delete login IDs, attach users to/remove users from security groups).
  3. Connectors apply these changes to target systems.

Periodic RBAC enforcement

  1. Using roles which had been previously assigned to users, predict which entitlements each user should have.
  2. List of accounts and groups on each target system.
  3. Calculate the difference between the predicted and current entitlements.
  4. Automatically generate access requests to remediate the discrepancy between actual and predicted entitlements.

Periodic enforcement is illustrated in greater detail in Figure [link].

Simple batch enforcement of RBAC entitlement model

Simple batch enforcement of RBAC entitlement model

In the Figure:

  1. An automated process runs connectors to list accounts and groups on each target system.

  2. User assignment to roles is combined with role definitions to predict the entitlements per user.

  3. Actual entitlements are compared to predicted entitlements.

  4. Access requests are created to resolve discrepancies between actual and predicted entitlements.

Approved exceptions

A purely role-based model can be quite difficult to manage in practice. Some users have unique access needs, so would need their very own roles. As the number of roles grows to approach the number of users, the cost of developing and maintaining roles becomes prohibitive.

As the number of roles approaches the number of users, RBAC degenerates back to direct user management, but with an extra layer of indirection between roles and users. Such an RBAC system would provide no benefit.

Roles only make economic sense when they are shared by many users. How many is "many?" There is no concrete number -- it depends on the cost of developing and maintaining roles in a given organization and the frequency of access requests that refer to each role. A good starting point is to consider roles only when twenty or more people need the same access.

Users whose access needs cannot be completely met with roles also need direct-assigned entitlements. Support for both direct-assigned and role based entitlements means that fewer roles can be defined, and assigned to more users per role. This improves the cost effectiveness of RBAC.

For this to work, the RBAC policy engine (shown in Figure (Screenshot:rbac-batch-enforcement-simple-2)) needs an indication that a given entitlement is acceptable and should not be "corrected" just because it is not predicted by the user's assigned roles.

A user's entitlements may vary from what the user's assigned roles predict: they may be "surplus" -- meaning the entitlement is more than what the role predicts, or "deficit" -- meaning that the user's roles predict that a user should have a given entitlement, but the user does not and should not have that entitlement. Surplus and deficit exceptions apply to both accounts and group memberships.

An RBAC policy engine must support such approved exceptions, to avoid an explosion in the number of rules caused by users whose needs do not quite fit the role model.

Entitlement management with a combination of roles and approved exceptions is illustrated in Figure [link].

Entitlement management with a combination of roles and approved exceptions

Entitlement management with a combination of roles and approved exceptions

Approved exceptions, which prevent the RBAC policy engine from attempting to remediate surplus and deficit discrepancies that are actually desirable, is illustrated in Figure [link].

Batch enforcement of RBAC entitlement model with exceptions

Batch enforcement of RBAC entitlement model with exceptions

Automatic role assignment

A useful improvement to the basic role model of requesting access with roles to automate the access request process wherever possible. If a user's roles or other entitlements can be predicted based on identity attributes -- such as the user's location, department, job title, etc. -- then it makes sense to automate role assignment rather than waiting for users to request access manually.

Automated role assignment links user classes, whose membership is based on identity attributes, to roles, which contain entitlements. It may be additive -- i.e., "all users in user class UC1 should be automatically assigned the entitlements in role R1" and, optionally, subtractive -- i.e., "when a user is no longer a member of user class UC1, if he had previously been assigned role R1, then the role should be detached and its constituent entitlements revoked."

This process is illustrated in Figure [link].

Batch enforcement with automated role assignment

Batch enforcement with automated role assignment

Deferred revocation in role changes

One of the motivations for RBAC is to help identify the entitlements that should be revoked when a user moves to a different job function. Role changes enable this process, but there is an implicit assumption that old entitlements are revoked at the same time that new ones are assigned. In practice, this may not be true, as users continue to perform their old job function for some time, at least in a backup capacity. It is important to implement a process that decouples role changes into add-now, revoke-later pairs of requests, to support this.

Business roles, technical roles and role hierarchy

Roles may be thought of as the intersection between business responsibilities and the technical entitlements needed to fulfill them. It can 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 entitlements that are normally assigned together, often within the scope of a single system or application.

These approaches are combined using a role hierarchy. Higher level roles represent business function and include as members lower level roles, which represent patterns of entitlement assignment within each system and application. Business roles may be defined by business analysts, while technical roles may be defined by application owners.

This is illustrated in Figure [link].

Nesting technical roles inside business roles; auto-assignment to user classes

Nesting technical roles inside business roles; auto-assignment to user classes

Using a role hierarchy can ease role development, as people focus on defining roles they understand (either technical or organizational) and because multiple, similar roles can be simplified by moving shared entitlements into child roles.



2017-06-15 - H.D.

Excellent explanation of RBAC concepts