Processing Provisioning Requests

IdentityIQ creates a master provisioning plan for the requested actions when a provisioning request is submitted from a provisioning request source. A workflow case is also created to manage and track the progress of the provisioning activity. The workflow case contains the workflow that specifies the process to follow.

Note

Certification and policy violation based provisioning does not use workflows.

IdentityIQ ships with predefined workflows or business processes which can be customized for each installation as needed. The workflow case created for each provisioning request is associated with the appropriate workflow for the event that generated the request. The following table lists the Workflows that drive the provisioning process from each request source.

Provisioning Request Source	Workflow Invoked
Lifecycle Manager	Main workflows include: LCM Create and Update, LCM Manage Password, LCM Registration, and LCM Provisioning
Identity Refresh	Identity Refresh
Define Identities	Identity Update
Lifecycle Events	Each event is managed by the business process listed in Business Process field on the Lifecycle Event definition window.
Certification Remediations / Provisioning	None Managed by and RemediationManager class. If the certification specifies Process Revokes Immediately, certification starts the remediation process directly.
Policy Violation Remediations	None Policy violations remediations that certifications create are managed the same as any other certification remediation. Policy violations remediated from Policy Violations page are saved directly to the violation table.

Involvement

The Perform Maintenance task processes all certification remediation including: roles entitlements and policy violations. This task invokes the Remediation Manager to process the remediation requests.

For certifications with specifications that include the Process Revokes Immediately option, the Certificationer object invokes the Remediation Manager directly to process the remediation requests. The basic logic of the provisioning process remains the same. The Remediation Manager uses the same mechanisms that the workflows use to complete the requests.

Remediation tasks that are performed on the Policy Violations page are not a part of these maintenance task processes.

Note

Requests on a certification for provision-missing-required-roles are not remediation items. These requests are added to the same provisioning plan as additional actions. The process that manages remediation items also manages these requests.

Overview of Provisioning Process

The Provisioning Process has three phases:

• Compiling the Plan – analysis and preparation of the plan for processing

• Answering Provisioning Policy Questions – request of missing required data from a user

• Implementing the Plan – submittal of the plan to the appropriate connector to provision the requested access

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:

Evaluate and Expand Roles

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 – removes role uncertainty.

• Application Provisioning Policies – applied when a new account is requested.

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

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.[Link needed]

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.[Link needed]

Answering Provisioning Policy Questions

After the plan is compiled, the project can have unanswered questions that must be presented to a person to answer. The provisioning broker does not interface with the user and cannot get answers to these questions. The workflow process, the component that controls the provisioning process, is responsible for getting the questions answered.

Exceptions

Because the following processes can not present forms to users, this interactive provisioning policy phase does not apply for the associated provisioning activities. These requests are only fulfilled if they can be completed with the available information. Because remediation requests are access removal requests, these requests should not require any additional data.

• Processes that manage certification remediations

• Processes that manager provisioning activities

• Policy-violation remediations

Generally projects that have unanswered questions are only an issues if the projects have activities that require a new account to be created for a new assignment or a missing role.

Provisioning Forms

The Lifecycle Manager Provisioning, Identity Refresh, and Identity Update Workflows invoke the Do Provisioning Forms business process. This process presents questions on user-facing forms and collects the answers. The Do Provisioning Forms process separates these actions into the following steps:

• Build Provisioning Form

• Present Provisioning Form

• Assimilate Provisioning Form

Optionally, you can assign owners for individual provisioning policy fields. When an owner is assigned, any questions related to the field are sent to the field owner and not to the access requester. The controlling workflow identifies who receives the questions and then submits the forms to the correct identities.

By default, the Lifecycle Manager Provisioning Workflow contains two opportunities to present provisioning forms to a user, pre-approval and post-approval. The following named steps run the Do Provisioning Forms workflow:

• Identity Request Initialize

• Identity Request Provision

A Workflow can have a different number of approval steps between the steps that present provisioning forms. Each approval can modify items in the master plan that cause the project to be recompiled. For example, if an approver rejects one of the role assignments, provisioning questions for an account that role requires might not be needed.

Implementing the Plan

After the plans are partitioned and any missing fields are provided, the subdivided plans can be implemented through one of the following mechanisms:

• Integrations

• Direct Read-Write Connectors

• Work Items

The results are recorded in the plan and indicate if the request was implemented immediately or placed in a queue for future implementation. This status determines when Identity Cube is updated to reflect the provisioned changes. See also Updating Identity Cube®.[Link needed]

The following table provides an overview of the provisioning mechanism.

Provisioning Mechanism	Plan Implementation
Integration Executors	Managed plan implementation using integration executors. Starts as an asynchronous process that might not complete immediately.
Direct Read-Write Connectors	Application objects contain the provisioning configuration.
Work Items	Unmanaged plan implementation using the controlling workflow.

Integrations

Integrations are a separately licensed components that communicate with systems within your network. The following table provides and overview of the integration modules and connectors.

System	Module	Connector
Provisioning systems, such as: OIM, ISIM, FIM	Provisioning Integration Modules (PIMs)	Read / Write connectors and IntegrationConfigs / Executors
IT Service Management, such as: Remedy, Service Now, HP Service Manager	Service Integration Modules (SIMs)	IntegrationConfigs / Executors
Mobile device management systems, such as: AirWatch, MobileIron, Good Technology	Mobile Integration Modules (MIMs)	Read / Write Connectors
IT Security: HP ArcSight	IT Security Integration Module	IntegrationConfigs / Executors
Enterprise Applications: Oracle EBS, SAP Portal, PeopleSoft, Siebel and NetSuite	Enterprise Resource Planning Integration Modules (ERP Integration Modules)	Read / Write Connectors
Mainframe: RACF, CA-Top Secret, CA-ACF2, RACF LDAP and Top Secret LDAP	Mainframe Integration Modules	Read / Write Connectors
Healthcare: Epic and Cerner	Healthcare Integration Modules	Read / Write Connectors
Identity Intelligence / Analytics: SAP GRC	GRC Integration Module	IntegrationConfigs / Executors

Integration Executors attempt an immediate update of the target application. If the immediate update attempt is unsuccessful, Integration Executors place the activity in a queue.

Note

Even if the activity does not immediately commit, the Integration Executors cannot communicate back to IdentityIQ when the request is completed. Therefore, these requests are always considered to be queued.

See Plan Initializer Rule.[Link needed]

Direct Read-Write Connectors

Read-write connectors are available to manage data communication between IdentityIQ and an ever-increasing number of applications. For applications using these connectors, you manage provisioning activities through the variables in the Provisioning configuration for that application.

Provisioning using direct read-write connector with these applications is fully automated. These connectors generally:

• Run the plan immediately.

• Can report back a committed status to IdentityIQ in real time.

• Confirm that the changes can be reflected in Identity Cube immediately.

See also Plan Initializer Rule.[Link needed]

IdentityIQ Updates

For items that require updates to IdentityIQ, such as roles assigned to an identity or identity attribute changes, a separate plan is created. These requests are similar to direct connector updates. Although no connector is required to complete these internal updates, the requests are run immediately and are reported back as committed when updated.

Work Items

Work Items, opened in IdentityIQ that contain provisioning instructions, to provision unmanaged plans. The controlling workflow or Remediation Manager is responsible for implementing an unmanaged plan. An unmanaged plan:

• Includes provisioning requests to any application where data is aggregated using read-only connectors.

• Does not have an Integration Executor that communicates with the plan.

• Are identified and examined after the Integration Executors and direct read-write connectors are called.

If the unmanaged plan contains any requests, one or more work items are opened in IdentityIQ that contains the provisioning instructions from the plan. Each work item is assigned to a user who is responsible for implementing the changes required to complete the specified provisioning tasks. Work item assignees are often the application or entitlement owner. When the provisioning action is completed, the work item assignee must manually mark the work item as complete.

Note

Provisioning tasks managed through work items are considered queued, rather than committed. Even if the assigned user marks the work item complete, IdentityIQ cannot determine with certainty if the changes were actually made until the next aggregation from the source application is completed.

Plan Initializer Rule

You can specify a Plan Initializer rule to run during the implementation of the provisioning plan. An installation-specific rule can be added to integration and provisioning configurations. When a rule is specified, it runs immediately prior to running the provisioning activity for the application. Provisioning is based on the provisioning plan and application associated configuration or integration executor.

See Implementing the Plan.[Link needed]