Role Management Concepts

The sections below outline some important terms and concepts regarding roles and how they are managed in IdentityIQ.

Benefits of Roles

A major benefit of implementing roles is using them to translate entitlement data into terms that can be more clearly understood by business managers and other employees, as they request, assign, and review access. Through roles, entitlements can be grouped together and presented as a logical unit, such as a job function, rather than as a detailed and often difficult-to-interpret list of access rights.

In some cases, the way entitlements are named or described can make it difficult for a reviewer to understand what the entitlement means. For example, groups names may use acronyms or numeric values which do not offer a great deal of contextual information to the layperson; even when names are more descriptive, inclusion of DN data in the group name may obscure the important values, at least at first glance. Roles can be used to simplify and clarify how the data is presented to the business user.

Sometimes a single job function may require multiple system entitlements, either all on the same application, or across multiple resources. Without roles, the reviewing manager needs to know about all of the required pieces – both to understand why an employee has access to each of these, and to ensure that employees have all the access they need to do the job. With roles, all of these permissions can be encapsulated in a single role and presented to the reviewer as a unit, both clarifying and simplifying the reviewing process.

Similarly, encapsulating entitlements into roles also makes it possible for a manager to automatically provision the required entitlements for a new employee, simply by assigning that person the appropriate role.

Role Types

By default, there are four types of roles configured in IdentityIQ:

Organizational Roles

Organizational roles are designed for organizing the role hierarchy in the IdentityIQ UI for easier management. By default, they do not perform any function other than creating a nesting structure in the Role Modeler. Organizational roles can be defined in any hierarchical structure desired. Possible structures could include:

• A hierarchy matching the corporate org structure for organizing business roles into easily managed groupings

• A set of container roles for holding collections of IT roles based on commonalities between them

• A set of container roles grouping other roles by application

• A set of container roles grouping other roles alphabetically

• Any combination of these structures (or others)

The key is to use organizational roles to simplify navigation through the role structure for administrators who will be tasked with managing the roles.

Business Roles

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 you want someone with this job function to be able to do, or not do?

For example, within the Accounts Payable department, there might be an AP Supervisor, 3 AP Lead Accountants, and 30 Accounting Clerks. This would require the creation of 3 business roles:

• AP Supervisor

• AP Lead Accountant

• AP Clerk

However, if all clerks don't do the same basic job, it may help to create additional roles to further divide them into sub-units. For example, perhaps the mailroom clerks are tasked with opening, stamping, and digitally scanning invoices while other clerks are responsible for accounting system data entry and reporting. In that case, the department might implement four business roles:

• AP Supervisor

• AP Lead Accountant

• AP Entry Clerk

• AP Mailroom Clerk

In some cases, business roles may be defined by the managerial hierarchy in place at the company. For example, there may be a strict hierarchy of managerial and supervisory job titles that is replicated within any division or department, such as

• Vice President

• Director

• Manager

• Supervisor

• Lead

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

IT Roles encapsulate sets of system entitlements. They are tied to actual permissions within an application or target system. IT roles represent the actual state of the user's access, such as an account, entitlement, or permission. IT roles should encapsulate groups of related entitlements that are shared by one or more business roles. If too many entitlements are grouped together, each IT role may only apply to one business role and lose any potential reuse benefits. If too few are grouped into each IT role, each business role will have to be connected to large numbers of IT roles to provide the required system access for the job; this can also result in role proliferation that makes role management an overly cumbersome activity, reducing their value to the organization. The goal therefore is to encapsulate as many entitlements into each role as possible without over-grouping.

A user's IT roles can be detected in IdentityIQ based on the entitlements that user has. Access can also be provisioned in IdentityIQ through IT roles.

Entitlement

Entitlement roles were originally created to represent a single entitlement on a single application; currently, Entitlement Roles exist for backward compatibility with versions 5.x and earlier of IdentityIQ, and are not recommended for current/new installations.

Custom Roles

Custom role types can be created to model a structure that doesn't easily fit into the IdentityIQ default model. In addition, existing role types can be configured to function differently from their default behaviors. Because there are so many ways roles can be customized, this document only discusses IdentityIQ's role structure in the default configuration.

IdentityIQ's Two-Tier Role Model

IdentityIQ by default uses a two-tier role model, to facilitate matching a user's business responsibilities to their actual access. Although you are not required to implement your roles using this two-tier model, it is helpful to understand the benefit of this model as you plan your implementation.

In the two-tier model, IT roles are linked to business roles, to tie actual access to your defined job functions and titles. This allows end users such as managers or access reviewers to work with familiar, user-friendly business roles rather than having to understand and act on every individual entitlement that is managed in IdentityIQ. IT roles can be shared by multiple business roles, as needed.

Linking IT Roles to Business Roles: Required 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.

IT roles are connected to business roles through the Required Roles and Permitted Roles lists.

• Required roles 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 roles 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.

The required IT role connection is used as the driving force for provisioning entitlements based on role assignment. When a business role is assigned to an Identity, requiring entitlements the Identity does not have, the entitlements for the required IT roles will be provisioned for the Identity. Depending on how provisioning is configured, this process can range from entirely manual to fully automated.

These require and permitted connections also help identify missing entitlements during the certification process. When a user is missing required entitlements for the IT roles under business roles assigned to them, the access review can reflect this to bring it to the reviewer's attention. Correction of that state is not done in the certification process itself; that is left to the refresh process or some other out-of-band process.

Role Inheritance

In some organizations, business roles or IT roles can be efficiently modeled using an inheritance-based role structure.

Business Roles

Business roles can be modeled with inheritance when a set of business roles can be defined by increasingly specific criteria. Consider a Help Desk team made up of three support levels (business roles). Each higher numbered level may be able to do all the same activities as the lower numbered group(s) but also have extra tasks that the lower numbered groups do not do.

For example:

1. Help Desk Level 1

   • Answer calls, troubleshoot basic issues

   • Route complex problems to Level 2

2. Help Desk Level 2

   • Diagnose problems routed from Level 1

   • Refer problems not resolved within 24 hours to Level 3

   • Answer calls and engage in basic troubleshooting when time available

3. Help Desk Level 3

   • Resolve problems referred from Level 2

   • Assist with Level 2 issues when time available

   • Answer calls and engage in basic troubleshooting when time available

Perhaps the organization is structured so that all Help Desk personnel are assigned to the Department "Help Desk." Additionally, all Level 2 and Level 3 Help Desk personnel are in the Denver location (while Level 1 personnel are not). Further, Level 3 personnel must hold the job title "Senior Engineer."

These increasingly-specific shared attributes can be used to create the assignment rules for each of the inherited roles. When IdentityIQ applies the assignment rules to an inherited role structure, the role assigned to each Identity is the deepest one in the inheritance hierarchy that applies.

When the assignment rules run, Identities are assigned to only one of the roles in an inheritance structure. Only the most specific role – the deepest level in the hierarchy – that applies to the Identity is assigned. In other words, if an Identity's attributes meet the criteria for Level 1 and Level 2, Level 2 is assigned; if they match all three Levels' criteria, Level 3 is assigned.

IT roles

IT roles are modeled with inheritance when entitlement access for one set of Identities is a superset of the access grant to another set of Identities. For example, perhaps all Engineering users have access to the bug tracking system and project planning tool, but only Developers have access to the version control system. The Developer IT role could inherit from the Engineering IT role. Detection of IT roles in an inheritance structure operates on the same basic premise as assignment of inheritance-based business roles: an Identity will only have one role in the hierarchy detected for it and it will be the deepest one that applies to that Identity. In the Engineering example, an Identity that has the Developer IT role detected for it will not also have the Engineering IT role detected. However, the Developer IT role is only detected if all entitlements for both roles are found on the Identity.

Limitations of Role Inheritance

It is important to note that if organizational roles are interspersed with business roles in a hierarchy, the organizational roles' presence will disrupt the inheritance functionality. Inheritance of these traits only applies to roles of the same type that inherit from each other in a hierarchy that is not interrupted by other role types.

The direct inheritance of an IT role directly in a Business or Container role is not supported.

Understanding Relationships Between Roles and Entitlements or Permissions

Roles bundle sets of access (entitlements and permissions) together so that access can be more easily managed and governed. Entitlements, which typically take the form of an account on an application or membership in a group, control access to a system or application, and encompass actions the user with the entitlement can take in the application. Permissions represent direct access, independent of account or group membership, to an action a user can take in a system or application.

The access allowed by roles can be direct or indirect. For example, an Accountant role can give direct access to the Accounting system, in the form of an account on the system. Indirect access is typically granted through nested groups or a set of inherited roles; for example, an Accounting Supervisor role may inherit the Accountant role, and thereby be indirectly granted all the access an Accountant would have on the Accounting system.

Part of maintaining an efficient and functional role model is understanding and monitoring the connections between roles and the entitlements and permissions they allow.

For example, if you are making changes to the set of entitlements defined in your Active Directory application, it's important to understand which roles will be affected by those changes. Or, if you want to examine your role model to see where different roles may overlap in terms of the access they grant, it's useful to be able to see exactly which entitlements and permissions are included within multiple roles. If an application is going to be retired, it's useful to review ahead of time which roles include access to the application, so that the role can be changed accordingly.

IdentityIQ provides many tools to help you monitor and manage the relationships between roles and entitlements / permissions. You can examine roles to discover which entitlements and permissions they grant, and you can also examine entitlements and permissions to see which roles include them.

Establishing Connections Between Roles and Access

An IdentityIQ task called Role-Entitlement Associations builds a table of relationships between roles and access, ensuring referential integrity in your role model. This task only needs to be run one time to establish role associations to entitlements and permissions; once it has been run, IdentityIQ automatically updates the relationship table any time changes are made to role profiles.

This task is run by default when upgrading from an earlier version of IdentityIQ to the current version; in an upgrade scenario, you do not need to run the task independently of the upgrade process in order to establish these relationships.

Although there is no requirement to run the Role-Entitlement Associations task again after it is first run, you can choose to run it if you want to – for example, if you have onboarded many applications in a short timeframe and want to take extra care to ensure that your relationship table is up to date.

Examining Roles: What Access Do They Provide?

The Role Profiles Composition report lets you see which entitlements and permissions are included in specific roles. See Role Profiles Composition Report.

The Advanced Analytics Role search includes criteria to search for roles by access profile, for entitlements, permissions, or both. See Role Search Criteria.

The Role Viewer (Setup > Roles) lets you drill into Role Statistics details about individual entitlements; the detail view lists Associated Roles where relevant. See Role Viewer Tab.

Examining Entitlements and Permissions: Which Roles Include Them?

The Roles by Entitlement report lists all roles that grant particular entitlements or permissions. See Roles by Entitlement Report.

The Role Member report includes entitlement and permission criteria, that lets you see which users are members of roles that grant specific access. See Role Members Report.

The Advanced Analytics Role search includes criteria to search for roles by access profile, for entitlements, permissions, or both. See Role Search Criteria.

You can drill down to Role Association information for entitlements and permissions in these areas of IdentityIQ:

• The Entitlement Catalog includes an Associated Roles tab listing the roles that provide direct access to the entitlement. See Entitlement Catalog.

• In the Identity Warehouse, you can click on individual entitlements to see Associated Roles that provide direct access to the entitlement for this user. See the Identity Warehouse Page.

• In the Application Definition, the Accounts tab for the application lists users with accounts on the application. You can click the arrow next to a user to see specific entitlements, then click on an entitlement to see details that include Associated Roles where applicable. See Configuring an Application.

• Work items for access review challenges or decisions include an option to drill down into specific entitlements to see Associated Roles where applicable. See Work Items.

• In Targeted Certifications, the What do you want to certify? section lets you enter criteria for selecting roles. Source Application, Source Attribute, and Source Value filtering attributes let you refine which roles are included in the certification by the entitlement access granted by the roles. See Targeted Certification: What to Certify.

• When adding or removing access using the Manage User Access Quicklink, you can filter access based on the Role Source Application, Role Source Attribute, or Role Source value. You can also click the Details button on access items and drill down into the Entitlement Profile to see Associated Roles for the item.

• When approving access, you can click the information icon (?) for any access item, and drill down into the Role Hierarchy's Entitlement Profiles, to see Associated Roles for the access item.

How Roles are Created

IdentityIQ provides a comprehensive set of role engineering tools in the Role Management UI, to help your organization rapidly build and deploy an enterprise role model. These tools include an interactive role modeling interface as well as business and IT role mining capabilities.

Business roles and IT roles can be manually created through the Role Management user interface.

You can also use the role mining feature to generate business and IT roles; role mining can often do the task more efficiently than a manual process. Roles created through role mining can then be manually modified.

In business role mining, roles are identified based on one or more identity attributes in IdentityIQ. For example, if Job Title is one of the identity attributes, a business role can be created based on each unique Job Title.

In IT role mining, IT roles are generated based on system access current employees already have.

Both the Role Management UI and the Role Mining feature are discussed in detail later in this section.

How Roles are Assigned

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; they also could be 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 includes 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.

Using Assignment Rules to Assign Business Roles to Identities

Automatic role assignment is done based on the Assignment Rule for the role. When roles are created through Role Mining, the Assignment Rule is automatically generated to match the selection criteria that created the role.

When the Assignment Rule is executed, the appropriate Identities are automatically assigned that business role. To execute the roles' assignment rules, run an Identity Refresh task with the Refresh assigned, detected roles and promote additional entitlements option selected. See Identity Refresh.

Manually created roles must have an Assignment Rule written for them to allow them to be assigned to Identities automatically. The assignment rule for each role can be defined through any of these constructs:

• Match List – checks for a match in one or more identity or application attribute values

• Filter – specifies matching criteria in a XML representation.

• Script / Rule – BeanShell code that sets the criteria for assigning the role; usually used when the conditions for the assignment rule are too complex for the simpler constructs

• Population – saved set of search criteria identifying a population of identities; Populations are created from Advanced Analytics searches.

If role-mining-generated roles are manually modified, the assignment rules generated for them may no longer apply. In that case, the assignment rules must be edited as well to prevent them from being incorrectly assigned to Identities.

For an overview of developing and using rules in IdentityIQ, see Rules and Scripts in IdentityIQ.

Reviewing and Monitoring Roles and Role Assignments

Review of roles and role assignments is an essential part of successful roles program. Tools for monitoring role assignments include:

Manager and Targeted Certifications
These certifications allow managers to review roles assigned to their employees.

Role Membership Certifications
These certifications let the owner(s) of the role itself review all the users who have that role.

Role Composition Certifications
These certifications allow the role owner (or others) to review the access that makes up the role, to ensure that roles are accurate and current.

These certification options are discussed in detail in Manage and Schedule Certifications.

Role Based Access Control (RBAC)

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.

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 have only 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.

Here are some key IdentityIQ concepts you should be familiar with as you plan your implementation of RBAC:

• IdentityIQ's Two-Tier Role Model

• Linking IT Roles to Business Roles: Required and Permitted Access

• How Roles are Assigned

• Reviewing and Monitoring Roles and Role Assignments

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, etc. 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.

• The Role Editor Page 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. See How to Perform a Role Composition Access Review.

Best Practices for Defining and Creating Roles for RBAC

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 , Role Mining for Business and IT Roles, and Role Modeling 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.

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

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