7.3 Understanding Variations for Application Sources

7.3.1 Understanding Azure AD MS Graph Account and Permission Collectors

Your old Azure AD User account and permission collectors have been disabled. For more information about collecting from Azure AD MS Graph account and permission collectors, see Section 6.2.1, Collecting from Active Directory with Azure Active Directory.

7.3.2 Understanding the Identity Manager AE Permission Collector

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 the CloudAD Driver and SAP User Management Driver, that support Identity Manager entitlements. When the Identity Manager AE Permission collector collects any User record from the Identity Manager application that has an association with a subordinate application (via the DirXML Association attribute on the User) it receives an Account assignment for that subordinate application. The Identity Manager AE Permission collector also automatically maps the User record 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 and is disabled by default. For more information, about enabling this template, see Section 3.4, Customizing the Collector Templates for Data Sources. When using the Cloud Bridge to collect data from your on-premises data centers, you will need to specify ordinals for the respective authentication method in the Cloud Bridge user interface (http://localhost (CBA IP address or DNS name):8080)

NOTE:When an Identity Manager AE permission is requested in Identity Governance Access Request, the idmDn attribute of the requesting user is utilized in the RBPM SOAP request as the <ser:requester>. If this value is not a valid user DN in the target Identity Manager system, the fulfillment request will fail.

7.3.3 Understanding the Identity Manager Entitlements Account and Permission Collectors

The Identity Manager Entitlement collectors are intended for Identity Manager Standard Edition (IDM SE) users who want to use Identity Governance to provision or revoke accounts and permissions. The entitlement collectors collect accounts and permissions from Identity Manager using IDM drivers that support entitlements such as Azure, Workday, and SCIM drivers. Like the other Identity Governance collectors, the entitlement collectors map accounts and permissions to identities by association or other attributes. To successfully collect accounts and permissions:

  • You must have collected identities from Identity Manager, and

  • All supported drivers must be running

You can use the account collectors to collect accounts and the permission collectors to collect permissions and their assignments. For example, the permission collector can collect the building access permission (list of buildings) and assignments (who can access the building).

In addition to IDM credentials, the LDAP distinguished name of the entitlement in the IDM driver is also a mandatory field for the entitlement collectors.

Typically, attribute mappings are preconfigured and have built-in fallback options. For example, by default, the collector maps the account or permission name to the IDM display name. If the collection process does not find the display name, the collector automatically maps the account or permission name to other available attributes such as the description. However, you do need to change the default Account-User Mapping value GUID to Object GUID and default Permission-Account or User Mapping value association to Account ID from source.

7.3.4 Understanding and Configuring the Workday Account and Permission Collectors

Security groups control access to data in Workday. Security groups are a collection of users or of objects that are related to users. Micro Focus provides default templates for the Workday account and permission collections. Workday permission collectors support two types of permission collections: User Based Security Group and Role Based Permissions. Role-based permissions are always associated with a specific organization. When using role-based permission collectors, you can also collect permission hierarchy. Collected role based permission in the catalog, includes role name, permission, and organization as the name of the permission and displays permission relationships.

When configuring the Workday Account Collector, configure service parameters as needed, then specify the Account-User Mapping parameter as WorkdayUserName and map it to Object GUID to join accounts to identities.

When configuring the Workday Permission Collector, configure service parameters, then select the permission type.

  • To collect user-based security group permissions, specify Permission-Account or User Mapping parameter value as WorkdayUserName and map it to Account Name to join permissions to the account.

  • To collect role-based permissions, specify the Permission-Account or User Mapping value as WorkforceID and map it to Workforce ID to map permission to identities. Additionally, leave the organization type blank to collect all role-based permissions or specify an organization type to collect permissions associated with an organization.

    When specifying a specific organization, to collect the hierarchy of role-based permissions using organization hierarchy, map the Parent Permission ID to wd-superior_organization. Mapping this will collect and establish the child/parent permission relationship for role-based permissions.

7.3.5 Understanding the SCIM Account and Permission Collectors

The System for Cross-domain Identity Management (SCIM) account and permission collectors are unique collectors that use unique authentication methods. By default, the generic SCIM permission collector collects groups as permission for the resource type. However, you can configure the collector to collect other permissions by setting the Resource Type and mapping the attributes of that resource type. For example, if you want to add printers as permission you can give the endpoint of that resource type and map the required attributes to perform the collection.

7.3.6 Understanding and Configuring the Salesforce Account and Permission Collectors

Using standard Identity Governance Salesforce collector templates, you can collect data from User, UserRole, and Profile objects. The User object is used for Salesforce Identity and Salesforce Account collectors as well as the permission-holder information in the permission collectors.

The generic Salesforce permission collector is configured by default to collect UserRole permissions. However, you can configure the collector to collect other permission types such as UserLicense, PackageLicense, PermissionSetLicense, PermissionSet, PermissionSetGroup, and Profile. For your convenience, Identity Governance also provides Salesforce Role Permission and Salesforce Profile Permission collector templates to collect only UserRole and Profile objects respectively.