Aggregation Rules
Aggregation Rules are used during part of the aggregation process that occurs after the connector has created valid ResourceObjects for the accounts or groups being aggregated, i.e. after the defined connector rules have all been run. There are two types of aggregation: account and account group. A Refresh rule can be specified to run at the end of account aggregation but also can also be run from an Identity Refresh task.
The rules described in this section can be used to perform these actions:
The rules described in this section can be used to perform these actions:
- Modify the ResourceObjects provided by the connector before they are correlated and aggregated
- Correlate ResourceObjects to existing Identities
- Control attribute population during creation new of Identities when a matching Identity is not found for correlation, particularly when aggregating from an authoritative source
- Correlate manager Identities
- Customize the creation of Managed Entitlements during aggregation/refresh
- Customize an Identity before storing it (at the end of aggregation or during Identity Refresh)
- Customize account group attributes before storing (during account group aggregation)
- Aggregation rules are described here in the order in which they are run when specified for a given aggregation task.
ResourceObjectCustomization
Whenever we do aggregation identityIQ fetches those target system accounts in the form of resource objects.
Resource Object is a Data Structure which is understood by Sailpoint so it converts all the accounts from the target systems finally in the resource objects and then it tries to dump into the database or identityiq so finally the thing which is understood by the identityIQ is resource object so it can do some customizations on that resource object.
So While bringing the data into IdentityIQ ( means bringing through aggregation ) you can do the customization and can put that record into identityIQ. So can do modification to resource object using customization rule.
A ResourceObjectCustomization rule runs prior to any other aggregation rule to customize the resource object provided by the connector before aggregation begins
Example:
there are 5 colums in table emp and i want to hard code 1 other attribute as employment type. so will achieve this using customization rule
Also can do modification of resource object of Authoritative application example to add attribute fullname.
verify customization rule modified resource object of authoritative and jdbc app.
Note : Difference between BuildMap and Customization Rule
Managed Entitlement Customization
Example: Made one attribute as managed in schema of an application. here department is managed and when do aggregation this managed attribute gets populate in Entitlement Catalog. But these are non-requestable by default. so what need to be done to make requestable suppose for one of these and also to set owner name.
so which rule can help in customizing the resource object of entitlement data or managed attribute data.
so after writing rule and done the aggregation the managed attribute one with value as 1 only made requestable but set description and owner for all managed attributes
To find an identity based on some attribute of an account/link is called correlation.
A Correlation Rule is used to select the existing Identity to which the aggregated account information should be connected. Correlation can be specified on the application definition through a simple attribute match process or it can be managed with a rule. If both are specified, the correlation rule supersedes the correlation attribute specification and the simple attribute match will only be attempted if the rule does not return an Identity.
Correlation Rule : A rule that is used to identify identity on the basis of some attribute say "firstname" or "lastname".
Correlation Rule : A rule that is used to identify identity on the basis of some attribute say "firstname" or "lastname".
NOTE: Except as noted above with respect to optimized aggregation, the Correlation rule runs for every Link created in the aggregation. Therefore, time-intensive operations performed in it can have a negative impact on aggregation performance.
If the correlation rule cannot find an Identity that corresponds to the account, one must be created. By default, the Identity Name is set to the display attribute from the resource object (or the identity attribute if display attribute is null) and the Manager attribute is set to false. An IdentityCreation rule specifies any other Identity attribute population, or any change to these two attribute values, based on the account data. It can also be used to set values like a default IdentityIQ password for the Identity.
If the application is not an authoritative application, any Identities created for its accounts must later be manually correlated to an authoritative Identity or the accounts will have to be recorrelated through an automated process to connect them to the correct authoritative Identities.
IdentityCreation rules are most commonly specified for authoritative applications, since new Identities created from those accounts are real, permanent Identities. However, they can also be used for non-authoritative application accounts to set attributes that can make manual correlation easier.
This rule is associated to an application in the UI through the application definition:
Define -> Applications -> select existing or create new application -> Rules -> Creation Rule
As with Identity correlation, manager correlation can be specified on the application definition through a simple attribute match process or it can be managed with a rule. If a rule is defined, it is used to determine the correct manager Identity; if no rule is defined, the Identity attribute match process is used to find the manager Identity. A ManagerCorrelation Rule identifies an Identity’s manager based on an application account attribute (or attributes) on the account being aggregated or refreshed.
RefreshRule
A Refresh rule runs at the end of the Identity Refresh process, both during an Identity Refresh task and at the end of an Aggregation task. It allows custom manipulation of Identity attributes while the Identity is being refreshed. Refresh rules are most commonly used in manually-executed refresh tasks configured for data cleanup when erroneous aggregation configurations have resulted in unintended data consequences on Identities. However, they can also be used in normal refresh or aggregation tasks to set attributes (usually custom attributes).
NOTE: Since the Refresh rules run for every Identity involved in the aggregation or refresh task, time-intensive operations performed in it can have a negative impact on task performance.