Role-based access control (RBAC)

[#1]

• What is role based access control?
• About this article
• Full versus partial RBAC
• Implementing RBAC in IdentityIQ
• IdentityIQ’s two-tier role model
• Required access and permitted access
• Defining and creating roles
• Assigning roles
• Reviewing and monitoring role assignments
• Maintaining roles
• RBAC project tips
• Additional resources

What is role based access control?

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.

About this article

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.

Full versus partial RBAC

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.

Implementing RBAC in IdentityIQ

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’s two-tier role model

IdentityIQ uses a two-tier role model to facilitate matching a user’s business responsibilities to their actual access.

• Business Roles generally represent job functions, titles, or responsibilities. They are usually tied to the organizational structure and are assigned to users based on their functions in the business – such as “Treasury Analyst” or “Accounts Payable Clerk”. Business roles define the desired state for a user’s access – what do we want someone with this job function to be able to do, or not do? Business roles are assigned to users directly, either automatically via attribute matching on things like job title or department, or via request, which may come from the user himself or from someone else, like a manager or an application owner.
• IT Roles encapsulate sets of system entitlements. They are tied to actual permissions within an application or target system. They represent the actual state of the user’s access, such as an account, entitlement, or permission. A user’s IT roles can be detected in IdentityIQ based on the entitlements that user has. Access can also be provisioned in IdentityIQ via IT roles.

Required access and permitted 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.

• Required relationships refer to the set of access that someone with a given role must have. Someone with an Accounts Payable business role, for example, will always need have to have read and write access to the accounting system.
• Permitted relationships mean the access is discretionary – these are permissions or entitlements a user may be allowed to have, but isn’t required to have. When permitted access is included with a business role, the entitlements are essentially “pre-screened” – we know that a user with this role is allowed to have the permitted access. For example, perhaps all employees are allowed to have VPN access but aren’t automatically given this access unless they or their manager requests it.

Defining and creating roles

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:

• Include business experts in the planning. It’s essential to work with your organization's subject matter experts – managers, IT and security teams, human resources, application owners, et cetera, who have a clear idea of what their team members do and how people use various applications – to help you determine which segments of your organization are most in need of RBAC. These business experts can also help identify patterns of access, define job responsibilities, and evaluate access options.
• Monitor the big picture. In addition to the business experts who will provide input on the needs of specific departments or applications, you also need someone with oversight over the entire role hierarchy to spot organization-wide patterns and see the big picture, in order to help you avoid role proliferation or duplication. There may be some overlap of access needs among disparate teams, so in order to avoid duplication of roles, you will need someone keeping track of the overall, top-level view of your role model.
• Familiarize yourself with IdentityIQ’s tools for role development. IdentityIQ provides a number of tools to help with role creation: Entitlement Analysis, IT Role Mining, and Business Role Mining all support analysis of the data which has been onboarded into IdentityIQ, and can create roles based on that analysis. You can export role mining data and ad hoc queries into a report format for your analysts to evaluate. The use of these valuable tools is covered in depth in both the product documentation and the Roles white paper (Role management in IdentityIQ​).
• Work with a meaningful entitlement catalog. Before developing your roles in IdentityIQ, it helps to have a meaningful entitlement catalog from which to build roles. The Entitlement Analysis feature is one of the most useful ways of identifying patterns of access and spotting “red flags” or outliers with singular access assignments. The usefulness of the analysis depends on an entitlement catalog that completely and correctly represents the access you want to manage.
• Use meaningful names and descriptions for business roles. When you create business roles, keep in mind that it’s important to use meaningful names and descriptions for the roles. These are available to people requesting and reviewing access and can be very valuable information to help users understand what each business role is for, and what it includes.
• Define your IdentityIQ team appropriately. The people who analyze and define the roles and the access that goes with them do not have to be the same people who work in IdentityIQ to set roles up. Choose the right team of people for working on the role model in IdentityIQ so that your definition and implementation efforts are secure and efficient.
• Create a process to approve role creation.  Plan for an approval process for role creation. Roles can be set up to trigger workflows for approval and notification. Putting new roles, or changes to roles, through an approval process protects against role proliferation/duplication.

Assigning 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.

Reviewing and monitoring role assignments

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.

Maintaining roles

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:

• The Role Editor supports creating and editing roles. You can configure roles such that a change or edit to the role will trigger a workflow for approvals and notifications before the role is promoted into production.
• The Role Composition Certification allows the role owner (or others) to review the access that makes up the role. This certification is an essential part of a role program, for keeping roles accurate and current.

RBAC project tips

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:

• Take a pragmatic approach. Think of RBAC as an ongoing program, not a project. Don’t expect to achieve 100% coverage of all access via RBAC as you implement it. A comprehensive RBAC solution could take months or even years to complete. It is realistic and acceptable to implement RBAC in steps or phases.
• Know what you’re trying to accomplish. Are you trying to make certifications easier? If so, your primary focus will be on evaluating and organizing current access. Is your goal to make access requests easier? In that case, you may want to focus on the Lifecycle Manager side of IdentityIQ, using roles to help users more easily find and select the roles they want to request.
• Look for groupings of role types. Use the IdentityIQ features such as Business/IT Role Mining and Entitlement Analysis to identify patterns and groupings of access and role types. This will help you avoid role proliferation.
• Enforce least privilege. Define roles so that you don’t give people access they don’t need. Setting up roles for the least privilege is a best practice for reducing security risk, both from malicious intent and from user errors.
• Expect exceptions to RBAC. In most enterprises, it is difficult or impossible to entirely avoid individual entitlements, especially in areas of highly specialized access needs, such as an IT department. Don’t assume you have to force all entitlements and all access models into roles.
• Make roles reusable. If only one person in the whole organization has some particular role, maybe that access shouldn’t be managed via a role. Make sure the roles you define are applicable to groups of people; otherwise your role model will be unwieldy and will not deliver the goals of efficiency and simplification.
• Involve the business experts. People within your organization who know the business are often the best resource for what the access patterns are and how should you structure your roles.
• Test and verify your roles. Roles need as much testing and verification as other functionality – maybe more. If you define roles sub-optimally at the outset and put them into production, you can end up with a lot of users who lack the access they need or who have more access than they should. There can be a big cleanup effort if you roll out a role structure that has not been set up and tested properly.
• Develop processes for role maintenance. Roles evolve, and you need to keep them up to date. Plan for periodic review and certification of your roles to make sure they’re still current and accurate. You should also plan for how to retire roles when they are no longer needed. Regular certification of role composition and role membership should be part of your ongoing RBAC strategy.

Additional resources

Role management in IdentityIQ

IdentityIQ documentation

Implementing Role-based access control with Humana

[Jayant_Kurumojee]

IdentityIQ Documentation link is not working