Role-based access control (RBAC) is an approach to managing entitlements, intended to reduce the cost of security administration, ensure that users have only appropriate entitlements and to terminate no-longer-needed entitlements reliably and promptly.

In the context of a single system or application, RBAC means granting privileges directly to roles and attaching users to roles. Users acquire privileges through role membership, rather than directly. Within a single system, roles are sometimes called security groups or user groups.

Single-system RBAC is a time tested and successful strategy, as it allows administrators to group users, group privileges and attach sets of privileges to sets of users, rather than attaching individual privileges to individual users.

Hitachi ID Systems refers to both roles and groups that exist on individual systems or applications as groups, to distinguish them from roles. Hitachi ID uses the term role to refer to a construct that exists on an Identity and access management (IAM) system such as Hitachi ID Identity Manager and which may encapsulate multiple groups, spanning one or more systems.

IAM systems extend RBAC beyond single applications. Roles in an IAM system are sets of entitlements that may span multiple systems and applications. The key element of roles is to replace many technical entitlements with more user friendly labels that:

  • Business users can understand when:
    • Requesting access.
    • Reviewing requests, to approve or reject them.
    • Reviewing already-assigned entitlements, to determine whether they remain appropriate or should be revoked.
  • May be automatically assigned and/or revoked to different classes of users.
  • Can predict what entitlements users should have and automatically request adjustments to grant missing or revoke excess entitlements, so that users wind up with access that matches their assigned role(s).

Roles contain other entitlements -- login accounts and group memberships. Roles are often also nested -- i.e., one role can contain others. Nesting roles can reduce the cost of role administration.

There is a formal National Institute of Standards and Technologies (NIST) model for RBAC.

Hitachi ID Identity Manager includes a complete infrastructure for managing user entitlements using role based access control (RBAC).

  • Define roles:

    Administrators define roles in Hitachi ID Identity Manager as collections of:

    • Login accounts on specified target systems.
    • Membership in groups on target systems.

  • Role/entitlement analytics:

    Hitachi ID Identity Manager includes extensive analytics relating to existing roles, user classes and entitlement assignments. These are intended to support development and ongoing maintenance of a role model:

    1. Find clusters of users who have shared identity attributes and shared entitlements, as these are potential user classes and roles.
    2. Identify roles with overlapping entitlements -- should they be merged?
    3. Identify user classes with materially overlapping user populations -- should they be merged?
    4. Identify roles with too few users -- perhaps they should be retired.
    5. Identify roles with too many users -- perhaps they are too coarse-grained.
    6. Identify users with too many entitlements -- they could cause technical problems on end systems and probably represent high business risk.
    7. Identify users with too few entitlements -- do they still need access to systems or applications at all?
    8. Identify entitlements that are included in too many roles -- perhaps they should be attached to a base role, which is then nested into higher level roles.
    9. Identify entitlements not included in any role -- should they be?
    10. Identify users not assigned any role -- should they be? Are they members of a large enough community for this to be economical?
    11. Identify users assigned too many roles -- do they have too many access rights? Do new, higher-level roles have to be defined?
    12. Do any roles violate SoD policies internally (i.e., entitlements in the role are mutually exclusive)? This can happen when SoD policies are defined after the roles and should be remediated -- illegal combinations should not be so easily requested.
    13. Which roles have many users that, in turn, have many out-of-role entitlements? How many out-of-role entitlements do users assigned each role have, on average? This suggests either incomplete role definitions (add entitlements) or users that do not fit well into a role model.

  • Role hierarchy:

    In addition to entitlements on target systems, roles can include other roles. This allows organizations to define:

    • Technical roles, consisting of entitlements on target systems.
    • Business roles, consisting of other roles.

  • Mandatory and optional components:

    Roles may contain both mandatory and optional entitlements. Users who are assigned a role will, in general, be assigned all of the mandatory elements in a role. In addition, users who have been assigned a role may request any of its optional components, which will be granted without need for additional approvals.

  • Role assignment:

    Users can be assigned zero or more roles:

    • Some users can be outside the scope of the role-based access control (RBAC) infrastructure.
    • Other users can be assigned exactly one role, representing their singular job function.
    • Still other users can be assigned multiple roles, representing multiple job functions.

  • Manual and rule-based assignment:

    Roles may be assigned via a request process -- i.e., a requesting user U_q asks that a receiving user U_p be assigned role R_x. Such requests may be subject to policy and human approval before being completed.

    Roles can also be assigned automatically, by defining a class of users who should be assigned a given role and associating that class with the role. In this case, both on a batch basis (e.g., every few hours), with a throttle mechanism and as user profiles are altered in a manner that changes their qualification for the user class, roles are automatically assigned or revoked.

  • Role-based access requests:

    Requests to create new user profiles can specify a role -- either instead of or in addition to other entitlements that the new user should be provisioned.

    Requests relating to preexisting users can include role changes. Role changes may cause entitlements to be added, removed or left in place.

  • Approved exceptions:

    Some users may have a legitimate reason to retain privileges beyond those called for in their assigned roles or may not need all of the privileges in that role. Hitachi ID Identity Manager supports users who remain legitimately out of compliance, through approved exceptions to role-based security entitlements.

  • Controlled enforcement:

    Users can be flagged for role-based access control (RBAC) enforcement. This means that any entitlements they have in violation of their assigned roles -- either too many or too few -- can be detected and automatically remediated.

  • Cascading changes to role definitions:

    Hitachi ID Identity Manager includes an RBAC enforcement mechanism, which is normally run as a batch process every 24 hours. This system can detect users whose actual security entitlements are out of compliance with the entitlements that their assigned roles predict. This may be because changes were made to their profiles outside of Hitachi ID Identity Manager, or because the role's definition has changed.

    The RBAC enforcement mechanism detects non-compliant users and automatically submits workflow change requests to bring users back into compliance.

    One of the use cases this supports is cascading role changes: an administrator can change a role's definition and commit the change. On the next automated enforcement run, the RBAC automation subsystem will automatically submit workflow requests to bring users into compliance with the new role definition. These requests may be auto-approved (depending on organization policy), which means that they may be applied to target systems immediately.

  • Incremental deployment:

    It is difficult to enforce RBAC to every user in a large population simultaneously, such that any excess entitlements are automatically removed and any missing entitlements are automatically added. To avoid this, Hitachi ID Identity Manager supports gradual activation of users for RBAC enforcement, allowing time to educate users about the new system and troubleshoot errors in the role model for a few users at a time.

  • Role-aware access certification:

    Hitachi ID Identity Manager supports certification of accounts, attributes and group memberships from any integrated system:

    • Fine-grained entitlements assigned to users -- many checkboxes, based on data pulled directly from target systems.
    • Roles assigned to users -- fewer checkboxes, representing groups of privileges.
    • Approved exceptions to the privileges predicted for a user by policy, where the policy may be role assignment or a segregation of duties rules.

Return to Identity Management Concepts