Approval by Starling 2FA app
Approvers that are registered for Starling Two-Factor Authentication, can also use the Starling 2FA app for approvals. To do this, in the Designer, set the QER | Person | Starling | UseApprovalAnywhere configuration parameter. For detailed information, see the One Identity Manager Authorization and Authentication Guide.
Requests with limited validity period for changed role memberships
If an employee changes their primary department (business role, cost center, or location), they lose all company resources and system entitlements inherited through it. However, it may be necessary for the employee to retain these company resources and system entitlements for a certain period. Use temporary requests to retain the state of the employee's current memberships. Inherited assignments are not removed until after the validity period for this request has expired. The employee can renew the request with the validity period.
Prerequisites
To configure automatic requests for removal of role memberships
-
In the Designer, set the QER | ITShop | ChallengeRoleRemoval configuration parameter.
-
In the Designer, set the QER | ITShop | ChallengeRoleRemoval | DayOfValidity configuration parameter and enter a validity period for the request.
-
In the Designer, set the configuration parameters under QER | ITShop | ChallengeRoleRemoval for roles whose primary memberships need to remain intact when modified.
-
Commit the changes to the database.
NOTE: The configuration parameters are set by default. The validity period is set to seven days.
If employee master data is modified by importing, One Identity Manager checks if a primary role (for example Person.UID_Department) was modified or deleted on saving. If this is the case, VI_CreateRequestForLostRoleMembership is executed. The script create a temporary assignment request for this role, which is granted approval automatically. Thus, the employee remains a members of the role and retains their company resources and system entitlements. The request is automatically canceled when the validity period expires.
The request can be renewed during the validity period. The request renewal must be approved by the role manager. The request becomes permanent if approval is granted. Role membership stays the same until the assignment is canceled.
TIP: The QER | ITShop | ChallengeRoleRemoval | ITShopOrg configuration parameter specifies which product nodes to use for a limited validity period request of modified role memberships. The Challenge loss of role membership product is available by default in the Identity & Access Lifecycle | Identity Lifecycle shelf. You can also add this product to your own IT Shop solution.
To use the "Challenge loss of role membership" product in your own IT Shop
-
Assign the Challenge loss of role membership assignment resource to one of your own shelves.
-
In the Designer, edit the value of the QER | ITShop | ChallengeRoleRemoval | ITShopOrg configuration parameter.
Related topics
Requests from permanently inactive employees
By default, permanently disabled employees remain members in all the customer nodes. This ensures that all pending request and resulting assignments are retained. One Identity Manager can be configured such that employees are automatically removed from all custom nodes once they are permanently disabled. This means that all pending requests are aborted and remaining assignments are removed.
To remove employees from all customer nodes if they are permanently disabled
Deleting requests
To limit request procedures in the One Identity Manager database, you can remove closed request procedures from the database. The request procedure properties are logged in the approval history at the same time. The requests are subsequently deleted. Only closed requests with unexpired retention periods are kept in the database.
If the request to be deleted still contains dependent requests, the request is only deleted after the dependent requests have been deleted. Dependent requests are requests that are entered into PersonWantsOrg.UID_PersonWantsOrgParent.
To delete requests automatically
-
In the Designer, set the QER | ITShop | DeleteClosed configuration parameter.
-
To delete aborted requests, set the QER | ITShop | DeleteClosed | Aborted configuration parameter and set the retention period in days.
-
To delete denied requests, set the QER | ITShop | DeleteClosed | Dismissed configuration parameter and set the retention period in days.
-
To delete canceled requests, set the QER | ITShop | DeleteClosed | Unsubscribed configuration parameter and specify its retention period in days.
-
In the Designer, set the Common | ProcessState | PropertyLog configuration parameter.
This activates logging for deleted request procedures and their approval history. For more detailed information about logging data changes tags, see the One Identity Manager Configuration Guide.
INFORMATION: Ensure that the recorded request procedures are archived for audit reasons. For more detailed information about the archiving process, see the One Identity Manager Data Archiving Administration Guide.
Closed requests are deleted by the DBQueue Processor once the request's retention period has expired. As the basis for calculating the retention period, the request's cancellation date is used. If this date cannot be given, the time at which the request was last changed, is used. The DBQueue Processor determines the requests to be deleted in the context of daily maintenance tasks. All request procedure properties are logged in the approval history.