Glossary of Terms for RSA Identity Governance & Lifecycle

[#1]

Article Number

000034057

Applies To

RSA Product Set: RSA Identity Governance & Lifecycle
RSA Version/Condition: All
 

Issue

This article contains definitions of various terms used in RSA Identity Governance & Lifecycle. It is common for new users to be confused over terms such as User, Identity, Account, Group, Role, etc. and how they interrelate. The purpose of this RSA Knowledge Base Article is to clarify such terms and their usage in RSA Identity Governance & Lifecycle.
 

Resolution

GLOSSARY

Resources (Directories/Applications)

Directories

Directories are objects you create and manage in RSA Identity Governance & Lifecycle that represent the data sources in your organization from which Identities (Users) and, in some cases, Accounts and Entitlements are collected. As the data sources in your organization contain the data you collect, the Directories you create serve as containers for the Collectors and the collected source data. Directories also serve as the managed entity for the data contained in them, which means Directory owners can be designated as participants in the review process and in approval and fulfillment phases for Change Request Workflows.

Applications

An Application is an object you create and manage in RSA Identity Governance & Lifecycle that represents an Application in your organization that Users access to do their jobs. For any Application in your organization, there are any number of ways Users can access its resources. Users can be directly granted granular Entitlements, Accounts, and Application Roles that provide access. They can also be granted access by virtue of belonging to Groups and Roles that have been granted Entitlements to an Application.

The Applications you create and manage in RSA Identity Governance & Lifecycle serve as the nexus between the following elements:

• The different modes of access to the Application (Users, Groups, Roles, and Accounts).
• The Entitlement and Account Collectors that collect the Application’s Entitlements data and Accounts data, respectively.
• The Entitlements and Application Roles available from the Application.
• The Change Request approval and fulfillment Workflows associated with the Application.
• The Violations of business Rules that have occurred for this Application (if the RSA Identity Governance & Lifecycle Rules module is enabled).

Business Unit

A Business Unit is an object that you create that represents a discrete segment within your organization in which Users are organized. Purchasing, accounting, and sales are but a few familiar examples of the Business Units likely found in your organization. Your organization’s Business Units have access to resources (Application Entitlements, Application Roles, and so on) that enable its Users to perform their business functions.

Data Collection

Data Collection is the process of extracting the data that defines who and what Accounts have Entitlements to what Applications and Permissions to shared file systems in your organization from its various data repositories. Data Collection is the prerequisite to all Access Governance tasks you can perform with RSA Identity Governance & Lifecycle. It constructs Identity (Users), Entitlement, Application Role, Account, Role, and Data Resource objects and creates the logical associations between them from the raw data collected. Because regulatory and security compliance demands dictate that your organization must be able to attest that is in compliance at any given point in time in an ever-changing enterprise-wide environment, periodic data collection is crucial to meeting those demands.

Data collection is a process that derives the following types of information:

• Who are the Users and what are the Roles, and Groups of Accounts in your organization?
• What are the Applications and Data Resources in your organization?
• What are the Entitlements, Accounts, and Permissions to Data Resources in your organization?
• Who owns Data Resources?
• What changes to Application Metadata have occurred?

Identity / User

An Identity defines Users in an organization who have access privileges to a quantifiable portion of an organization’s data and Applications and corresponds to a real person (User) who may have access through one or more Accounts to one or more Applications used in your organization.

Unification

Identity Unification is the process that consolidates user records collected from multiple user (or employee) data sources into a normalized user data model. A user data model provides a unified, enterprise-level view of the users in RSA Identity Governance & Lifecycle. It lets RSA Identity Governance & Lifecycle accurately associate Users with the entitlement Accounts they have been granted and the Roles and Business Units to which they belong.

Account

An Account provides access to an Application used in your organization through Entitlements and Application Roles. Accounts are collected through Account Collectors (ADCs). Accounts are not Identities or Users but may match the User ID attribute collected for an Identity. Accounts provide access to Applications for a User/real person.

Entitlement

Entitlements define the access privileges granted to one or more Users in an organization to a specific Application and the data within that Application.The Entitlements and Application Roles associated with Accounts are collected by Entitlement Collectors (EDCs).

Group

A Group is a container that includes Accounts and sub-groups of Accounts collected from account data sources by Account Collectors (ADCs). You view them under the Users tab in the User Interface (UI). Collecting Groups at the Identity level was deprecated in RSA Identity Governance & Lifecycle version 6.5 and completely removed in 7.0. Entitlement Collectors (EDCs) resolve references to Groups with Accounts and Entitlements but do not create/collect Groups.

Role and Role Set

Note: This is applicable only if the Role module is implemented for your installation. If you have system administrator privileges, you can enable the Role module in Admin > System Settings. In addition, enabling Business Role Manager (BRM) will help you develop new Roles and evaluate changes to existing Roles.
 

A Role represents an aggregation of Users (included individually or within an included Group or Role) and Entitlements (granular Entitlements, Application Roles, and other Roles). RSA Identity Governance & Lifecycle enables you to view all the Roles in the system, collect Roles, and organize Roles into Role Sets. A Role Set is simply a collection of Roles.

Group versus Role

A User gets access to a Group through their Accounts who are Members of a Group, whereas a Role gets Users added to it as Members. Adding Entitlements to a Group results in Users automatically getting the Entitlements indirectly. Entitlements added to a Role means the User is entitled to the Entitlement but it is not automatically given to the User. Role Entitlements are given to Role Members via Workflow configuration settings and/or Role Membership Rules.

Attribute

RSA Identity Governance & Lifecycle lets you create Attributes for collected, created, and managed objects. Pre-defined Attributes may provide only some of the Attributes you need for your objects. Creating Attributes lets you collect more comprehensive and important data. They also let you more accurately represent business sources for which you are managing compliance.

The Attributes you create function identically to pre-defined RSA Identity Governance & Lifecycle Attributes. You can use these Attributes for filtering criteria in Review, Rule definition, and information tables, and control how they are displayed in the user interface.

You can designate the Attributes that you create as collected Attributes or as locally managed Attributes. Collected Attributes can be assigned values through data collection. Locally managed Attribute values are not collected and can only be assigned values through the user interface.

Review

Reviews enable business managers and other personnel with oversight responsibility over who has access to resources in your organization to determine whether users have appropriate access to the resources they require, no more or no less, to do their jobs. RSA Identity Governance & Lifecycle provides enterprise-level visibility into what Entitlements, Permissions, and Accounts users have and what Groups and Roles they belong to and enable business managers to review and maintain or revoke the Entitlements and Memberships and certify the results. RSA Identity Governance & Lifecycle’s central repository keeps a historical trend of all the data it collects to let you see what access employees have at a particular point in time or how the collected information (for example, User Entitlements) has changed over time.

Change Request

A Change Request represents a set of business-related changes that are processed together by the system. Processing multiple changes in a single Request allows reviewers to see the full impact of the requested changes. This helps to avoid potential policy violations and security issues caused by separate processing.

Change Requests specify changes to user Entitlements and Memberships in Groups, Roles, and Application Roles. You can manually create Change Requests, and RSA Identity Governance & Lifecycle automatically generates Change Requests in the following scenarios:

• Entitlements revoked in Reviews
• Members added or removed from Roles
• Actions applied by Rules

A Change Request can be rejected or fulfilled. That decision is made by the access governance stakeholders, line of business managers, application owners, and other interested parties who understand what access to Resources users in your organization require. These decisions should be made in the approval phase, with due date actions to establish an Escalation Workflow as needed. Decisions in the fulfillment phase should be limited to fulfillment actions that require human input.

Changes that are not logically related should not be included together in a single Change Request. Independent Requests should be processed separately to avoid potential delays.

Workflow

A request workflow specifies the overall process that drives a Change Request to completion (fulfilled, rejected, or cancelled). Each node in a request Workflow specification represents a task that must be performed to complete a Change Request. A Change Request must be approved and then fulfilled and verified. The actions in turn are actually references to other Workflows that specify how the tasks must be performed.

• Request Worfklow - is the main Workflow and serves as a framework for the Change Request.
• Approval Workflow - a sub-workflow called from the Request Workflow and is intended to create an activity for business-level approvals of the changes being requested.
• Fulfillment Workflow - a sub-workflow called from the Request Workflow that exists to process the requested change and ensure that it is implemented in the target external system. A Fulfillment Workflow should include a closed-loop process to ensure that it is not completed until we have proven that the change has been provisioned, either by waiting for collection to process the change or by communicating directly with the endpoint via AFX.

Access Fulfillment Express (AFX) Connector

An AFX Connector fulfills Change Requests on an endpoint. As with manual fulfillment of Requests, the system uses collected data to verify that an AFX Connector fulfillment activity was completed. The AFX module provides a set of Connector templates for a variety of data sources such as Active Directory, database, multiple cloud applications, etc. from which you can create Connectors. Each Connector type includes a set of fulfillment commands that can be completed on an endpoint.

Rule

Note: This is applicable only if the Rules module is implemented for your installation. If you have system administrator privileges, you can enable the Rule module in Admin > System Settings.

RSA Identity Governance & Lifecycle enables users in an organization such as business managers or IT security officers, for example, to create and process business Rules that detect and notify specified users about various conditions reflected in collected data that should be monitored. Additionally Rules can potentially rectify those conditions in order to maintain compliance with an organization’s security and regulatory policies. For example, a Rule can be configured to detect whether users in a particular location, business unit, or department are able to access a particular application resource to which they should have access and vice versa.

Rules can also serve to provide decision support in user access request and role modeling processes. For example, RSA Identity Governance & Lifecycle could use a Rule to evaluate an Entitlement access request for a User to determine whether granting the request would violate a business Rule if it were allowed.

A Rule Violation occurs when a User Entitlement matching a Rule’s condition is detected.

Conditions you can detect with Rules include but are not limited to:

• Users that have Entitlements they should not have.
• Users that do not have Entitlements they should have.
• Users that have Entitlements that violate Segregation of Duties policies.
• User Attributes that have changed, which indicates that users have joined, moved within, or left your organization.
• User Entitlement changes.
• User terminations.
• Users that have Entitlements that have not been approved through a Change Request.
• Role Membership and Role Metrics changes.

Entitlements in the context of a business Rule include:

• Directly granted Entitlements and Entitlements granted through Accounts.
• Directly granted Application Roles.
• Indirectly granted Entitlements through Groups and Roles.

Reports can be generated on Rules, Rule Violations, and Rule violation exceptions.