4 Managing 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 favour 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, as described in Managing Approval Policies in the Administrator’s Guide for Oracle Identity Manager for 11g Release 2 (11.1.2.2).
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.
The request process flow is as follows:
-
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.
-
If the operation is not authorized, then an error is returned and the flow ends.
-
If the operation is allowed, then it is checked if the operation is a bulk operation or future-dated operation.
-
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.
-
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 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.
Note: These SoD request statuses are possible if the request is any of the following request types:
|
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:
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 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:
|
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:
|
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:
|
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.
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.
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!5.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!5.0 |
Revoke Account |
Revoke Account Certification Rule |
request.isCertification Equal TRUE |
Workflow default/DefaultRequestApproval!5.0 |
Revoke Entitlement |
Revoke Entitlement Certification Rule |
request.isCertification Equal TRUE |
Workflow default/DefaultRequestApproval!5.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:
-
Assign Roles IdentityAuditorEnabled Rule
-
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:
-
Login to Oracle Identity System Administration.
-
On the left navigation pane, under Workflows, click Approval. The Approval Workflow Configuration page is displayed.
-
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.
-
In the Rules section, click Create. The Create Rule page is displayed.
-
In the Name box, enter a name for of the rule. This is a mandatory field.
-
In the Description box, enter a description for the rule.
-
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.
-
From the Status list, select a status for the rule. By default, the rule is in Enabled status.
-
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:
-
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. -
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.
-
Click the Organization Name attribute. The condition
requester.Organization Name
is displayed in the Condition Builder dialog box. -
Click OK. The condition is added to the first field in the IF clause.
-
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
-
-
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. -
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
. -
-
Click Top. The Top organization is selected.
-
Click OK. The Top organization is populated in the value field.
-
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.
-
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.
-
-
In the THEN clause, click the search icon adjacent to the first field to open the Condition Builder dialog box.
-
Select workflow and click OK.
-
In the value field for workflow, select AutoApproval!1.0. The request will be auto-approved if you select this workflow.
-
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
-
-
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 |
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 request.isCertification EQUAL true Note: |
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 identityAuditEnabled EQUALS TRUE Note: |
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 identityAuditEnabled EQUALS TRUE Note: |
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 identityAuditEnabled EQUALS TRUE Note: |
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 identityAuditEnabled EQUALS TRUE Note: |
Assign Roles, Remove from Roles |
request |
This refers to the request metadata, and the only allowed sub-attribute is request.isCertification EQUAL true Note: |
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 identityAuditEnabled EQUALS TRUE Note: |
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.
Example 1: appType[AD User].appInstance[VisionEmployeesDomain].account[*].Organization Name EQUAL Marketing This condition means that if an account is being created in the 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 |
Provision ApplicationInstance |
catalogItem |
This refers to catalog metadata attributes set in the catalog item for which the access request is being submitted, for example |
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 |
Enable Account, Disable Account, Revoke Account |
request |
This refers to the request metadata, and the only allowed sub-attribute is request.isCertification EQUAL true Note: |
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 |
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, |
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 |
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 |
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 |
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 |
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 |
Revoke Entitlement |
request |
This refers to the request metadata, and the only allowed sub-attribute is request.isCertification EQUAL true Note: |
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":
-
On the left navigation pane of Identity System Administration, under Workflows, click Approval. The Approval Workflow Configuration page is displayed.
-
In the Operation section, select an operation to configure rules for the operation.
-
In the Rules section, click Edit. The Edit Rule page is displayed.
-
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.
-
In the Rules section, select the rule that you want to edit, and click Edit. The Edit Rule page is displayed.
-
If you want to modify any rule attribute, then update the attribute values in the Edit Rule section.
-
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:
-
In the Condition Builder section, click Add Condition. A new row is added.
-
From the operators list on the right, select OR.
-
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. -
From the operators list, select CONTAINS.
-
In the value field, select
OrclOIMUserHelpDesk
by using the Condition Builder dialog box. -
In the THEN section, specify workflow and default/BeneficiaryManagerApproval!3.0 in the two fields respectively. Therefore, the complete rule condition is:
IF requester.adminRoles CONTAINS OrclOIMUserHelpDesk THEN workflow default/BeneficiaryManagerApproval!3.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.
-
-
Click Update. The workflow rule is updated with the new rule condition.
-
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:
- On the left navigation pane of Identity System Administration, under Workflows, click Approval. The Approval Workflow Configuration page is displayed.
- In the Operation section, select an operation whose workflow rule you want to delete.
- In the Rules section, click Delete. A message box is displayed asking for confirmation.
- 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:
-
The approval workflow rules associated with the operation being performed are evaluated one by one, in the order in which they are configured.
-
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.
-
For a Bulk operation, if none of the rules match, then the SOA composite configured in
defaultRequestApprovalComposite
of SOAConfig is returned implicitly. -
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 follows](img/noworkflow.gif)
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:
-
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.
-
Pick the approval policy that comes first or next in the order of priority.
-
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.
-
Model the current approval policy as an approval workflow rule as follows:
-
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
-
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.
-
Model the approval policy rule as approval workflow rule condition in the Approval Workflow Configuration page.
-
-
Repeat steps 2 through 4 for all the approval policies applicable to a request type.
-
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:
- Ensure that SOA is enabled. To do so, verify that the value of the
Workflows Enabled
system property istrue
. - Ensure that migration of approval policies to approval workflows, as described in "Migrating Approval Policies to Approval Workflow Rules", has been completed.
- Set the value of the
Workflow Policies Enabled
system property totrue
. - Restart Oracle Identity Manager Managed Server.
4.3.4.2 About In-Flight Request Lifecycle
When you upgrade Oracle Identity Manager to 12c Release 2 (12.2.1.2.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 follows](img/inflight1.gif)
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 follows](img/inflight2.gif)
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:
- Login to Oracle Identity System Administration of the source/test environment as the system administrator.
- On the left pane, under System Configuration, click Export. The Export Configuration page opens and the Search Objects option is displayed.
- From the Search Objects page, select Type as Policy and click Search icon. Search result is displayed in the Available Entities table.
- 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.
- Click Next or click Export Options in the train link. The Export Options page is displayed.
- Set Dependency to Yes, select the workflow rules for the selected operations that you want to export.
- Continue with the remaining steps of the wizard and complete the export.
- Login to Oracle Identity System Administration of the target/production environment as the system administrator.
- On the left pane, under System Configuration, click Import.
- 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:
- Shutdown the SOA Managed Server.
- Set the value of the
Workflows Enabled
system property tofalse
. See Table 19-1 for information about this system property. - 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 |
|
Provisioning operations |
|
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 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 interface |
The following features are disabled (and not displayed) in the default user interface when the
|
4.6 Use Cases for Disabled or Deleted Proxy Users
When users are disabled, Oracle Identity Governance handles tasks without losing the assignments although the target assignee of the task being initiated is already disabled, or the current assignee of the pending tasks is being disabled. The type of tasks can be one of request/approval task, identity audit (IDA) scan violation, or certification.
Applying Oracle Identity Governance Bundle Patch 12.2.1.3.210329 provides the following enhancements:
Removing Proxy Relationships When a User is Disabled or Deleted
When a user is disabled or deleted, all proxy relationships defined with the user is not effective anymore. If there is an active proxy at the time of disabling the user, the proxy will be terminated. This means that Oracle Identity Governance removes all proxy data of this user from the database and SOA.
For example, User1 and User2 set their proxy to User3, and User3 sets his proxy to User4. When User3 is disabled, those proxy relationships will be removed.
Proxy cleanup actions are done both with Oracle Identity Governance database and SOA. As a result, the proxy data is completely removed from the system.
Task Assignment with Proxy
When a user has proxy a setup, all tasks are delegated to both the user and its proxy. This means that both the users have the same level of control at the beginning. When a user starts to take actions on the task, modification actions on the same task are limited for the other assignee.
Reassigning Tasks When Current Assignee is Disabled or Deleted
When a user is disabled or deleted, the existing proxies from/to this user are
removed, and all pending tasks are reassigned to the other user or role depending on
the configuration of the OIG.DefaultTaskReassignee
system property.
It is important to set this property with an active user or role.
By default, the value of the OIG.DefaultTaskReassignee
system
property is the SYSTEM ADMINISTRATORS role so that pending tasks can be reassigned
to the SYSTEM ADMINISTRATORS role when a user is disabled or deleted.
When the value of the OIG.DefaultTaskReassignee
system property is a
manager, Oracle Identity Governance finds the closest active manager from the
hierarchy if the current target assignee is disabled.
When the value of the OIG.DefaultTaskReassignee
system property is a
user, Oracle Identity Governance reassigns the task to the user.
When the value of the OIG.DefaultTaskReassignee
system
property is a role, Oracle Identity Governance reassigns the task to the role. Here,
the role name as the value of the OIG.DefaultTaskReassignee
system
property is case-sensitive.
If Oracle Identity Governance cannot find any valid assignee, then the tasks are reassigned to the System Administrator.
Note:
This feature works for the disable and delete operations initiated from Oracle Identity Governance user interface or APIs only. Disabling and deleting the users from reconciliation and bulk load does not trigger this new feature.
Defining the New Initial Task Assignee
If the target assignee of a request being created is already disabled, Oracle Identity Governance looks for the closest manager of the initial target assignee based on the configured approval workflows, as described below:
-
OIG.BeneficiaryManagerApprovalWorkflows (for request only): When the initial target assignee is already disabled, Oracle Identity Governance looks for the closest manager of the beneficiary of the request with the defined approval workflow, as shown:
OIG.BeneficiaryManagerApprovalWorkflows=default/BeneficiaryManagerApproval!4.0,default/MyCustomComposite!1.0
Multiple composites can be defined with the comma separator.
-
OIG.RequesterManagerApprovalWorkflows (for Request only): When the initial target assignee is already disabled, Oracle Identity Governance looks for the closest manager of the requester of the request with the defined approval workflow, as shown:
OIG.RequesterManagerApprovalWorkflows=default/RequesterManagerApproval!4.0,default/MyCustomComposite2!1.0
Multiple composites can be defined with the comma separator.
Note:
The OIG.BeneficiaryManagerApprovalWorkflows and OIG.RequesterManagerApprovalWorkflows properties are applicable only for requests. By default, OIG.BeneficiaryManagerApprovalWorkflows is set to default/BeneficiaryManagerApproval!4.0, and OIG.RequesterManagerApprovalWorkflows is set to default/RequesterManagerApproval!4.0. You can append more approval workflows, such as the following:
OIG.BeneficiaryManagerApprovalWorkflows= default/BeneficiaryManagerApproval!4.0,default/DefaultOperationalApproval!5.0
-
Identity Audit (IDA) scan violations and certifications are assigned to the closest active manager of the initial target assignee if the manager is already disabled.
If a valid assignee is not found, Oracle Identity Governance assigns the IDA scan violations and certifications to the user defined for OIG.DefaultTaskReassignee, and then for SYSTEM ADMINISTRATOR or the default certification assignee, if defined.
When certifications are created, if there is no valid assignee even after looking up for the active higher manager and the user defined for OIG.DefaultTaskReassignee and XL.AlternativeReviewerIDForManager, Oracle Identity Governance skips the creation of such certifications. Therefore, make sure that the two system properties are defined with active users with enough privilege for the operations.
Deploying the New Version of the CertificationProcess Composite
To enable this feature after applying this bundle patch, deploy the new version of
the CertificationProcess
composite. To do so:
- Create a backup of the current version of the
CertificationProcess
composite from SOA, as shown:- Login to Oracle Enterprise Manager Fusion Middleware Control.
- Navigate to SOA, soa-infra, default, CertificationProcess[2.0].
- From the SOA Composite menu, select Export the composite.
- Extract the contents of the
OIM_HOME
/server/workflows/composites/CertificationProcess.zip
file to a temporary directory. - Perform the following steps to deploy the
deploy/sca_CertificationProcess_rev2.1.jar
file:- In Oracle Enterprise Manager Fusion Middleware Control, navigate to SOA, soa-infra, default.
- From the SOA Composite menu, select SOA Deployment, Deploy.
- Provide the complete path of the
/deploy/sca_CertificationProcess_rev2.1.jar
file. - Restart the SOA servers.