Identity Governance processes require clean, up-to-date data obtained from a variety of sources such as Identity Manager, Active Directory, and other enterprise applications in the data center and the cloud. Identity Governance can obtain the data by directly connecting to the systems through protocols such as LDAP and JDBC, or it can simply load the data from a periodically extracted data file such as a Comma Separated Value (CSV) formatted file.
Identities are the first part of the Entitlement Catalog. Identity Governance can collect, correlate, and publish the identities. Plus, if you integrate with Identity Manager, you can leverage all the capabilities of Identity Manager to provide a synchronized, composite view of the people or things in your organization from multiple changing systems of record. Identity Governance can collect Identities from multiple sources but it logically publishes the identities to a single name space in the Catalog.
Identity Governance maps the identity and entitlement data to a minimum standard schema. The schema can be extended to include custom attributes to match the shape of your identity and entitlement data.
Permissions are the next major part of the Entitlement Catalog. Applications have their own namespaces and Identity Governance can collect and publish the permissions per application in parallel. Identity Governance uses the latest published Identity Catalog to map who has what access to permissions in each application when it is published.
Collection templates are the default mappings of data from identity and application sources to the core Identity Governance standard schema. At a minimum, connection specific information such as accounts and passwords or API keys and access tokens must be provided to save the template and collect the data.
Identity Governance provides templates to simplify the collection of data from the applications. For more information about the templates, see Collecting Identity and Application Data.
Identity Governance has two categories of data sources: identity and application. An identity source, such as SAP User Management or Active Directory, provides attributes of an identity. For example, you import employee names, titles, and human resources attributes. Identities, also referred to as users in the user interface and in this document, represent the people who are at the core of the processes within Identity Governance. They are the who in the review process of “who has access to what.” Identities are also the people who manage and perform the reviews, or who serve as the administrators of Identity Governance. Identity sources with change events enable incremental changes to the user and group data without having to frequently collect and publish identities.
To review the access for an application, such as Salesforce, you can create an application source. The application source can collect data for accounts and permissions. Accounts and permissions are the what in the review process of “who has access to what.” In general, accounts represent entities, such as a system, application, or data source, that an identity might access. For example, your employees might have an account that lets them log in to a self-service human resources application. Accounts often specify the type of permissions granted to the user. Permissions can describe any of the following:
Actions that you can take within an application, such as running reports
Items that you possess, such as an identity badge
Things that you can access, such as a building
Your organization might also have a hierarchy of permissions based on roles. For example, a corporate role called Sales Employee might consist of various child permissions that apply to all employees, such as Garage Access, Building Access, and Read Access to Company Intranet. The role might also have permissions associated with sales software applications and financial data.
Each application source can contain separate collectors for gathering specific account and permission data. Account collectors help you discover accounts that have been added or deleted since the previous data collection. You can also determine whether accounts are being used, such as identifying the last login for that account. When you collect permission data, you can review changes to permissions, such as new groups or roles. You can also view changes in the assignments of permissions to users or accounts.
During the data collection phase, Identity Governance collects raw data from specified identity and application data sources. Identity Governance can collect data from the following types of sources:
Active Directory
Azure
CSV file
eDirectory
Google Apps
Identity Manager
JDBC
RACF
Salesforce.com
SAP User Management
ServiceNow
NOTE:Active Directory, eDirectory, and Identity Manager identity sources can be configured to generate incremental change events.
Identity Governance provides several predefined collector templates to facilitate data collection. A collector template lets you quickly build and customize a collector. Whenever possible, the collector templates include predefined attribute mappings and value transformation policies suitable for the target data source. To automate the collection process, you can create scheduled collections that define the interval and data sources that you want to collect.
For more information about collecting data, see Section III, Managing the Identity Governance Catalog.
After collecting identity data, you can publish a snapshot of the Identity Governance catalog. The snapshot presents a consolidated view of the collected identities. Using Identity Governance, you can directly associate user identities and permissions. Alternatively, you can associate identities with accounts and associate the accounts with permissions. For more information about publishing, see Section 18.0, Publishing the Collected Data.
If you use the Identity Manager Driver for Identity Governance (Identity Governance driver), you can synchronize data that Identity Governance has collected from application sources with identities, roles, and resources in Identity Manager. For example, the Identity Vault for Identity Manager contains information related to the roles and resources assigned to Joe Smith for applications A, B, and C. Identity Governance collects Joe’s roles and permissions from applications D, E, and F. When you publish the Identity Governance catalog to Identity Manager, the driver allows you to reflect Joe’s roles, resources, and permissions in the Identity Vault. This option ensures that you do not have duplicate information for Joe Smith. Also, Joe can now request access to resources in applications that Identity Manager does not manage. For more information about synchronizing and reflecting user data, see Understanding Synchronization and Reflection. For more information about the driver, see the NetIQ Identity Manager Driver for Access Review Installation and Configuration Guide.
The next step is the manual process of preparing the published data for review. During the manual process, you can improve data quality by:
Defining technical roles
Defining business role policies
Setting policies, such as Separation of Duties
Providing additional meta data
Defining business-friendly names for various entities
Specifying risk factors for applications, roles, authorizations, and permissions
You can also edit the data by changing the collected values. The Identity Governance browser-based interface provides an easy way to resolve the mappings that exist among different user, account, and permission object types. For more information about preparing data, see Editing Attribute Values on Objects in the Catalog.