Role-based access control (RBAC) is an approach to access security that relies on a person’s role within an organization to determine what access they have. A role is a collection of permissions, and users receive permissions through the roles they have been assigned. (Permissions or access in this definition can mean many things, such as the ability to perform certain tasks, permission to view, edit, or create files, or holding superuser privileges on sensitive applications, to give just a few examples.) This allows roles within an organization to remain relatively stable while users and permissions can change rapidly.
One of the main goals of RBAC is to grant employees only the access they need to do their jobs, and to prevent them from having access that is not relevant to them. A well-designed RBAC system also simplifies and streamlines the administration of access, by grouping sets of access in a logical and intuitive way, based on things like department, job function or title, region, or manager level. Grouping access permissions into roles provides a secure and efficient way of managing access, and helps keep things simple for administrators, certifiers, and the users requesting access.
Implementing RBAC can be a major and complex operation. This article discusses some of the things you should be aware of and take into account as you plan your RBAC solution.
This article is based in large part on a webinar about RBAC that was presented to a customer group by Technical Manager Tina Timmerman: you can view a recording of that webinar here: Roles and RBAC
Also note that this article focuses on RBAC rather than on roles in general. For a comprehensive look at how roles work in IdentityIQ, see Role management in IdentityIQ.
RBAC is often talked about as a comprehensive system, but in actual practice it can be implemented as a partial solution. As you plan your organization’s RBAC strategy, don’t get too caught up in the idea that all access must be managed only through roles. A partial RBAC solution that manages some but not all access through roles can still provide a great deal of value. Trying to achieve 100% coverage for all access can easily result in a proliferation of roles, including the creation of roles which may only have one person in them. This can ultimately undercut the goal of making access easier and more efficient to manage.
Some job profiles are particularly well suited to an RBAC approach, such as jobs that involve a high degree of standardization, high turnover, seasonal employment, or a need for particularly rapid onboarding; other job profiles, such as those in an IT department that involve highly privileged and specialized access, may not be good candidates for RBAC.
IdentityIQ provides many features and tools that support implementation of RBAC – role editing and modeling, role mining, entitlement analysis, certifications for role membership and role composition, and workflows for governing changes. This article does not discuss these specific features in detail, but you can learn more about them in Role management in IdentityIQ and in the IdentityIQ product documentation.
However, there are some key IdentityIQ concepts you should be familiar with as you plan your implementation of RBAC: IdentityIQ's two-tier role model and the concept of required access and permitted access.
IdentityIQ uses a two-tier role model to facilitate matching a user’s business responsibilities to their actual access.
When IT roles are linked to business roles, IdentityIQ uses the IT role definitions to know what access it should provision for a user when they are assigned the business role. Business roles and IT roles are linked using two types of relationships: required and permitted.
As you set about defining the roles for RBAC, you need a clear picture of the business roles in your organization, and of the entitlements. Part of this exercise is determining where to start implementing RBAC. It may not be realistic to try to set up RBAC for your entire organization all at once, and where you start will depend a lot on your type of business and your organization.
Here are some best practices for defining and creating roles:
Business roles can be assigned in a couple of ways. Roles can be assigned automatically based on attribute matching, using assignment rules in the business role. This is typically used for birthright provisioning – that is, simply because someone is an employee, they automatically get some set of business roles; furthermore, if they are in the Accounting department (as indicated by an attribute defining their department), they get another business role; and if they are also a manager, they may get yet another business role. This can all be done automatically when an identity is created, or when it is updated with, for example, a change of department or a change of manager status. Birthright roles are frequently marked as not requestable, and also excluded from the certification process, since we expect users to be granted these roles simply by virtue of who they are.
Roles can also be requestable – that is, a role can be assigned to a user based on a request for the role from, for example, the user’s manager, an application manager, or from the user himself. Part of designing your role model and your RBAC strategy will be determining who may request roles, and who will approve the role requests. When you define your roles, you can specify role attributes that determine what the approval process is.
Review of role assignments is an essential part of an RBAC strategy. Tools for monitoring role assignments include Manager Certifications, which allows managers to review roles assigned to their employees, and Role Membership Certifications, which let the owner(s) of the role itself review all the users who have that role.
An RBAC system is successful only to the extent that the roles it relies on are current, relevant, and appropriately scoped. In addition to monitoring who has a role, you have to monitor what is in a role. Within your organization, the types of available access can change, job descriptions can change, new applications can get added, et cetera. People in your organization must have confidence that roles are meaningful and current, or they may stop using them.
IdentityIQ offers some features to help you maintain your roles. You can read more about how to use these features in the IdentityIQ product documentation and in the Role management in IdentityIQ white paper:
Here are some pointers based on the experience of customers, partners, and SailPoint solution architects who have implemented RBAC in the field. While your own project requirements may vary and will depend on your business needs, these are things to consider as you plan your RBAC strategy: