7.1 Understanding Collector Templates for Identity Sources

Identity collectors populate the catalog with identities and group data. Identities are at the core of the functions of Identity Governance. All collectors share some common elements and features. In addition, identity collectors also include identity specific collector views and publication behavior settings.

7.1.1 Understanding Identity Collector Views

Each identity collector comprises one or more of the following views that you can customize to match the characteristics of the data source being collected.

Collect Identity

To ensure that you can create a unique identity from the data that you collect, you can tell Identity Governance how to map the data collected from an application to the data that you collect from identity sources. Collect as much information as you need to fulfill your business needs. Also ensure that you collect enough information to allow application account and permission data to be joined to your identities. Some common join attributes that are available from most application sources include email address, workforceId, and name attributes.

Collect Group

Identity Governance always uses the userID attribute for an identity to join to the membership of collected groups. If a data source does not support group collection, Identity Governance does not allow you to configure this option.

An identity in the catalog can have attributes for one or more organizational group. For example, you might group employee identities by their department, such as Finance or Human Resources. You can use the collected group attribute to set the scope of a review, such as reviewing employees only in the Finance group. For example, Active Directory, eDirectory, and Identity Manager support this type of collection.

Collect Group to User Membership

Collects the relationship that joins users to groups from identity sources that maintain these relationships separate from the basic group information. For example, the JDBC Identity collector runs a SQL query that parses the table that contains the links between groups and users.

Collect Parent Group to Child Group Relationships

Collects the relationship that joins groups to subordinate groups from identity sources that maintain these relationships separate from the basic group information. For example, the eDirectory Identity collector uses this view to obtain nested group members of groups.

HINT:To optimize results, enable these views only when you want to get appropriate data and mapping information. You can disable these views if your data source does not contain identity group collection. For example, the Active Directory collector collects group, user member, and child group member information from the Collect Groups view. So, the other views can be disabled.

7.1.2 Understanding Publication Behavior

When you create an identity source, you can specify a publication option. The catalog contains data collected from multiple data sources. To create a unified identity for each person, you need to merge, or unify, the different sets of collected information. Merging occurs during the publication process. For each identity source, you can specify one of the following publication option:

Publish and merge

Use this option when you collect data for the same identity from different data sources. For example, both Active Directory and Salesforce.com have the same first_name and last_name attributes for Jane Smith. This option allows you to combine the duplicate attributes from the sources into one identity for Jane in the Identity Governance catalog.

When identity sources are merged to create combined published users, there are scenarios where a user collected from an identity source will not merge with a user from another identity source. By default, Identity Governance will create a new user when it cannot merge a collected user with an existing user. However, there are some identity sources where it is not desirable for a new user to be created. These identity sources are only intended to add information to existing users, and are not meant to create new users. You can specify whether a merged identity source should be allowed to create new users, or must always merge with a user collected from another identity source by enabling or disabling New User Creation.

When you edit the configuration of a publish and merge collector, the schema mapping user interface presents a Match rule check box next to each attribute mapping row. You must select at least one matching attribute before you can save the configuration. By specifying the matching attribute you can merge the collected data from an identity source to the existing data. For example, the Workfore ID is used as the matching attribute to map EmployeeNumber to Workforce ID and Last Name to LastName.

Figure 7-1 Attribute Matching

NOTE:You must specify unique values for the attributes you want to match during merging. In addition, do not use an empty (null) value as a matching attribute value. If a matching attribute has a null value, the record from the second source is discarded.

You must also specify the rules for merging. Only one of your data sources can be an authoritative source for each identity attribute. To help you specify the attribute authority, Identity Governance numbers the data sources within each collection. The first source listed becomes the default authoritative source for all attributes in the collection. However, you can reorder the priority of the data sources or override the default setting for specific attributes. For more information, see Section 9.1, Publishing Identity Sources.

Publish without merging

Use this option if you have only one identity source or your data sources do not contain the same identities. Since Identity Governance does not perform any merging activities during publication, you might observe faster performance. However, if your sources do contain the same identity, Identity Governance will treat those identities as separate people.

Do not publish

Use this option when you are configuring the identity source. For example, you might not want to publish any collected data when you are testing the process.