By default, permanently deactivated identities 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 identities are automatically removed from all custom nodes once they are permanently deactivated. This means that all pending requests are broken off and remaining assignments are removed.
To remove identities from all customer nodes if they are permanently deactivated
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.
The same procedure is followed for completed deputizations. The properties of the deputizations are recorded; then the deputizations are deleted from the database.
To delete request procedures and deputizations automatically
-
In the Designer, set the QER | ITShop | DeleteClosed configuration parameter.
-
To delete canceled 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 and compile the database.
If you disable the configuration parameter at a later date, model components and scripts that are no longer required, are disabled. SQL procedures and triggers are still carried out. For more information about the behavior of preprocessor relevant configuration parameters and conditional compiling, see the One Identity Manager Configuration Guide.
The deleted deputizations, request procedures, and their approval history are logged. For more detailed information about logging data changes, see the One Identity Manager Configuration Guide.
NOTE: Ensure that the recorded request procedures and deputizations 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.
Depending on your company structure, you can use the supplied default shop, Identity & Access Lifecycle, and extend it or set up your own IT Shop solution. Set up different IT Shop structures for your custom IT Shop solution. Specify which identities are authorized to make request in the shops.
To set up an IT Shop solution with the help of the IT Shop wizard.
-
In the Manager, select the My One Identity Manager > IT Shop wizards > Create shop category.
The wizard includes the most important configuration stages for setting up an IT Shop. After completing the wizard, there may be other configuration steps necessary.
IT Shop structures such as shopping centers, shops, and shelves are mapped in the IT Shop > IT Shop category. An IT Shop solution is displayed hierarchically.
The following sections describe the procedure for manually setting up an IT Shop.
Various base data is required to construct an IT Shop:
-
Processing status
Processes statuses pass on the status of single approval steps. You can set the processing status for each approval step in the approval workflow depending on whether the approval decision was negative or positive. Depending on the result of the approval decision, the appropriate processing status is set for the request.
For more information, see Processing status.
-
Standard reasons
Standard reasons are predefined reasons that can be selected in the Web Portal when making approval decisions.
For more information, see Standard reason for requests.
-
Approval policies
One Identity Manager uses approval policies to determine the approver for each request process.
For more information, see Approval policies for requests.
-
Approval workflows
Approval workflows define all the necessary steps for making approval decisions for request processes.
For more information, see Approval workflows for requests.
-
Approval procedure
Approval procedures are used to find the approvers required for an approval step.
For more information, see Setting up approval procedures.
-
Mail templates
Mail templates are used to send email messages to requesters and approvers.
For more information, see Custom mail templates for notifications.
-
Adaptive cards
To allow approvers who temporarily do not have access to the One Identity Manager tools to approve requests, you can send adaptive cards.
For more information, see Creating, editing, and deleting adaptive cards for requests.
-
Role classes
Use role classes to specify which company resources can be requested through the IT Shop. At the same time, you decide which company resources may be assigned as products to shelves and IT Shop templates.
For more information, see Role classes for the IT Shop.
-
Role types
Role types are used to group roles into a role class. Within the IT Shop, role types can e used to group shop and to restrict the effective approval policies for a shelf.
For more information, see Role types for the IT Shop.
-
Business Partners
In One Identity Manager, you can enter the data for external businesses that could be act as manufacturers, suppliers, or partners. You assign a manufacturer to a service item.
For more information, see Business partners.
-
Functional areas
To analyze rule checks for different areas of your company in the context of identity audit, you can set up functional areas. Moreover, functional areas can be replaced by peer group analysis during request approvals or attestation cases. Functional areas can be assigned to service items.
For more information, see Functional areas.
-
Service categories
Service categories are used to group service items and make them available in the Web Portal.
For more information, see Entering service categories.
-
Tags
Product owners are able to add tags to their products. These tags can be used as search criteria by requests in the Web Portal.
For more information, see Entering tags.
-
Request properties
Requests can be given additional information though product-specific request properties such as the specific details of a product, its size, or color. A request property gathers all additional features together that can be given when requesting a product.
For more information, see Entering product-specific request properties.
-
Chief approval team
There is a default application role in One Identity Manager for the chief approval team. Assign identities to this application role, who are authorized to approve, deny, cancel requests, or to authorize other approvers in special cases.
For more information, see Chief approval team.
-
Product owners
A default application role for product owners is available in One Identity Manager. Assign the identities to this application role, who are authorized to approve requests and edit the main data of service items or service categories.
For more information, see Product owners.
-
Attestors
A default application role for attestors is available in One Identity Manager. Assign the identities to this application role, who are authorized to attest IT Shop structures.
For more information, see Attestors.
