Chat now with support
Chat with Support

Identity Manager 8.1 - IT Shop Administration Guide

Setting up an IT Shop Solution
One Identity Manager Users in the IT Shop Putting the IT Shop into Operation Requestable Products Preparing Products for Requesting Assigning and removing products Preparing the IT Shop for multi-factor authentication Assignment Requests and Delegating Creating IT Shop Requests from Existing User Accounts, Assignments and Role Memberships Adding Groups Automatically to the IT Shop
Approval Processes for IT Shop Requests
Editing Approval Policies Approval Workflows Determining Effective Approval Policies Selecting Responsible Approvers Request Risk Analysis Testing Requests for Rule Compliance Approving requests from an approver Automatic Request Approval Obtaining Other Information about Requests by an Approver Appointing Other Approvers Setting up an Approval Step Approvers cannot be Established Automatic Approval on Timeout Abort Request on Timeout Approval by the chief approval team Approving Requests with Terms of Use Using Default Approval Processes
Request Sequence Managing an IT Shop
IT Shop Base Data Setting up IT Shop Structures Setting Up a Customer Node Deleting IT Shop Structures Templates for Automatically Filling the IT Shop Creating Custom Mail Templates for Notifications request templates
Default Solution for Requesting System Entitlements Resolving errors in the IT Shop Appendix: Configuration parameters for the IT Shop Appendix: Request Statuses Appendix: Example of Request Results

Using a requested role to find approvers

If membership in or assignment to a hierarchical role is requested and the manager of the requested role is to be the approver, use the approval procedure MS. Then the manager and deputy of the requested department, cost center, business role or location are determined as the approvers. This approval procedure can only be used for assignment requests.

Waiting for further approval

NOTE: Only one approval step per approval level can be defined with the approval procedure WC.

Use the approval procedure WC within an approval process to ensure that a defined prerequisite is fulfilled before the request is approved. Therefore, the approval of a permissions group request should only take place if the corresponding user account exists. Deferred approval is useful when a request should be tested with respect to 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 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 37: Return value for deferred approval

Return value

Action

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

  1. Create a database function which tests the condition for the request.

  2. Create an approval step with the approval procedure WC. Enter the function call in Condition.

    Syntax: dbo.<function name>

  3. Specify an approval step in the case of success. Use an approval procedure with which One Identity Manager can determine the approvers.

  4. 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 function TSB_FGIPWODecisionForGroup which is supplied.

Table 38: 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 39: Return value for deferred approval decisions in the function TSB_FGIPWODecisionForGroup
Return value Action

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 an open request for a user account or the employee 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 employee 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.

Calculated approval

Note: Only one approval step per approval level can be defined with the CD approval procedure.

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.

If approval should be calculated (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 the One Identity Manager. If the condition does not return a result, the approval step is denied by the 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.

NOTE: If there is reference to the current request in the condition, use one of the following variables. The variable must be in quotes.

Syntax: '@UID_PersonWantsOrg'

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 40: Approval step with calculated approval

Single step:

Calculated approval

Approval procedures:

CD - calculated approval

Condition:

isnull(UID_Org, '') in

(Select UID_ITShopOrg From ITShopOrg Where isnull(UID_AccProduct, '') In
(Select UID_AccProduct From AccProduct Where isnull(PurchasePrice, 0) < 1000))

Number of approvers:

1

Then the query is composed as:

select 1 from PersonWantsOrg

where (isnull(UID_Org, '') in

(Select UID_ITShopOrg From ITShopOrg Where isnull(UID_AccProduct, '') In

(Select UID_AccProduct From AccProduct Where isnull(PurchasePrice, 0) < 1000)))

and UID_PersonWantsOrg = '@UID_PersonWantsOrg'

Figure 7: Approval Workflow Showing Calculated Approval

Approvals to be made externally

Use external approvals (approval procedure EX) if a request needs to be approved once a defined event from outside the One Identity Manager takes place. You can also use this procedure to allow users with no access to the 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

  1. Define your own processes that:

    • Trigger an external approval

    • Analyze the results of the external approval

    • Grant or deny approval in the subsequent external approval step in One Identity Manager

  2. Define an event, which 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 has to be changed. Use the process task CallMethod 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). Parameter Param1 specifies the approver. The approver is always the sa system user. Parameter param 2 is passed to the approval. If the request was granted, the value True must be transferred. If the request was denied, the value False must be transferred. Use parameter Param3 to pass a reason text fro 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.

Use the Process Editor to define and edit processes.

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 the One Identity Manager. Use this approval procedure to make external approvals and define:

  • A process "P1" that creates a ticket with the information about the requested product in the external system and passes the ticket number to the One Identity Manager in the request instance.
  • An event "E1" that starts the process "P1".
  • A process "P2" which checks whether the ticket status is "closed" and calls the CallMethod function with the MakeDecision method in the One Identity Manager.
  • An event "E2" that starts the process "P2".
  • A schedule that starts the events "E2" on a regular basis.

Enter "E1" in the Event box as trigger for the external decision.

Pass the product and customer data that the product is being requested for in the process "P1" to the external ticket system. In another parameter, pass the ticket number from the external ticketing system to the One Identity Manager.

Use the ticket number to check the ticket status in process "P2". If the ticket is closed, call the task MakeDecision and pass the ticket status from the external system to the One Identity Manager in a parameter (Param2). In another parameter, specify the system user that changes the approval step status in the One Identity Manager (Param1). Pass sa as the value for this parameter. Pass the reason for the approval decision in the parameter Param3.

For more detailed information about defining processes, see One Identity Manager Configuration Guide.

Detailed information about this topic
Related Documents