Skip to main content

Role Based Access Control - Hitachi ID Access Certifier

What is RBAC?

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 groups of privileges to groups of users, rather than attaching individual privileges to individual users.

Identity management and access governance 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 fewer roles that business users can understand. Business users can then a reasonable determination of which users should have which roles. This implicitly specifies which users should have which technical entitlements.

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

To manage entitlements primarily using roles, organizations must reach two milestones:

  1. Role definition:

    Define a sufficiently rich set of roles, such that the set of entitlements required by any given user can be expressed in terms of one or more roles.

  2. User classification:

    Assign every user to at least one role, so as to specify which entitlements the user should have.

These milestones are straightforward where there are large numbers of users who need the same entitlements. Examples of homogeneous populations include point-of-sale retail users and students in a higher education institution.

These same milestones can be very difficult to achieve where there are significant numbers of users each of whom needs a unique set of entitlements. This is true in many back-office operations, for example.

Roles are usually accompanied by two kinds of rules:

  1. Automatic role assignment:

    These rules determine which roles a given user should get, based on the user's identity attributes. For example, users in a given department may automatically get a specific role.

  2. Extra details or entitlements:

    Instead of defining a new role for every possible variation of entitlements, a rule may be used to make adjustments to the entitlements predicted by a base role. For example, a rule may specify a server where a mail box will be created, or an extra security group to be assigned.

Even with rules and nested roles, large numbers of unique users may still be difficult to incorporate into an RBAC system. Maintenance of the role model itself can, in some cases, be just as hard as managing entitlements directly on target systems and applications.

An additional challenge in many RBAC implementations is deciding when to deactivate old entitlements. When users change roles, some of their old entitlements should be removed and some new ones added. Users may carry on some of their old responsibilities for a transition period. This means that new entitlements should be activated immediately but old entitlements should be removed some time later. The difficulty is determining just when to deactivate old entitlements.

Request-Based User Provisioning

Because of the challenges in implementing a 100% role-based access management system, most organizations also use a request-based system.

Request based systems can be automated, typically with web-based change request forms and e-mail based invitations asking appropriate users to review and authorize changes.

Automated requests are also possible: a data feed from a system of record, such as an HR application, may automatically trigger change requests.

Use RBAC Where Appropriate

RBAC should be used where appropriate and economical -- i.e., where there are large numbers of users with identical or very similar entitlement requirements. Other techniques should supplement RBAC where RBAC is too costly to define or maintain:

  • Always use roles inside individual applications.
  • Use enterprise roles (i.e., roles that span multiple applications) to manage the security rights of large sets of users with identical requirements that don't change often.
  • Use roles to grant new users their initial set of entitlements.
  • Try to define relatively few, relatively coarse-grained roles rather attempting to capture every entitlement needed by every user with large numbers of fine-grained roles.
  • Try to avoid over-reliance on roles when managing access rights of users whose needs are either unique or rapidly evolving.

Read More:

  • Architecture:
    Hitachi ID Suite network architecture.
  • Included Connectors:
    Systems on which Access Certifier can audit and reduce privileges.
  • Auto-Discovery System:
    How the Hitachi ID Access Certifier automatically discovers new, deleted and changed users and privileges on integrated systems and applications.
  • Other Integrations:
    Integrations between Hitachi ID Suite and other parts of an IT infrastructure.
  • Workflow:
    Workflow to prompt stakeholders to perform micro-audits, and to authorize access reductions.
  • RBAC:
    Relating Access Certification to role based access control.
  • Server Requirements:
    Sizing, configuration and number of servers on which to deploy Access Certifier
  • Language Support:
    Languages Supported by the Hitachi ID Identity and Access Management Suite
page top page top