7.3 Understanding Variations for Application Sources

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.

Like the other Identity Governance collectors, the GitHub collectors map accounts and permissions to identities by association or other attributes. To successfully map accounts and permissions to identities, identities must be collected using the identity source that is configured in the GIT server. The GitHub permission collector collects organizations, teams, repositories, the permission to permission association, and also the holder association. The GitHub collector has a batch size limit of 100 records. The collector supports two authentication types, and to access all GitHub endpoints, the credentials used for the authentication types should be of an organization owner. The GitHub collector collects all organizations the owner holds.

The GitHub collector template includes mandatory attribute mappings suitable for the target application. However, you can configure other attributes and then edit the transform script to build the required payload. For example, for GitHub accounts if you want to map ‘email’ for the Account-User Mapping attribute, you have to map Account-User Mapping with user and write the script as given to parse the email from the user JSON.

var user = JSON.parse(inputValue) outputValue = user['email'];

Apart from the mapped attributes, you can add other attributes for organization by parsing the values from the organization JSON. For teams, you can parse the values from the teams JSON and for repository from the repository JSON.

If you use Cloud Bridge to collect data from your on-premises data centers, you must specify ordinals for the respective authentication method in the Cloud Bridge user interface (http://localhost (CBA IP address or DNS name):8080).

For more information, see the GitHub Docs.

The Microsoft Teams application is a subordinate application and uses the Azure Active Directory database. It consists of teams and channels with members of their own. Teams further divides members into team and channel members, or team and channel owners, with higher privileges. Teams are public and private and channels are standard and private. Each team can have a number of channels with one default standard channel.

While collecting data from Microsoft Teams application, you must use the Azure AD MS Graph collector for collecting accounts and identities and use the MS Teams collector to collect teams, channels, their members, and the associated permissions. However, for the collector to work, you must have the following API permissions in Azure Active Directory.

The Microsoft Teams collector does not collect data for itself. So, you must enable the Azure Active Directory data source to collect permissions from MS Teams. You have the option to configure MS Team collector as a hierarchical structure and map the attribute Unique Application ID with the applicationId.Make sure the outputValue in the ECMA script is mapped to the name of the collector. For example, outputValue='MS_Teams’.

The MS Team Permission collector template includes mandatory attribute mappings, such as ID, objectType. ID is the unique ID from a team or a channel, objectType indicates if the object is for teams or channels.

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 . 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)

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 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.

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.

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.

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.