In general, application data stores do not maintain personal information about the account holders since it is not needed for 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 to 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 data sources
Applies only to Identity Manager 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 a large number of 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/or 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.
The Identity Manager AE Permission collector is a unique type of Application Source collector. In addition to creating the base Identity Manager application in Identity Governance, it also automatically generates subordinate applications that represent IDM Drivers, such as CloudAD Driver and SAP User Management Driver, that support Identity Manager Entitlements. Any User record collected from the Identity Manager application that is associated with a subordinate application (via the DirXML-Association attribute on the User) will also receive an Account assignment for that application and be automatically mapped to the Identity Manager User.
No other application source permission collector provides automatic generation of subordinate applications or accounts. Due to the complexity of the relationships managed by this collector, the template intentionally blocks customization to ensure the integrity of the data collections.