Creating and Applying Rules for Data Handling
These are the rules that can be customized to handle data the manipulation requirements of the aggregation or provisioning processes for each application. Rules are specific to connectors and are used throughout the product. You can write more than one of each type and select the rule to use from drop-down lists.
A file containing an example of each rule type is included in the IdentityIQ installation package. The examplerules.xml
file is located in the IdentityIQ_HOME/WEB-INF/config directory
.
Many rule types apply to all applications and are called by the aggregation process. Other connectors may include additional rule options that are specific to the connector type.
For each rule type, you can select a rule that has already been created from the drop down. To edit or create a new rule, click the "..." icon next to a rule drop-down list to access the rule editor throughout IdentityIQ. Choose to either create a new rule, or edit an existing rule structure.
Aggregation Rules
These rules define behavior when aggregating data from the application. 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, which occurs after the defined connector rules have all been run.

This rule type is used to define identity correlation for applications whose accounts cannot be correlated to Identities through a simple attribute match in a correlation configuration. A correlation rule is required if the logic to correlate accounts is more complex than a correlation configuration will support (for example, correlating based on multiple attributes taken together).

This rule is only run when a new identity is being created during the aggregation. Some examples of operations which might be performed in a creation rule include setting an identity’s password, changing the name of aggregated identities, or setting an attribute to all caps. Typically, this rule is only used for authoritative applications, though one could be specified for a non-authoritative application if needed.

A manager correlation specifies how one identity should be linked to another in a Manager – Direct-report relationship. This can often be accomplished with a simple attribute mapping correlation on the Correlation tab, but when a more complex matching algorithm is required, this rule type can be used.

This is an open-ended rule which is available to all application types in IdentityIQ for manipulating or customizing the aggregated data before the account (or group) is saved to the database. This rule type is most often used for manipulating data on application types which do not offer Connector Rules, since for those applications, this rule is the only account-manipulation rule offered.

The Managed Entitlement Customization rule is called during creation of Managed Entitlements in an aggregation or refresh task, or in the Missing Managed Entitlements Scan task. This rule can modify the Managed Entitlement as it is being created, to set fields such as owner, requestable, or descriptions before they are saved. Managed Entitlements are ManagedAttribute
objects, which are Entitlement Catalog entries.
Provisioning Rules
These rules run during the processing of provisioning requests. Some are connector specific and some apply for all connectors, as indicated in their descriptions. Provisioning-related rules which apply to all application types are:

The BeforeProvisioning
rule is executed immediately before the connector's provisioning method is called. This gives customer the ability to customize or react to anything in the ProvisioningPlan
before the requests are sent to the underlying connectors used in provisioning. This rule is not connector-specific; it runs for all applications regardless of connector type.

An application’s AfterProvisioning
rule is executed immediately after the connector's provisioning method is called, but only if the provisioning result is in a committed or queued state. This gives customers the ability to customize or react to anything in the ProvisioningPlan
that has been sent out to specific applications after the provisioning request has been processed. This rule is not connector-specific; it runs for all applications regardless of connector type.
Schema Rules
Schema rules vary by connector and are used for customization. Schema rules allow you to segregate business logic account and group objects respectively, avoiding the need to check whether the resourceobject
represents an account or non-account object.