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.
Account and permission collectors are the two types of collectors available within an application source. 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 or 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. Identity Governance enables you to collect and publish accounts, then view both mapped and unmapped accounts in the Accounts catalog.
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.
NOTE:The source type of application connectors does not have to be the same. For example, there may be an attribute on User accounts in Active Directory (for example, myAppRoles) that is used to assign permissions for an enterprise application. Although the accounts are collected from Active Directory, permissions may be collected from a JDBC database, a CSV file, or some other source.
Some permission collectors can collect nested permission assignments. For parent-child hierarchy permissions, when a user has an assignment for a child permission, they may also optionally be given an assignment for the parent permission. To allow the creation of these nested permission assignments, you must enable the option Populate Nested Permission Assignments while configuring the service parameters. The AD Permission and the eDirectory Permission collector templates include this option by default, but you can create a custom template and include the option to collect nested permission assignments.
IMPORTANT:When Populate Nested Permission Assignments is enabled, the assignment type attribute on collected permission assignments will show as DIRECT even if the value supplied by the collector is different. Identity Governance ignores the assignment type attribute value supplied by the collector.
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.
Accounts can also have custodians. Some application sources such as eDirectory and Active Directory supports the concept of custodians which can be collected directly from the application. Once you collect the data, you can configure the account collector template to map the Account custodian attribute and join it to identity available in the Identity Governance catalog.
Identity Governance uses the Account-User Mapping attribute to join the accounts with the identities available in the catalog. You must specify the value for Account-User Mapping and the Map to attribute for Identity Governance to do the association.
Applies only to Identity Manager AE data sources.
Applies only to Identity Manager AE data sources.
Permission collectors gather the following types of information and create a catalog of permissions for the Application source:
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. The primary purpose of these views is to get the detailed information about the permission objects or values of a selected permission type.
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.
Sometimes a permission might have a owner assigned to it to review the access, evaluate the risk, or confirm decisions before removing permissions. You can collect the data directly from the application source and configure the permission collector template to map the Permission Owner attribute to identities or account holder. To map identities and groups as permission owners, specify a value for the Permissions-owners-mapping attribute, then select either User ID from Source or Group ID from Source or select both.
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.