4 Managing Workflows

Managing workflows include understanding and configuring workflow rules, managing request approval in an upgraded deployment, moving workflow policies from test to production, and running Oracle Identity Manager without workflows.

This contains the following sections:

4.1 Understanding Workflow Rules

Understand workflow rules, request process flow with or without workflows, and request lifecycle for single and bulk requests.

This sections describes about the approval workflows in the following topics:

4.1.1 About Workflow Rules

Request generation and approval depends on the usage and configuration of workflow rules.

Request generation and approval is governed by the following:

  • Whether Oracle Identity Manager is running with or without workflows. By default, workflows are enabled in Oracle Identity Manager. For information about running Oracle Identity Manager without workflows, see Running Oracle Identity Governance Without Workflows.

  • Approval workflow rules defined for the supported operations.

Note:

Approval policies have been deprecated in favor of workflow policies. Request generation and approval is governed by workflow policies, as described in this document.

If you have upgraded Oracle Identity Manager from an earlier release, then approval policies continue to work.

However, Oracle recommends that you migrate all existing approval policies to workflow policies.

Workflow rules determine the following:

  • Whether or not approvals are required for an operation

  • Which workflow must be invoked for a specific operation

4.1.2 About Request Process Flow

The process flow of a request depends on whether or not the operation is allowed, single or bulk operation, and the deployment is with or without workflows.

The process of request generation and approval, which is governed by approval workflow rules, is depicted in Figure 4-1.

Figure 4-1 Request Process Flow

Description of Figure 4-1 follows
Description of "Figure 4-1 Request Process Flow"

The request process flow is as follows:

  1. Authorization checks are performed based on the admin roles granted to the user. This check determines whether or not the user is allowed to perform the operation.

  2. If the operation is not authorized, then an error is returned and the flow ends.

  3. If the operation is allowed, then it is checked if the operation is a bulk operation or future-dated operation.

  4. If it is a bulk or future-dated operation, then a request is created, approval is initiated based on workflow rule evaluation, and the operation is completed after approval.

  5. If it is not a bulk or future-dated operation, then approval workflow rules are evaluated. The result of this evaluation determines whether request is created or not.

    • If the result is Direct, then no request is created, and the operation is performed directly.

    • If a SOA Workflow ID is returned as the result, then a request is created, and the workflow returned by the policy evaluation is invoked.

Bulk requests are processed in the following way:

  • An allowed bulk operation always results in a request being created.

  • Approval workflow rules configured for the bulk operation are evaluated.

    If rule evaluation results in a workflow ID, then bulk request is created and corresponding SOA workflow is initiated.

    If rule evaluation results in no workflow ID, then bulk request is created and it is auto-approved.

  • After the bulk request is approved (auto-approved or SOA workflow approval), child requests are created.

  • Child requests go through approval workflow rule evaluation (non-bulk), and are processed based on the outcome.

4.1.3 About Request Lifecycle

Each request goes through a specific lifecycle after it is created in the system. The lifecycle transits the request through various stages. The stage a request is in determines what action the controller takes in that step, what operations are available on the request at that time, and what the possible stage transitions are.

Request lifecycle is described in the following sections:

4.1.3.1 Various Request Stages

Table 4-1 describes how a request functions at various stages through its life cycle and how a request attains these stages.

Table 4-1 Request Stages

Request Stage Description

Request Draft Created

After saving the request as a draft by clicking the Save as Draft button on the Cart Details page, the request moves to the Request Draft Created stage.

A requester can save a request for modifying, submitting, or deleting it later. This is useful if the requester is awaiting additional information before submitting the request. The draft request cannot be withdrawn or closed.

Note: The request data saved in draft mode does not include sensitive information such as passwords, even if they were entered before saving the request as draft.

Request Created

After successful submission of the request, the request moves to the Request Created stage.

Provide Information

This is a task assigned to requester (accessible from Inbox) for the entitlement request to search for and select the account for which the entitlement needs to be provisioned.

Request Awaiting Approval

After the request is created, the request moves to the Request Awaiting Approval stage automatically if there are approvals defined for this request. At this stage, the corresponding approvals are initiated through the request service.

If a request is withdrawn or closed at this stage, then the request engine calls cancel workflow on each workflow instance. Notifications are sent to approvers about the withdrawn tasks.

After the request successfully completes these statuses, it will attain the Request Approved stage.

If an SoD validation check is plugged-in after the request has been successfully created, the request is associated with the following statuses.

  • SoD check not initiated

    A request attains this stage, if the SoD validation is not initiated for provisioning resource based request. The request engine moves the request to this stage after submission of request and before Obtaining Approval.

  • SoD check initiated

    A request attains this stage, if the SoD validation is initiated asynchronously for provisioning resource based request. The request engine moves the request to this stage after submission of request and before Obtaining Approval.

  • SoD check completed

    A request attains this stage, if the SoD validation is completed for provisioning resource based request. The request engine moves the request to this stage after submission of request and before Obtaining Approval.

Note: These SoD request statuses are possible if the request is any of the following request types:

  • Provision Application Instance

  • Modify Account

  • Provision Entitlement

  • Revoke Entitlement

  • Assign Roles

  • Remove from Roles

Request Approved

Only after a request is approved, it moves to the next stage and is updated with the current status. The outcome is Approved, Rejected, or Pending.

Request Auto Approved

Only after a request is approved, it moves to the next stage and is updated with the current status.

Request Rejected

Each time a workflow instance is updated, request service updates the request engine with the current status of that instance. The outcome that the request engine expects from request service is Approved or Rejected. If any of the workflow instances that are instantiated are rejected, then request engine moves the request to Rejected stage. If any workflow instance is rejected, then the controller calls cancel on all the pending workflows and moves the request to Rejected stage.

Operation Initiated

After the request is approved, the request engine moves the request to the Operation Initiated stage and initiates the operation.

The following request statuses are associated with this stage:

  • Operation Completed

    After completing the actual requested operation, the request engine moves the request to the Operation Completed stage. This happens after Operation Initiated status and is associated with Completed stage.

  • Post Operation Processing Initiated

    After the actual requested operation is completed, if there exists any additional operation that needs to be executed as post-processing, the request engine moves the request to the Post Operation Processing Initiated stage, before initiating those operations. This happens after Operation Completed status.

Note: In case of a bulk operation, child requests are created after request level approval, and the parent request moves to the "Request Awaiting Child Requests Completion" status.

Request Failed

When the associated operations specified in the request fails to execute, the request cancels any pending operations and moves the request to the Request Failed stage.

The following request statuses are associated with this stage:

  • Request Failed

    When all associated operations specified in a request fail, the request is moved to the Request Failed stage.

  • Request Partially Failed

    When any associated operation specified in a request fails, the request is moved to the Request Partially Failed stage.

Request Withdrawn

A request can be withdrawn by the requester. At this stage, the request is associated to the Request Withdrawn status, and the initiation of all approvals are canceled.

Note:

  • A request can be withdrawn before Operation Initiated stage. After the request attains the Operation Initiated stage, the request cannot be withdrawn.

  • A request saved in draft mode cannot be withdrawn.

  • A request can always be withdrawn by a requester only, which is done by using Identity Self Service.

  • An administrator can close requests, which is similar to the withdraw function.

Request Closed

A request can be closed by the requester. At this stage, the request is associated to the Request Closed status, and the initiation of all approvals are canceled.

Note:

  • A request saved in draft mode cannot be closed.

  • An administrator can close requests, which is similar to the withdraw function.

Request Completed

After the execution of all operations specified in the request are completed, the request engine moves the request to the Request Completed stage.

The following request statuses are associated with this stage:

  • Request Completed with Errors

    A request attains this status, when an actual requested operation executes fine, but fails to execute any of the post-processing operations. The Request Completed with Errors stage is associated with the Failed stage.

  • Request Completed

    A request attains this status, when an actual requested operation executes fine without any errors.

  • Request Awaiting Completion

    When a request is scheduled to be executed on a future date, the request attains Request Awaiting Completion status till the operation is completed on an effective date.

The successful attainment of a stage also results in the status of the request being updated to the corresponding status.

Operations can be executed manually or automatically by the system in response to an event. Examples of manual operations are:

  • Save request as draft

  • Edit/update draft request

  • Submit request

  • Close/cancel (withdraw) request

  • Approve request when the service is notified that the approval workflow is successfully approved

Examples of automatic operations are:

  • Start approvals when the request is submitted

  • Execute request when the request is approved and execution date is in the future or not specified

4.1.3.2 Single Request Lifecycle

Any single or non-bulk request goes through a single level of approval. When the approval workflow is invoked, the request moves to the Request Awaiting Approval stage, and it moves to the Request Approved stage after approval, as shown in Figure 4-2.

Figure 4-2 Single Request Lifecycle

Description of Figure 4-2 follows
Description of "Figure 4-2 Single Request Lifecycle"
4.1.3.3 Bulk Request Lifecycle

The lifecycle of a bulk or parent request is similar to a single or non-bulk request, until the bulk request goes to the Request Approved stage. After that, it is split into child requests, and then it moves to the Request Awaiting Child Requests Completion status of the Operation initiated stage, as shown in Figure 4-3.

Figure 4-3 Bulk Request Lifecycle

Description of Figure 4-3 follows
Description of "Figure 4-3 Bulk Request Lifecycle"

Each child request goes through the lifecycle described in "Single Request Lifecycle". After the child requests are completed, the bulk or parent request moves to the Request Completed stage.

4.2 Configuring Approval Workflow Rules

Configuring approval workflow rules involve understanding workflow rules, rule conditions, and system-defined operations and rules; and creating approval workflow rules, configuring custom rule conditions, modifying approval workflow rules, deleting approval workflow rules, and understanding approval workflow rule evaluation.

This sections describes about configuring approval workflow rules in the following topics:

4.2.1 About Approval Workflow Rules

Approval workflow rules can be configured to determine whether an operation requires approval or not. In addition, if approval is required, then the rule also indicates which SOA workflow is to be initiated.

A list of operations and corresponding workflow rules are predefined in Oracle Identity Manager. These system-defined rules determine whether or not approvals are required and the SOA workflow to be initiated. All the non-bulk operations have pre-defined approval workflow rules configured.

For a list of supported operations and corresponding rules, see "About System-Defined Operations and Rules".

Note:

Oracle Identity Manager does not allow you to create new operations and corresponding rules. However, you can create and modify rules for the existing operations.

Approval workflow rules can be configured for all the supported operations, which are:

  • Self-Register User

  • Create User

  • Modify User

  • Disable User

  • Enable User

  • Delete User

  • Create Role

  • Modify Role

  • Delete Role

  • Assign Roles

  • Remove from Roles

  • Modify Role Grant

  • Provision Application Instance

  • Modify Account

  • Disable Account

  • Enable Account

  • Revoke Account

  • Provision Entitlement

  • Modify Entitlement

  • Revoke Entitlement

  • Heterogeneous Request

  • Bulk Modify User Profile

  • Bulk Disable User

  • Bulk Enable User

  • Bulk Delete User

  • Bulk Delete Role

  • Bulk Assign Roles

  • Bulk Remove from Roles

  • Bulk Provision Application Instance

  • Bulk Disable Account

  • Bulk Enable Account

  • Bulk Revoke Account

  • Bulk Provision Entitlement

  • Bulk Revoke Entitlement

4.2.2 About Rule Conditions

An approval workflow rule consists of rule condition and outcome.

An approval workflow rule consists of:

  • Condition: Rule condition based on the allowed inputs defined at the operation level

  • Outcome: Workflow ID, which is the SOA workflow ID to be initiated for the operation

The following is an example of an approval workflow rule for the Modify User operation:

Rule condition:

requester.adminroles CONTAINS OrclOIMUserAdmin

Rule Outcome:

Direct

Here, the rule condition checks if the requester is a member of the User Administrator admin role in the beneficiary's organization. If the condition is satisfied, then operation is performed without initiating any approval workflow.

The rule conditions vary from operation to operation. For example, user data is required along with requester data for a Create User operation, and role information and user data is required along with requester date for an Assign Role operation. Requester data is required for all operations. Oracle Identity System Administration enables you to enter the required role conditions based on the operation that you select.

Each approval workflow can have multiple rules associated with it, which must be defined in a certain order. For example, the Create User approval workflow can have rules, such as Create Contractor, Create Supplier, and Create Partner, defined in a sequence. The order in which the rules in an approval workflow are evaluated depends on the order or sequence in which the rules are defined in the policy.

See "About Custom Rule Conditions" for examples of rule conditions for each operation.

4.2.3 About System-Defined Operations and Rules

Each operation/workflow policy has a default rule, whose outcome is DIRECT. This means that if the default rule condition evaluates to true for an operation, then it is a direct operation without approvals.

Table 4-2 lists the system-defined operations and corresponding workflow rules, for which the outcome is DIRECT.

Note:

The rules in Table 4-2 are only for backward compatibility. You must remove these and create your own rules.

Table 4-2 Operations and Rules

Operation Rule Name Rule condition

Assign Roles

Assign Roles Default Rule

requester.adminroles CONTAINS OrclOIMRoleAuthorizer OR requester.adminroles CONTAINS OrclOIMUserAdmin OR requester.adminroles CONTAINS OrclOIMSystemAdministrator

Create Role

Create Role Default Rule

requester.adminroles CONTAINS OrclOIMRoleAdministrator OR requester.adminroles CONTAINS OrclOIMSystemAdministrator

Create User

Create User Default Rule

requester.adminroles CONTAINS OrclOIMUserAdmin OR requester.adminroles CONTAINS OrclOIMSystemAdministrator

Delete Role

Delete Role Default Rule

requester.adminroles CONTAINS OrclOIMRoleAdministrator OR requester.adminroles CONTAINS OrclOIMSystemAdministrator

Delete User

Delete User Default Rule

requester.adminroles CONTAINS OrclOIMUserAdmin OR requester.adminroles CONTAINS OrclOIMSystemAdministrator

Disable Account

Disable Account Default Rule

requester.adminroles CONTAINS OrclOIMApplicationInstanceAuthorizerRole OR requester.adminroles CONTAINS OrclOIMUserAdmin OR requester.adminroles CONTAINS OrclOIMSystemAdministrator

Disable User

Disable User Default Rule

requester.adminroles CONTAINS OrclOIMUserAdmin OR requester.adminroles CONTAINS OrclOIMSystemAdministrator

Enable Account

Enable Account Default Rule

requester.adminroles CONTAINS OrclOIMApplicationInstanceAuthorizerRole OR requester.adminroles CONTAINS OrclOIMUserAdmin OR requester.adminroles CONTAINS OrclOIMSystemAdministrator

Enable User

Enable User Default Rule

requester.adminroles CONTAINS OrclOIMUserAdmin OR requester.adminroles CONTAINS OrclOIMSystemAdministrator

Modify Account

Modify Account Default Rule

requester.adminroles CONTAINS OrclOIMApplicationInstanceAuthorizerRole OR requester.adminroles CONTAINS OrclOIMUserAdmin OR requester.adminroles CONTAINS OrclOIMSystemAdministrator

Modify Entitlement

Modify Entitlement Default Rule

requester.adminroles CONTAINS OrclOIMEntitlementAuthorizer OR requester.adminroles CONTAINS OrclOIMUserAdmin OR requester.adminroles CONTAINS OrclOIMSystemAdministrator

Modify Role

Modify Role Default Rule

requester.adminroles CONTAINS OrclOIMRoleAdministrator OR requester.adminroles CONTAINS OrclOIMSystemAdministrator

Modify User Profile

Modify User Profile Default Rule

requester.adminroles CONTAINS OrclOIMUserAdmin OR requester.adminroles CONTAINS OrclOIMSystemAdministrator

Provision Application Instance

Provision ApplicationInstance Default Rule

requester.adminroles CONTAINS OrclOIMApplicationInstanceAuthorizerRole OR requester.adminroles CONTAINS OrclOIMUserAdmin OR requester.adminroles CONTAINS OrclOIMSystemAdministrator

Provision Entitlement

Provision Entitlement Default Rule

requester.adminroles CONTAINS OrclOIMEntitlementAuthorizer OR requester.adminroles CONTAINS OrclOIMUserAdmin OR requester.adminroles CONTAINS OrclOIMSystemAdministrator

Remove from Roles

Remove from Roles Default Rule

requester.adminroles CONTAINS OrclOIMRoleAuthorizer OR requester.adminroles CONTAINS OrclOIMUserAdmin OR requester.adminroles CONTAINS OrclOIMSystemAdministrator

Revoke Account

Revoke Account Default Rule

requester.adminroles CONTAINS OrclOIMApplicationInstanceAuthorizerRole OR requester.adminroles CONTAINS OrclOIMUserAdmin OR requester.adminroles CONTAINS OrclOIMSystemAdministrator

Revoke Entitlement

Revoke Entitlement Default Rule

requester.adminroles CONTAINS OrclOIMEntitlementAuthorizer OR requester.adminroles CONTAINS OrclOIMUserAdmin OR requester.adminroles CONTAINS OrclOIMSystemAdministrator

Modify Role Grant

Modify Role Grant Default Rule

requester.adminroles CONTAINS OrclOIMRoleAuthorizer OR requester.adminroles CONTAINS OrclOIMUserAdmin OR requester.adminroles CONTAINS OrclOIMSystemAdministrator

In addition, there are a few other system-defined rules that support compliance use cases, which include role lifecycle, identity auditor, and certification, as listed in Table 4-3.

Table 4-3 Rules for Compliance Use Cases

Operation Rule Name Rule Condition Rule Outcome

Assign Roles

Assign Roles IdentityAuditorEnabled Rule

identityAuditEnabled EQUAL TRUE

Workflow

default/DefaultOperationalApproval!5.0

Create Role

Create Role IdentityAuditorEnabled Rule

identityAuditEnabled Equal TRUE

Workflow

default/RoleLCMApproval!1.0

Delete Role

Delete Role IdentityAuditorEnabled Rule

identityAuditEnabled Equal TRUE

Workflow

default/RoleLCMApproval!1.0

Disable User

Disable User Certification Rule

request.isCertification Equal true

Workflow

default/DefaultRequestApproval!6.0

Modify Role

Modify Role IdentityAuditorEnabled Rule

identityAuditEnabled Equal TRUE

Workflow

default/RoleLCMApproval!1.0

Remove from Roles

Remove from Roles IdentityAuditorEnabled Rule

identityAuditEnabled Equal TRUE

Workflow

default/DefaultOperationalApproval!5.0

Remove from Roles

Remove from Roles Certification Rule

request.isCertification Equal TRUE

Workflow

default/DefaultRequestApproval!6.0

Revoke Account

Revoke Account Certification Rule

request.isCertification Equal TRUE

Workflow

default/DefaultRequestApproval!6.0

Revoke Entitlement

Revoke Entitlement Certification Rule

request.isCertification Equal TRUE

Workflow

default/DefaultRequestApproval!6.0

Modify Role Grant

Modify Role Grant IdentityAuditorEnabled Rule

identityAuditEnabled EQUAL TRUE

Workflow

default/DefaultOperationalApproval!5.0

See Also:

Table 4-4 for information about the request.isCertification and identityAuditorEnabled conditions.

Note:

The workflow rules listed in Table 4-3 are configured ahead (in terms of order) of the default rules listed in Table 4-2. Therefore, these rules would be evaluated before the default rules. See "About Approval Workflow Rule Evaluation" for more information about workflow rule evaluation.

For example, the Assign Roles operation has two rules configured by default in the following order:

  1. Assign Roles IdentityAuditorEnabled Rule

  2. Assign Roles Default Rule

To determine the approval workflow to be initiated for an Assign Roles operation, the Assign Roles IdentityAuditorEnabled Rule rule is evaluated first. If the rule does not match (evaluates to true), then Assign Roles Default Rule is evaluated.

4.2.4 Creating Approval Workflow Rules

Approval workflow rules are configured to determine whether an operation requires approval or not. In addition, if approval is required, then the rule also indicates which SOA workflow is to be initiated.

To create an approval workflow rule:

  1. Login to Oracle Identity System Administration.

  2. On the left navigation pane, under Workflows, click Approval. The Approval Workflow Configuration page is displayed.

  3. In the Select an Operation to configure rules section, select an operation to configure rules for the operation. The rules associated with the operation are displayed in the Rules section at the bottom of the page. This section displays the rule name, rule description, and the workflow associated with the operation.

    In the Rules section, you can create a new rule, or select an existing rule and update or delete it.

    Note:

    When multiple rule conditions are specified in an approval workflow policy, the order in which rules are evaluated is based on the order in which they are configured in the policy. The order cannot be changed after the rules have been created. Therefore, the rules must be created in the order in which you want them to be evaluated.

  4. In the Rules section, click Create. The Create Rule page is displayed.

  5. In the Name box, enter a name for of the rule. This is a mandatory field.

  6. In the Description box, enter a description for the rule.

  7. In the Owner box, specify a owner of the rule. To do so, click the search icon adjacent to the Owner field, and then search and select a owner.

  8. From the Status list, select a status for the rule. By default, the rule is in Enabled status.

  9. In the Condition Builder section, specify the rule conditions in the IF and THEN clauses. To do so, perform the following steps to create a sample rule condition in which if the user is a member of the Top organization, then the Create User operation will be auto-approved:

    1. Under the IF clause, in the first field of the empty row, to specify an object and attribute, click the search icon adjacent to the field. The Condition Builder dialog box is displayed.

      Note:

      If you are aware of the exact object and attribute name, then you can enter the condition in the first field, for example requester.Organization Name, instead of clicking the search icon.

    2. Click requester because you want to specify the condition based on requester data. A list of attributes is displayed that you can specify for the requester object. You can navigate through the attributes by clicking the page number icons and select it. Otherwise, enter the attribute name in the search field and click the search icon.

      Note:

      From any screen of the Condition Builder dialog box, you can click Start to come back to the first screen in which you can start specifying a fresh condition by selecting the object.

    3. Click the Organization Name attribute. The condition requester.Organization Name is displayed in the Condition Builder dialog box.

    4. Click OK. The condition is added to the first field in the IF clause.

    5. From the Operator list, select Equal.

      The following operators are available for selection:

      • EQUAL

      • NOT_EQUAL

      • CONTAINS

      • DOES_NOT_CONTAIN

      • BEGINS_WITH

      • DOES_NOT_BEGIN_WITH

      • ENDS_WITH

      • DOES_NOT_END_WITH

    6. To specify the value in the field on the right side, click the search icon. The Condition Builder dialog box is displayed.

      Note:

      If you are aware of the exact value, then you can enter the value, for example Top, instead of clicking the search icon.

    7. Select any one of the following options:

      • Value: To specify the value of an attribute.

      • Expression: To specify the condition based on an expression.

      For the purpose of this example, select the Value option. The values for the Organization Name attribute are listed. This is because the object and attribute specified in the rule is requester.Organization Name.

    8. Click Top. The Top organization is selected.

    9. Click OK. The Top organization is populated in the value field.

    10. To add another condition, click Add Condition. Another row is added under the IF clause. From the operator list on the right, you can select the AND or OR operator, and enter another rule condition as described in steps a through i.

      To remove a row, you can select the check box to the left of the row, and click Remove.

    11. If you have added multiple rule conditions, then you can group the conditions together. To do so, select the check boxes to the left of the conditions, and click Group. Similarly, to remove the grouping of the conditions, select the check boxes to the left of the conditions, and click Ungroup.

      Note:

      • You can group only two conditions at a time. If you select more than two conditions, then the Group button is disabled. Alternatively, the Ungroup button is enabled only when you select one of the conditions that is grouped, but it is disabled when you select more than one group.

      • A maximum of two conditions can be grouped together. Therefore, if you create a rule with four conditions that are grouped together with the AND operator, then the conditions are grouped into two sets. But if one of the conditions are grouped with the OR operator, then rule is updated correctly.

    12. In the THEN clause, click the search icon adjacent to the first field to open the Condition Builder dialog box.

    13. Select workflow and click OK.

    14. In the value field for workflow, select AutoApproval!1.0. The request will be auto-approved if you select this workflow.

    15. Click OK. The workflow value is populated in the value field.

      Therefore, the rule condition you specified is the following:

      IF
      requester.Organization Name EQUALS Top
      
      THEN
      workflow default/AutoApproval!1.0
      
  10. Click Create to create the rule condition. The rule condition is displayed in the table when you select the Operation for which it is created.

    Note:

    • When Risk attributes are used to define the conditions in a rule, for the rule to be evaluated correctly, the Risk Aggregation Job scheduled job must be run before the request is made.

    • For application instances, there is no mechanism to filter out the attributes. All the attributes for application instances are displayed in the Condition Builder with which a rule can be written. For roles, select the role name to display the list of attributes for the role entities. You can select the asterisk (*) wildcard character to display the list of attributes.

See "About Custom Rule Conditions" for examples of rule conditions for each workflow operation.

Note:

In this release, while creating a workflow rule, use User Type instead of Role. For example, in the following rule condition, user.User Type is used instead of user.Role:
IF user.User Type=Contractor
THEN capability=selfModifyUser

4.2.5 About Custom Rule Conditions

Custom rule conditions have a syntax that consist of operation and the corresponding top-level attribute for the condition.

Table 4-4 describes how to specify custom rule conditions with examples.

Table 4-4 Approval Workflow Rule Syntax and Examples

Operation Top-Level Attribute for Condition Creating Workflow Rule Conditions (based on top-level attribute)

All operations including bulk

operation

This refers to the operation being performed currently, for example:

operation EQUALS Create User

Note: Such a condition can be used where the desired outcome is always true.

All operations including bulk and excluding self-register user

requester

This refers to the user profile attributes, roles, and admin role memberships of all the requesters. For example:

requester.Email CONTAINS @example.com
requester.adminRoles CONTAINS OrclOIMUserAdmin

This condition means if requester's email ID contains example.com, and requester is a member of OrclOIMUserAdmin admin role.

Create User

user

This refers to all the user entity attributes, which can be specified by the requester while creating a user. For example:

user.Last Name EQUALS Doe

Modify User

user

This refers to all the user entity attributes of the user being modified, which can be specified by the requester while modifying a user. For example:

user.Organization EQUALS Marketing

Disable User, Enable User, Delete User

user

This refers to all the user attributes of the user being disabled, enabled, or deleted, which are currently set in the user's profile. For example:

existingUser.Organization EQUALS Marketing

Disable User, Enable User, Delete User

request

This refers to the request metadata, and the only allowed subattribute is isCertification. The only allowed values are true and false, which must be entered manually. This can be used to check if the current operation/request is a certification request. For example:

request.isCertification EQUAL true

Note: request.isCertification is used within default rules. It is not recommended to create custom conditions using request.isCertification.

Create Role

role

This refers to all the role entity attributes, which can be specified while creating a role. For example:

role.Name EQUALS ITAdmin

Because catalog metadata attributes can also be specified while creating the role, conditions are allowed based on catalog metadata attributes as well. For example:

role.catalog.Category EQUAL Role

Create Role

identityAuditEnabled

This can be used to create condition based on the value of the OIG.IsIdentityAuditorEnabled system property. The only allowed values are TRUE and FALSE, which must be entered manually. For example:

identityAuditEnabled EQUALS TRUE

Note: identityAuditEnabled is used within default rules. It is not recommended to create custom conditions using identityAuditEnabled.

Modify Role

role

This refers to all the role entity attributes, which can be specified while modifying a role. For example:

role.Name EQUAL ITAdmin

Because catalog metadata attributes can also be specified while modifying the role, conditions are allowed based on catalog metadata attributes as well. For example:

role.catalog.Category EQUAL Role

Modify Role

existingRole

This refers to all the role entity attributes, which are currently set for the role being modified. For example:

existingRole.DisplayName EQUALS IT Administrator

Because catalog metadata attributes can also be specified while modifying the role, conditions are allowed based on catalog metadata attributes as well. For example:

role.catalog.Category EQUAL Role

Modify Role

identityAuditEnabled

This can be used to create condition based on the value of the OIG.IsIdentityAuditorEnabled system property. The only allowed values are TRUE and FALSE, which must be entered manually. For example:

identityAuditEnabled EQUALS TRUE

Note: identityAuditEnabled is used within default rules. It is not recommended to create custom conditions using identityAuditEnabled.

Delete Role

existingRole

This refers to all role entity attributes, which are currently set for the role being deleted. For example:

existingRole.DisplayName EQUALS IT Administrator

Delete Role

identityAuditEnabled

This can be used to create condition based on the value of the OIG.IsIdentityAuditorEnabled system property. The only allowed values are TRUE and FALSE, which must be entered manually. For example:

identityAuditEnabled EQUALS TRUE

Note: identityAuditEnabled is used within default rules. It is not recommended to create custom conditions using identityAuditEnabled.

Assign Roles, Remove from Roles

user

This refers to all user attributes, which are currently set in the profile for the user/beneficiary who is being assigned a role or whose role membership is being revoked. For example:

user.Organization EQUALS Marketing

Assign Roles, Remove from Roles

role

This refers to all attributes of the role, which is being assigned ro or revoked from a user. For example:

role.name EQUAL IT Administrator

Assign Roles, Remove from Roles

catalogItem

This refers to catalog metadata attributes corresponding to the role for which the access request is being submitted. For example:

catalogItem.Category EQUAL Role

Assign Roles, Remove from Roles

identityAuditEnabled

This can be used to create condition based on the value of the OIG.IsIdentityAuditorEnabled system property. The only allowed values are TRUE and FALSE, which must be entered manually. For example:

identityAuditEnabled EQUALS TRUE

Note: identityAuditEnabled is used within default rules. It is not recommended to create custom conditions using identityAuditEnabled.

Assign Roles, Remove from Roles

request

This refers to the request metadata, and the only allowed sub-attribute is isCertification. The only allowed values are true and false, which must be entered manually. This can be used to check if the current operation/request is a certification request. For example:

request.isCertification EQUAL true

Note: request.isCertification is used within default rules. It is not recommended to create custom conditions using request.isCertification.

Modify Role Grant

user

This refers to user attributes, which are currently set in the profile for the user/beneficiary whose role membership is being modified. For example:

user.Organization EQUALS Marketing

Modify Role Grant

role

This refers to attributes of the role whose membership is being modified. For example:

role.name EQUALS IT Administrator

Modify Role Grant

catalogItem

This refers to catalog metadata attributes corresponding to the role for which the access request is being submitted. For example:

catalogItem.Category EQUAL Role

Modify Role Grant

identityAuditEnabled

This can be used to create condition based on the value of the OIG.IsIdentityAuditorEnabled system property. The only allowed values are TRUE and FALSE, which must be entered manually. For example:

identityAuditEnabled EQUALS TRUE

Note: identityAuditEnabled is used within default rules. It is not recommended to create custom conditions using identityAuditEnabled.

Provision ApplicationInstance

user

This refers to the user profile attributes of the user/beneficiary to whom the account is being provisioned. For example:

user.Organization EQUALS Marketing

Provision ApplicationInstance

appType

This refers to the account which is being provisioned to a user/beneficiary.

appType is a top-level attribute that can lead to a hierarchy of sub-attributes, such as appInstance, followed by account, and optionally followed by account-specific child tables or entitlements. Further, account can be followed by the parent form attributes, and child table or entitlement can be followed by their specific attributes.

Example 1:

appType[AD User].appInstance[VisionEmployeesDomain].account[*].Organization Name EQUAL Marketing

This condition means that if an account is being created in the VisionEmployeesDomain appInstance within the Marketing organization.

Note: Workflow rule evaluation only considers the account that is being requested and does not consider any of the existing accounts that the user/beneficiary might have.

Example 2:

appType[AD User].appInstance[*].account[*].Organization Name EQUAL Marketing

This condition means that if an account is being created in any appInstance pertaining to the AD User target within the Marketing organization.

Provision ApplicationInstance

catalogItem

This refers to catalog metadata attributes set in the catalog item for which the access request is being submitted, for example catalogItem.

Modify Account

user

This refers to user profile attributes of the user/beneficiary whose account is being modified. For example:

user.Organization EQUALS Marketing

Modify Account

appType

This refers to the account information that is being modified as part of this operation. For example:

existingAppType[AD User].appInstance[*].account[*].Organization Name EQUAL Manufacturing

This condition means that if the user account on any of the AD User targets is being transferred to the Manufacturing organization.

Modify Account

existingAppType

This refers to current or existing user account information, which is being modified as part of this operation. For example:

appType[AD User].appInstance[*].account[*].Organization Name EQUAL Marketing

This condition means that if the user account on any of the AD User targets is being transferred from the Marketing organization to some other organization.

Note: Workflow rule evaluation only considers the account that is being modified and does not consider any of the existing accounts that the user/beneficiary might have.

Modify Account

catalogItem

This refers to the catalog metadata attributes set in the catalog item for which the access request is being submitted. For example:

catalogItem.Category EQUALS Role

Enable Account, Disable Account, Revoke Account

user

This refers to the user profile attributes of the user/beneficiary whose account is being enabled/disabled/revoked. For example:

user.Organization EQUALS Marketing

Enable Account, Disable Account, Revoke Account

existingAppType

This refers to current or existing user account information, which is being disabled/enabled/revoked as part of this operation. For example:

existingAppType[AD User].appInstance[*].account[*].Organization Name EQUAL Marketing

This condition means that if the user account being disabled/enabled/revoked belongs to the Marketing Organization of any of the AD User targets.

Note: Workflow rule evaluation only considers the account which is being disabled/enabled/revoked and does not consider any of the existing accounts that the user/beneficiary might have.

Enable Account, Disable Account, Revoke Account

catalogItem

This refers to catalog metadata attributes set in the catalog item for which the access request is being submitted, for example catalogItem.

Enable Account, Disable Account, Revoke Account

request

This refers to the request metadata, and the only allowed sub-attribute is isCertification. The only allowed values are true and false, which must be entered manually. This can be used to check if the current operation/request is a certification request. For example:

request.isCertification EQUAL true

Note: request.isCertification is used within default rules. It is not recommended to create custom conditions using request.isCertification.

Provision Entitlement

user

This refers to user profile attributes of the user/beneficiary to whom the entitlement is being provisioned. For example:

user.Organization EQUALS Marketing

Provision Entitlement

appType

This refers to the entitlement information or the data that is being specified while performing the operation. For example:

appType[AD User].appInstance[VisionEmployeesDomain].account [*].UD_ADUSRC[*].Group Name EQUAL PasswordPolicyAdminGrp

This condition means that if the PasswordPolicyAdminGrp entitlement is being granted to the user/beneficiary on VisionEmployeesDomain application instance.

Provision Entitlement

catalogItem

This refers to the catalog metadata attributes set in the catalog item for which the access request is being submitted, for example, catalogItem.

Modify Entitlement

user

This refers to the user profile attributes of the user/beneficiary whose entitlement grant is being modified. For example:

user.Organization EQUALS Marketing

Modify Entitlement

appType

This refers to the entitlement information or the data that is being specified while performing the operation. For example:

appType[AD User].appInstance[VisionEmployeesDomain].account [*].UD_ADUSRC[*].Group Name EQUAL PasswordPolicyAdminGrp

This condition means that if PasswordPolicyAdminGrp entitlement grant is being modified for the user/beneficiary on VisionEmployeesDomain application instance.

Modify Entitlement

existingAppType

This refers to the entitlement information or the existing entitlement form data, such as start date and end date. For example:

existingAppType[AD User].appInstance[VisionEmployeesDomain].account [*].UD_ADUSRC[*].Group Name EQUAL PasswordPolicyAdminGrp

This condition means that if PasswordPolicyAdminGrp entitlement grant is being modified for the user/beneficiary on VisionEmployeesDomain application instance.

Modify Entitlement

catalogItem

This refers to the catalog metadata attributes set in the catalog item for which the access request is being submitted, for example catalogItem.

Revoke Entitlement

user

User profile attributes of the user/beneficiary whose entitlement grant is being revoked. For example:

user.Organization EQUALS Marketing

Revoke Entitlement

existingAppType

This refers to the entitlement information or the existing entitlement form data, such as start date and end date. For example:

existingAppType[AD User].appInstance[VisionEmployeesDomain].account [*].UD_ADUSRC[*].Group Name EQUAL PasswordPolicyAdminGrp

This condition means that if PasswordPolicyAdminGrp entitlement grant is being modified for the user/beneficiary on VisionEmployeesDomain application instance.

Revoke Entitlement

catalogItem

This refers to the catalog metadata attributes set in the catalog item for which the access request is being submitted, for example catalogItem.

Revoke Entitlement

request

This refers to the request metadata, and the only allowed sub-attribute is isCertification. The only allowed values are true and false, which must be entered manually. This can be used to check if the current operation/request is a certification request. For example:

request.isCertification EQUAL true

Note: request.isCertification is used within default rules.It is not recommended to create custom conditions using request.isCertification.

4.2.6 Modifying Approval Workflow Rules

You can modify workflow rules to add, modify, or remove the rule conditions.

To modify the workflow rule that you added in "Creating Approval Workflow Rules":

  1. On the left navigation pane of Identity System Administration, under Workflows, click Approval. The Approval Workflow Configuration page is displayed.

  2. In the Operation section, select an operation to configure rules for the operation.

  3. In the Rules section, click Edit. The Edit Rule page is displayed.

  4. In the Operation section, search and select the operation for which you want to modify the workflow rule. For the purpose of this example, select Create User. The rules for the Create User operation is displayed in a table in the Rules section.

  5. In the Rules section, select the rule that you want to edit, and click Edit. The Edit Rule page is displayed.

  6. If you want to modify any rule attribute, then update the attribute values in the Edit Rule section.

  7. In the Condition Builder section, you can modify an existing rule by modifying the object, attribute, or value fields. You can also add conditions to the existing ones, or remove rule conditions. Perform the following steps to add a rule condition that specifies that if the requester has the UserHelpDesk admin role, then the target user manager's approval is required for the Create User Operation:

    1. In the Condition Builder section, click Add Condition. A new row is added.

    2. From the operators list on the right, select OR.

    3. In the first field of the row, specify requester.adminRole by using the Condition Builder dialog box. See step 10 of "Creating Approval Workflow Rules" for information about selecting values in the Condition Builder dialog box.

    4. From the operators list, select CONTAINS.

    5. In the value field, select OrclOIMUserHelpDesk by using the Condition Builder dialog box.

    6. In the THEN section, specify workflow and default/BeneficiaryManagerApproval!4.0 in the two fields respectively. Therefore, the complete rule condition is:

      IF
      requester.adminRoles CONTAINS OrclOIMUserHelpDesk
      
      THEN
      workflow default/BeneficiaryManagerApproval!4.0
      

      This rule condition will ensure that if the requester has the UserHelpDesk admin role, then the target user manager's approval is required for creating the user.

  8. Click Update. The workflow rule is updated with the new rule condition.

  9. To remove a rule condition, select the check box to the left of the rule condition row, and click Remove. Then, click Update.

4.2.7 Deleting Approval Workflow Rules

You can delete the workflow rules that you define for all the operations. However, it is recommended that the default rules are not deleted.

To delete a workflow rule:

  1. On the left navigation pane of Identity System Administration, under Workflows, click Approval. The Approval Workflow Configuration page is displayed.
  2. In the Operation section, select an operation whose workflow rule you want to delete.
  3. In the Rules section, click Delete. A message box is displayed asking for confirmation.
  4. Click Yes.

4.2.8 About Approval Workflow Rule Evaluation

Understand the approval workflow rule evaluation for bulk and non-bulk operations.

When an operation (bulk or non-bulk) is being performed, approval workflow rule evaluation takes place in the following way:

  1. The approval workflow rules associated with the operation being performed are evaluated one by one, in the order in which they are configured.

  2. Rule evaluation stops, and the outcome, which is workflowID or Direct, of the matched rule is returned.

    Approval workflow rule evaluation stops at the first matching rule, which is the rule that evaluates to true, and that rule's outcome is returned as the result.

  3. For a Bulk operation, if none of the rules match, then the SOA composite configured in defaultRequestApprovalComposite of SOAConfig is returned implicitly.

  4. For a non-bulk operation, if none of the rules match, then the SOA composite configured in defaultOperationApprovalComposite of SOAConfig is returned implicitly.

If the approval workflow rule evaluation returns a WorkflowID, for example UserManagerApproval, then a request is created and the corresponding ASYNC orchestration is initiated. As part of the orchestration, there is a possibility that some of the data submitted by the user is modified or added. As a result, a different workflow ID than UserManagerApproval might be applicable. To handle such scenarios, approval workflow rules are re-evaluated before the workflow is initiated. If the re-evaluation results in a different workflowID, for example HRManagerApproval, then HRManagerApproval is initiated.

4.3 Managing Request Approval in an Upgraded Deployment of Oracle Identity Governance

Managing request approvals in an upgraded deployment involves understanding request approval process in an upgraded deployment, request process flow with disabled workflow rules, migrating approval policies, and enabling workflow rules.

This section describes about managing request approvals in an upgraded deployment of Oracle Identity Governance in the following topics:

4.3.1 About Request Approval in an Upgraded Deployment of Oracle Identity Governance

In an upgraded deployment of Oracle Identity Manager, the approval workflow rules feature is disabled by default.

As a result, the following occurs when an operation is initiated:

  • Authorization policies and admin role assignments determines whether or not an operation requires approval, as described in Request vs. Direct Operation in the User’s Guide for Oracle Identity Manager.

  • Approval policies are functional and determines which SOA workflow is to be invoked if approval is required.

  • There are two levels of approval, and the functionality is as described in Managing Requests of User's Guide for Oracle Identity Manager for 11g Release 2 (11.1.2.2).

  • If you enable workflow policies, then request generation and approval takes place in the same manner as in a fresh deployment of Oracle Identity Manager. However, you must migrate approval policies to workflow policies, as described in "Migrating Approval Policies to Approval Workflow Rules".

    Note:

    After enabling workflow policies, you must not disable it again. Toggling between enabling and disabling workflows is not supported.

Most of the approval policy features can be achieved by using approval workflows. Table 4-5 lists the approval policy features that can be achieved by using approval workflows.

Table 4-5 Approval Policies to Approval Workflows

Approval policies Approval workflow rules

Approval policies for a request type

Approval workflow rule specific to an operation

Approval policy level, which consists of request level and operation level

Single level of approval

Scope type, scope

Approval workflow rule condition

Approval process configuration: auto approval

Approval workflow rule configuration: Select Direct

Approval process configuration: approval process

Workflow rule configuration: Search and select workflow

Approval policy rule

Approval workflow rule condition

Heterogeneous request type

Heterogeneous request policy

Bulk request type

Bulk policy for operation, for example Create User Bulk

Request level approval policies

Approval workflow rules

Operation level approval policy

NA

Priority

Policy order, in which the policies are configured

Hierarchical organization scoping

Policy condition based on organization hierarchy, for example:

user.Organization="VisionMarketing" OR user.parentOrganization="Vision" OR ...

4.3.2 About Request Process Flow With Approval Workflow Rules Disabled

In an upgraded deployment of Oracle Identity Manager, approval workflows is disabled by default.

Figure 4-4 shows the request process flow when approval workflows is disabled.

Figure 4-4 Request Process Flow with DIsabled Workflow

Description of Figure 4-4 follows
Description of "Figure 4-4 Request Process Flow with DIsabled Workflow"

When approval workflow rules feature is disabled, the ApprovalRequired obligation(s) returned as a result of authorization policy evaluation determine whether the operation requires approval(s) or not.

If ApprovalRequired is false, then no request is created, and it is a direct operation.

If ApprovalRequired is true, then a request is created, approval policies are evaluated, and the SOA workflow returned by approval policy evaluation is initiated.

4.3.3 Migrating Approval Policies to Approval Workflow Rules

By default, a single workflow policy is available for an operation, whereas, an operation or request type can have multiple approval policies configured at request level and operation level.

To migrate approval policies to approval workflow rules:

  1. Identify all the approval policies that are applicable to a request type. Because there can be policies at request level and operation level, some manual analysis is required to identify their priority or order.

    An operation or request type can have multiple approval policies configured at request level and operation level. Whereas, by default, there is only a single approval workflow policy available for an operation. This default approval workflow policy cannot be deleted; new rules can be added to the same.

  2. Pick the approval policy that comes first or next in the order of priority.

  3. Open the default approval policy configuration specific to the request type. If there is a requirement to modify the current approval policy as a bulk workflow policy rule, then open the default bulk policy, for example Bulk Modify User.

  4. Model the current approval policy as an approval workflow rule as follows:

    1. Create a new approval workflow rule with the same name as the approval policy name picked in step 2. Provide a description for the approval workflow rule.

      See Also:

      "Creating Approval Workflow Rules" and "Modifying Approval Workflow Rules" for information about the user interface to work with approval workflow rules

    2. In the Approval Workflow Configuration page of Oracle Identity System Administration, search and select the workflow that is configured in the approval policy as approval process.

    3. Model the approval policy rule as approval workflow rule condition in the Approval Workflow Configuration page.

  5. Repeat steps 2 through 4 for all the approval policies applicable to a request type.

  6. Repeat steps 1 through 5 for all the request types.

4.3.4 Enabling Approval Workflow Rules

Enabling approval workflow rules in an upgraded deployment involves enabling the workflow rules feature and understanding the in-flight rquest lifecycle.

This section contains the following topics:

4.3.4.1 Enabling the Approval Workflow Rules Feature

In an upgraded deployment of Oracle Identity Manager, the approval workflow rules feature is disabled by default. To enable the feature:

  1. Ensure that SOA is enabled. To do so, verify that the value of the Workflows Enabled system property is true.
  2. Ensure that migration of approval policies to approval workflows, as described in "Migrating Approval Policies to Approval Workflow Rules", has been completed.
  3. Set the value of the Workflow Policies Enabled system property to true.
  4. Restart Oracle Identity Manager Managed Server.
4.3.4.2 About In-Flight Request Lifecycle

When you upgrade Oracle Identity Governance to 19c (19.1.0.0.0), there can be some in-flight requests that must be processed after the upgrade. After the approval workflow policies feature is enabled, the life cycle of all the in-flight requests are the same as in the earlier release of Oracle Identity Manager, except for workflow determination. SOA workflow to be initiated is determined based on the workflow policies and not approval policies. In-flight request go through the existing request stages, which are Obtaining Request Approval, Obtaining Operation Approval, Request Approval Approved, Operation Approval Approved, Request Approval Rejected, and Operation Approval Rejected.

After enabling approval workflows, the in-flight requests are processed in the following manner:

For In-Flight Requests Awaiting Request Approval

Figure 4-5 shows the lifecycle of in-flight requests that are awaiting request approval.

Figure 4-5 In-Flight Requests Awaiting Request Approval

Description of Figure 4-5 follows
Description of "Figure 4-5 In-Flight Requests Awaiting Request Approval"

If the request is approved, then approval workflow rule is evaluated to determine the SOA workflow to be initiated at operation level. The request moves to the Obtaining Operation Approval stage.

If the request is rejected, then the request moves to Request Approval Rejected stage.

For In-Flight Requests Awaiting Operation Approval

Figure 4-6 shows the lifecycle of in-flight requests that are awaiting operation approval.

Figure 4-6 In-Flight Requests Awaiting Operation Approval

Description of Figure 4-6 follows
Description of "Figure 4-6 In-Flight Requests Awaiting Operation Approval"

If the request is approved, then the operation is initiated.

If the request is rejected, then the request moves to the Operation Approval Rejected stage.

4.4 Migrating Workflow Rules From Test to Production

You can migrate workflow rules from a test environment to a production environment.

This section contains the following topics:

4.4.1 About Migration of Workflow Rules From Test to Production

Workflow rules can be exported from the source environment, such as test environment, and imported to the target environment, such as production environment, by using the Deployment Manager.

Migration of workflow rules and rule to operation/policy relationships come under the category of Policy in the Deployment Manager Wizard. See "Migrating Incrementally Using the Deployment Manager" for information about the Deployment Manager.

As workflow rules are associated with a specific operation, you must select the operation first, and then select the rules that you want to export.

While exporting/importing workflow rules, the workflow rule configuration in the source environment overrides the workflow rule configuration in the target environment. As a result, when workflow rules for an operation are imported, all rules configured for that operation are deleted, and the exported rules are associated with that operation in the target environment. In addition, the order of the rules in the source environment are carried over to the target environment.

For example, consider that the Create User operation has rules Rule1 and Rule2 configured in the target environment. But the Create User operation on the source environment has rules Rule1 and Rule3, and both are exported. When these rules are imported to the target environment, Rule1 and Rule2 are deleted, and Rule1 and Rule3 are associated with the Create User operation.

Therefore, it is recommended to maintain the source/test environment as the source of truth for workflow rule configuration.

4.4.2 Moving Workflow Rules From Test to Production Using the Deployment Manager

Use the Deployment Manager to export the operations and policies and import them to the target environment.

To export/import the workflow rules by using the Deployment Manager:

  1. Login to Oracle Identity System Administration of the source/test environment as the system administrator.
  2. On the left pane, under System Configuration, click Export. The Export Configuration page opens and the Search Objects option is displayed.
  3. From the Search Objects page, select Type as Policy and click Search icon. Search result is displayed in the Available Entities table.
  4. From the Available Entities table, select the check box against the policy you want to export the workflow rules. The Policy is moved to the Selected Entities table.
  5. Click Next or click Export Options in the train link. The Export Options page is displayed.
  6. Set Dependency to Yes, select the workflow rules for the selected operations that you want to export.
  7. Continue with the remaining steps of the wizard and complete the export.
  8. Login to Oracle Identity System Administration of the target/production environment as the system administrator.
  9. On the left pane, under System Configuration, click Import.
  10. Select the file that contains the exported workflow rules (from step 7), and complete the import process. For detailed steps see, Importing Deployments

Note:

A workflow rule condition can refer to entities, such as role or application instance. Such dependent entities cannot be migrated as part of workflow rule migration. You must manually configure or migrate such dependent entities in the target/production environment. Otherwise, rule evaluation result might be unpredictable.

4.5 Running Oracle Identity Governance Without Workflows

Oracle Identity Manager is dependent on SOA server, which is installed and enabled by default. However, you can manually disable workflows by disabling SOA as a post install configuration step.

This chapter describes the procedure to disable SOA and the functional impact of doing so in the following sections:

4.5.1 Disabling SOA Server

You can disable the SOA server by setting the value of the Workflows Enabled system property.

To disable SOA Server:

  1. Shutdown the SOA Managed Server.
  2. Set the value of the Workflows Enabled system property to false. See Table 18-1 for information about this system property.
  3. Restart Oracle Identity Manager Managed Server.

SOA Server can be re-enabled by setting the value of the Workflows Enabled system property to true.

Note:

Oracle recommends that you do not enable SOA again after disabling it. Toggling between enabling and disabling workflows is not supported.

4.5.2 About the Impact of Disabling Workflows

The primary functional impact of disabling workflow is that all operations are auto-approved, which means that the operations are completed without any approvals. Because no approval workflows are initiated, neither approval policies nor approval workflow rules are evaluated.

Figure 4-7shows the impact of disabling workflows.

In addition, Table 4-6 lists the features that are not available when workflow is disabled.

Table 4-6 Unavailable Features When Workflow is Disabled

Feature Details

Request approvals

  • All the operations performed are direct operations and a request is not created, with the following exceptions:

    • Request is always created for bulk operations. Child requests are created immediately, which are auto-approved.

    • Request is always created for all operations with future effective date.

    All the newly created requests are auto-approved without involving any human approval. For example, all add access, self profile modification, and account/entitlement modification requests, are direct operations.

  • Approval policies or workflow rules are not evaluated. See "About Rule Conditions" for information about workflow rules.

Provisioning operations

  • Disconnected application instance: Manual fulfillment tasks for disconnected application instances do not work when workflow is turned off. Provisioning operations for disconnected application instances will fail.

  • Account-entitlement dependency: Entitlement request with one beneficiary when workflow is turned off works in the following way:

    • Selected user has one account: The account is preselected, and there is no impact.

    • Selected user has multiple accounts: It is mandatory to select an account, and there is no impact.

    • Selected user has no account: Application instance automatically gets added to the cart and a bulk request is created. As SOA is turned off, bulk and child requests will be auto-approved.

    • Selected user has a pending account request: Newly created entitlement request is set as dependent on the account request. If the account is pending for approval, then as SOA is turned off, the requests are not processed further. If account request is waiting for an effective date, then the entitlement request is processed after the account request is completed.

    Entitlement request with multiple beneficiaries when SOA is turned off results in bulk request. The bulk request is auto-approved and child requests are created. The following are some specific use cases:

    • User has one account: entitlement request: This is auto-approved and completed.

    • User has multiple accounts: Corresponding entitlement child requests will fail.

    • User has no account: Corresponding entitlement child requests will fail.

    • User has pending account request: Entitlement child request is set as dependent on the account request. If the account is pending for approval, then as SOA is turned off, the requests are not processed further. If account request is waiting for an effective date, then entitlement request is processed after the account request is completed.

    The following account -entitlement use cases that rely on SOA composites will fail:

    • A multiple beneficiary request for entitlement where one or more beneficiaries have no account, and there is no in-flight account request (for that beneficiary and application instance combination).

    • A multiple beneficiary request for entitlement where one or more beneficiaries have multiple accounts, and account is not identified.

Identity Auditor features

When workflow is turned off, Certification and Identity Auditor features do not work, and the UI links related to Certification and Audit Compliance are not displayed in both Identity Self service and Identity System Administration. This is true when the value of the Identity Auditor Feature Set Availability system property is set to TRUE.

When workflow is turned off, any certification-related scheduled job will not be run, and appropriate messages will be logged.

UMS notification

UMS notification provider works depending on whether workflows are enabled or not. UMS provider does not send notifications when SOA is not available. If UMS provider is kept enabled when SOA is not available, then UMS does not attempt to send notifications and logs an error message. An alternate provider, for example, the EmailServiceProvider must be configured and enabled to continue sending notifications.

Web services connector

Web services connector does not work when SOA is disabled.

SIL-based SoD

SIL-based SoD check do not happen when workflows are disabled even when the operation results in a request. However, SIL-based SoD Checks continue to work at the provisioning level when SOA is unavailable.

User management

  • User self-registration: User self-registration continue to work when SOA is turned off. Organization is calculated through the home organization determination policy, and the self registration request is auto approved.

  • Proxy user management: The proxy feature is disabled when SOA is turned off. The panel for managing proxies in the Identity Self Service is not displayed, and all the APIs around proxy throws an exception with the following message:

    Proxy functionality is only supported when SOA and workflows are enabled.
    

User interface

The following features are disabled (and not displayed) in the default user interface when the Workflows Enabled system property is set to false:

  • In Oracle Identity System Administration: The Approval Policies link

  • In Oracle Identity Self Service: The Certifications, My open tasks, and Pending Approvals links/icons in the Self Service Home page, and the Approvals tab in the Request Details/Summary pages