An application collector can be a single-application collector or a multi-application collector. To configure an application as a multi-application collector, you must specify a unique ID when configuring the application source. If you do not specify a unique ID, Identity Governance will create a unique ID and recognize it as a single application data source. For an application to be eligible for collection using the multi-application collector:
The subordinate applications must have no collectors.
The application must have a unique ID (Application ID from Source).
The permissions of the application must not be collected by any other application.
In general, application data stores do not maintain personal information about the account holders since it is not needed for the operation of the application. These applications might hold basic information such as an Account Identifier (or login ID), a password, and the set of permissions that have been granted to the account users (group memberships, roles, ACLs, and so forth). In a typical enterprise, there will also be some account attribute (or combination of them) that can be used to associate (or “join”) the account to the identity that uses the account. However, this is not true for all accounts. Many applications have “admin” or “system” accounts that IT staff and administrators use to maintain the application, grant access to others, and so forth. Often, these “admin/system” accounts are granted the greatest level of permissions for the application. Additionally, sometimes these “superuser” accounts are shared by a group of individuals. As a result, it is very important to collect and review all accounts from the data source whether they can be joined to an identity or not.
Account collectors gather information about the application users, such as their name, account ID, login name, and login time. Permission collectors gather information about the application access rights of the account users. Since there is no universal method for linking accounts and permissions to identities, these collectors also provide the attributes and optional views necessary to join application accounts to Identity Governance identities and to join application permissions to either Identity Governance identities or the application accounts as needed.
Depending on the type of data that you want to collect, the account collector template might provide the following elements:
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 your company email system. An account in Identity Governance is similar to an association in Identity Manager.
Applies only to Identity Manager AE data sources.
Applies only to Identity Manager AE data sources.
Permission collectors gather the following types of information:
The set of permissions and descriptive attributes for each permission type
The hierarchical relationship (if any) among permissions
The data that will allow Identity Governance to join permission assignments to Identities or Accounts
There are a great number of variations in the way that permissions and their various relationships are described within each application source. To accommodate this variety, Identity Governance provides many ways to configure permission collectors by using views.
Used to collect the available permission values and descriptive information about the permission. If the permission schema contains the information needed to establish permission hierarchy and join permission values to Identities or Accounts, this view can be utilized to perform those functions also – with the benefit of configuration simplicity and better performance. Some examples of applications that utilize this type of combined view are the Active Directory and eDirectory Group permission collectors.
Used when the information about assigned permissions is contained within a source that has the holder-to-permission relationship defined on the holder (Account of Identity) records. Some examples of applications that use this method exclusively are Salesforce.com and SAP. An example of this relationship would be the memberOf attribute on Active Directory User objects.
Used when the information about assigned permissions is contained within a source that has the holder-to-permission relationship defined on the permission records. An example of this relationship would be the User members attribute on eDirectory Group objects.
Used to collect top-down permission relationships. An example of this relationship would be the Group members attribute on eDirectory Group objects.
Used to collect bottom-up permission relationships. An example of this relationship would be the Group memberOf attribute on eDirectory Group objects.