One Identity Manager supports approval of requests with various types of automatic approvals.
The approval step is approved automatically based on a predefined condition. If the condition returns a result, the approval step is granted approval. If the condition does not return a result, the approval step is denied approval.
For more information, see Calculated approval.
Checks the request for possible rule violations before approval. It takes into account the requested product, all pending requests, and all the company resources already assigned to the request recipient. The approval procedure checks whether the recipient violates existing compliance rules if the requests are granted approval.
Compliance checking requests does not necessarily detect all rule violations. Therefore, it does not replace the cyclical testing of compliance rules.
For more information, see Compliance checking requests.
Approval of the approval step is automatically decided as soon as a condition outside the One Identity Manager is fulfilled.
Specify an event in the approval step that triggers an external approval. The event triggers a process initiating external approval for the request and evaluates the result of the approval decision. The approval process waits until the result of the external approval is passed on to One Identity Manager.
For more information, see Approvals to be made externally.
The approval step is automatically approved if the requested product falls below a fixed risk index value.
Prerequisite: The permitted value for the risk index is given in the approval step.
Finds the risk index of the requested product and compares it with the permitted value specified in the approval step. If the risk index is lower than the permitted value the approval step is granted approval. Otherwise, the approval step is not granted approval.
Only risk indexes with inputted values are considered for the approval decision; calculated risk indexes are not taken into account.
For more information, see Request risk analysis.
Approval procedure to approve requests automatically. You do not have to specify approvers.
Always define an approval workflow with the SB approval procedure as a one-step workflow. That means you cannot set up more approval steps in addition to a self-service approval step. For more information, see Rule checking for requests with self-service.
The approval workflow and the Self service approval policy are available in the default installation and assigned to the Identity & Access Lifecycle shop.
The approval step defers approval until a defined condition is fulfilled. For example, system entitlement requests can be checked and maintained until the corresponding user account is available.
Prerequisite: The condition is defined as a function call in the approval step.
For more information, see Waiting for further approval.
NOTE: Only one approval step can be defined with the WC approval procedure per approval level.
Use the WC approval procedure within an approval process to ensure that a defined prerequisite is fulfilled before the request is approved. Therefore, approval of a system entitlement request is only possible if existence of the corresponding user account is verified. Deferred approval is useful when a request should be tested for rule conformity. If the user account does not exist when the requested permissions groups are tested, any rule violations that may occur due to the request will not be logged.
You can specify which prerequisites have to be fulfilled so that a request can be presented for approval by defining an appropriate condition. The condition is evaluated as a function call. The function must accept the request UID as a parameter (PersonWantsOrg.UID_PersonWantsOrg). It must define three return values as integer values. One of the following actions is carried out depending on the function’s return value.
Table 30: Return value for deferred approval
|
Return value > 0 |
The condition is fulfilled. Deferred approval has completed successfully. The next approval step (in case of success) is carried out. |
|
Return value = 0 |
The condition is not yet fulfilled. Approval is rolled back and is retested the next time DBQueue Processor runs. |
|
Return value < 0 |
The condition is not fulfilled. Deferred approval has failed. The next approval step (in case of failure) is carried out. |
To use an approval procedure
-
Create a database function which tests the condition for the request.
-
Create an approval step with the WC approval procedure. Enter the function call in Condition.
Syntax: dbo.<function name>
-
Specify an approval step in the case of success. Use an approval procedure with which One Identity Manager can determine the approvers.
-
Specify an approval step in the case of failure.
Example
To check whether the necessary user account exists when the permissions group is requested, you can use the TSB_FGIPWODecisionForGroup function that is supplied.
Table 31: Example of an approval step with deferred approval
|
Single step: |
Waiting Condition |
|
Approval procedures: |
WC - Waiting for further approval |
|
Condition: |
dbo.TSB_FGIPWODecisionForGroup |
|
Number of approvers: |
1 |
Table 32: Return value for deferred approval decisions in the TSB_FGIPWODecisionForGroup function
|
Return value > 0 |
The user account exists, thus fulfilling the condition. The delayed approval is decided positively. The request is passed onto the next approval step. Now an approval step must follow which can establish the approvers for the request. |
|
Return value = 0 |
The condition is not fulfilled. There is a request pending for a user account or the identity has an account definition with which a user account could be created. Approval is, therefore, deferred, and tested again on the next DBQueue Processor run. |
|
Return value < 0 |
The condition is not fulfilled. There is no request for a user account and the identity does not have an account definition with which a user account could be created. The delayed approval is decided negatively. The request is passed onto the next approval step. |
NOTE: Only one approval step can be defined with the CD approval procedure per approval level.
It is possible to determine who should be presented with the request for approval on the basis of a defined condition. For example, if the price of the request is below a defined limit, then the department manager can grant approval. If this limit is exceeded, the request has to be presented to the cost center manager. In another case, requests from members of department XY can be granted immediate approval as long as the request does not exceed the defined price limit. If the limit is exceeded or if the employee belongs to another department, the approval has to be granted by the department manager.
To calculate an approval (CD approval procedure), enter a condition when you set up the approval step. If the condition returns a result, the approval step is approved through One Identity Manager. If the condition does not return a result, the approval step is denied by One Identity Manager. If there are no subsequent steps to be carried out, the request is finally granted or denied approval. The condition is defined as a valid where clause for database queries. You can enter the SQL query directly or with a wizard. The condition is always checked for the current request and requester.
Example for calculated approval
Requests with a price of under 1000 euros can be approved by the customer’s department manager. Requests over 1000 euros must be presented to the cost center manager.
Table 33: Approval step with calculated approval
|
Single step: |
Calculated approval |
|
Approval procedures: |
CD - Calculated approval |
|
Condition: |
EXISTS ( |
SELECT 1 FROM ( |
SELECT UID_ITShopOrg FROM ITShopOrg WHERE EXISTS ( |
SELECT 1 FROM ( |
SELECT UID_AccProduct FROM AccProduct |
WHERE round(PurchasePrice, 13) < round(1.000000E+003, 13) |
) as X |
WHERE X.UID_AccProduct = ITShopOrg.UID_AccProduct |
) ) as X |
WHERE X.UID_ITShopOrg = PersonWantsOrg.UID_Org) | |
|
Number of approvers: |
1 |
Figure 6: Approval workflow showing calculated approval
Use external approvals (EX approval procedure) if a request needs to be approved once a defined event from outside One Identity Manager takes place. You can also use this procedure to allow users with no access to One Identity Manager to approve requests.
Specify an event in the approval step that triggers an external approval. The event triggers a process that initiates the external approval for the request and evaluates the result of the approval decision. The approval process waits for the external decision to be passed to One Identity Manager. Define the subsequent approval steps depending on the result of the external approval.
To use an approval procedure
-
In the Designer, define your own processes that:
-
Triggers an external approval.
-
Analyzes the results of the external approval.
-
Grants or denies approval in the subsequent external approval step in One Identity Manager.
-
Defines an event that starts the process for external approval. Enter the result in Result in the approval step.
If the external event occurs, the approval step status in One Identity Manager must be changed. Use the CallMethod process task with the MakeDecision method for this. Pass the following parameters to the process task:
MethodName: Value = "MakeDecision"
ObjectType: Value = "PersonWantsOrg"
Param1: Value = "sa"
Param2: Value = <approval> ("true" = granted; "false" = denied)
Param3: Value = <reason for approval decision>
Param4: Value = <standard reason>
Param5: Value = <number approval steps> (PWODecisionStep.SubLevelNumber)
WhereClause: Value = "UID_PersonWantsOrg ='"& $UID_PersonWantsOrg$ &"'"
Use these parameters to specify which request is to be approved by external approval (WhereClause). Param1 specifies the approver. The approver is always the sa system user. Param2 passes down the approval decision. If the request was granted, a value of True must be returned. If the request was denied, a value of False must be returned. Use Param3 to pass a reason text for the approval decision; use Param4 to pass a predefined standard reason. If more than one external approval steps have been defined in an approval level, use Param5 to pass the approval step count. This ensures the approval is aligned with the correct approval step.
Example
All approved requests should be entered into an external ticketing system and started. If a request is completed in an external ticketing system, it must also be completed in One Identity Manager. Use this approval procedure to make external approvals and define:
- A P1 process that creates a ticket with the information about the requested product in the external system and passes the ticket number to One Identity Manager in the request instance.
- An E1 event that starts the P1 event.
- A P2 process that checks whether the ticket status is "closed" and calls the CallMethod process task with the MakeDecision method in One Identity Manager.
- An E2 event that starts the P2 process.
- A schedule that starts the E2 event on a regular basis.
Enter E1 in the Event box as the trigger for the external decision.
Pass the product and customer data that the product is being requested for in the P1 process to the external ticket system. In another parameter, pass the ticket number from the external ticketing system to One Identity Manager.
Use the ticket number to check the ticket status in P2 process. If the ticket is closed, call the MakeDecision method and pass the ticket status from the external system to One Identity Manager in a parameter (Param2). In another parameter, specify the system user that changes the approval step status in One Identity Manager (Param1). Pass sa as the value for this parameter. Pass the reason for the approval decision in Param3.
For more information about defining processes, see One Identity Manager Configuration Guide.
CD - Calculated approval