Compiling the Plan

The Plan Compiler is responsible for the following tasks:

Create the Provisioning Project

The Plan Compiler calculates plans for provisioning using IntegrationConfig objects. Some details of application objects are maintained as an in-memory cache and, because of the cached nature of the objects, an update to an Application or an IntegrationConfig might not immediately take effect for plan calculations.

By default, cache updates are performed every 10 minutes. To modify this, in a test or deployment environment, modify the following SystemConfiguration options:

The master plan is evaluated for any role assignments. If the plan contains role assignments, those roles must be expanded. The role expansion process:

  • Identifies IT roles that an assigned business role needs.

  • Determines what specific entitlements the IT role needs.

  • Adds the entitlements to the lists of account/attribute/permission request for the provisioning project. Each attribute is represented as an Attribute Request or a Permission Request.

For example, Business Role X is added to an identity. Business Role X requires IT Role A which has entitlements associated with its role. The Plan Complier determines that IT Role A is required, identifies the necessary entitlements, and adds the entitlements to the project.

Note: After role expansion is complete, IT Role A does not display in the project. Only the raw entitlements that the IT role A needs are listed.

Apply Provisioning Policies

A provisioning policy is a list of fields with names that correspond to an application account attribute name the role uses. Provisioning Policies can be used to help complete an access request that has unknown data required for provisioning. When a provisioning request requires additional information to complete the access request, you can apply a provisioning policy specified for the application involved. Examples of additional or unknown data that is required for provisioning include the following items:

Types of Provisioning Policies include:

Role Provisioning Policies

The primary purpose of provisioning policies on roles is to remove any uncertainty for the role. In some cases, examining the role profile can determine the set of entitlements to be provisioned for an IT role. Role profiles can be clear or unclear. When all the role profile terms are joined using AND statements, the profile is clear. IdentityIQ can easily analyze the role profile and provision entitlements that match the profile.

For example, A profile that includes a list of OR terms is unclear, because two or more different memberOf values can satisfy the role. The following table provides examples.

Role Profile Example Terms

Type of Terms

Explanation

location='Austin' and memberOf='Engineering'

Profile with a list of AND terms

To satisfy this role, the identity must have both of these account attributes. Requests for those two attributes are added to the plan.

memberOf='Engineering' OR memberOf='Sales’

Profile with a list of OR terms

The default provisioning behavior for profiles containing OR terms is to provision only the first one. In this case, memberOf='Engineering' is added to the plan but not memberOf='Sales'.

If the organization wants memberOf='Sales’ provisioned for new role members, a provisioning policy can be defined with one field named memberOf with the field value Sales.

Note: Fields can also be assigned scripts or rules that enable the appropriate value to be calculated instead of using a hard-coded value.

Application Provisioning Policies

Provisioning Policies can also be specified for applications. These policies are applied when a new account is requested on an application. Application Provisioning Policies are similar to Role Provision Policies and can specify the field values as literal values or through a script or rule. The following actions trigger application provisioning policies:

Application Dependency

You can specify an application dependency at the field level when you create a policy. Application dependency works with synchronous connectors and does not work with connectors that queue plans. Application dependencies are enforced during Create operations. For update and delete, the dependencies are ignored.

Note: IdentityIQ does not undo dependencies during de-provisioning.

To specify an application dependency:

  1. Navigate to Applications -> Application Definition. On the Provisioning Policies tab of the Application Configuration page select the dependent application for the provisioning.

  2. Double-click or right-click the application in the Application List.

  3. On the Application Configuration page, select the Provisioning Policies tab.

  4. Define the application dependency at the field level in the Create Account and Create Group policies.

Application dependency works similar to roles and entitlements. If a dependency is missing, IdentityIQ expands it and executes a Create request for the dependency. If the user has an existing link on a dependent application, IdentityIQ uses the existing link information to derive the value. When there are multiple accounts on the link, the applicable accounts are selected automatically using rules or through an interactive user interface. Selecting an account can be an option to create a new account.

The available attributes are derived from the account schema of all dependent applications. During plan compilation, IdentityIQ reads these properties and determines any new accounts that are required to satisfy the dependency.

During Plan Evaluation, IdentityIQ uses the dependency settings to determine the order that must be used to implement the plan. If a dependency plan fails, all of the dependent plans also fail. If a dependency plan requires a retry, after the retry is successfully completed, the dependent plans are executed. There is special new logic in the Provision with Retries method that loops back to the provisioning step when there are still plans to complete.

There are not transformations (rules) on dependent fields. The evaluation process copies the exact values from the dependency plan or link to the dependent plan.

Identify Questions

After the provisioning policies are applied, pieces of data can still be missing. Some provisioning policies are specifically written so the data must be obtained from a person when the role or application account is requested. These missing data elements are recorded as questions on the provisioning project. These questions are presented to a person who must provide the information necessary to complete the provision request. See Answering Provisioning Policy Questions.

Filter and Check Dependencies

Filter and Check Dependencies streamline the provisioning process and prevent unintended consequences of the requests. During this step of the compilation process:

  • The current state of the identity is examined.

  • Any entitlements requested in the plan that already exist for the identity are removed from the plan.

  • Entitlements that are to be removed, based on a role removal, are examined. This step determines if the identity has another role that requires the entitlement that is scheduled to be removed.

Note: If the identity has another role that requires that entitlement, the entitlement removal request is taken out of the plan.

Partition the Plan

At the end of plan compilation, all the individual entitlement requests identified from the original master plan and the role expansion are partitioned into a set of smaller provisioning plans – one per target. The targets are designated by the connector or integrationConfig that IdentityIQ uses to communicate with them. Connections can include:

Note: Any requests in the plan that cannot be processed by any of the integration configurations or read-write connectors are added to the unmanaged plan and are processed manually through IdentityIQ Work Items.

See also Implementing the Plan.