Converse agora com nosso suporte
Chat com o suporte

Identity Manager 9.0 LTS - IT Shop Administration Guide

Setting up an IT Shop solution
One Identity Manager users in the IT Shop Implementing the IT Shop Using the IT Shop with the Application Governance Module Requestable products Preparing products for requesting Assigning and removing products Preparing the IT Shop for multi-factor authentication Assignment requests Delegations Creating IT Shop requests from existing user accounts, assignments, and role memberships Adding system entitlements automatically to the IT Shop Deleting unused application roles for product owners
Approval processes for IT Shop requests
Approval policies for requests Approval workflows for requests Determining effective approval policies Selecting responsible approvers Request risk analysis Testing requests for rule compliance Approving requests from an approver Automatically approving requests Approval by peer group analysis Gathering further information about a request Appointing other approvers Escalating an approval step Approvers cannot be established Automatic approval on timeout Halting a 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 Restructuring the IT Shop Templates for automatically filling the IT Shop Custom mail templates for notifications Request templates Recommendations and tips for transporting IT Shop components with the Database Transporter
Troubleshooting errors in the IT Shop Configuration parameters for the IT Shop Request statuses Examples of request results

Explicit exception approval

If the QER | ComplianceCheck | EnableITSettingsForRule configuration parameter is set, properties can be added to compliance rules that are taken into account when rule checking requests.

Use the Explicit exception approval IT Shop property to specify whether the reoccurring rule violation should be presented for exception approval or whether an existing exception approval can be reused.

Table 48: Permitted values

Option is

Description

Enabled

A known rule violation must always be presented for exception approval, even if there is an exception approval from a previous violation of the rule.

Not set

A known rule violation is not presented again for exception approval if there is an exception approval from a previous violation of the rule. This exception approval is reused and the known rule violation is automatically granted exception.

If several rules are violated by a request and Explicit exception approval is set for one of the rules, the request is presented for approval to all exception approvers for this rule.

Rules that have Explicit exception approval set result in a renewed exception approval if:

  • A rule check is carried out within the approval process for the current request.

    - AND -

    1. The rule is violated by the current request.

      - OR -

    2. The IT Shop customer has already violated the rule.

In case (a), the request for the IT Shop customer is presented to the exception approver. If the request is approved, case (b) applies to the next request. In case (b), every request for the IT Shop customer must be decided by the violation approver, even when the request itself does not result in a rule violation. The result you achieve is that assignments for employees who have been granted an exception, are verified and reapproved for every new request.

For more information about exception approvals, see the One Identity Manager Compliance Rules Administration Guide.

Rule checking for requests with self-service

Self-service (SB approval procedure) is always defined as a one-step procedure. That means you cannot set up more approval steps in addition to a self-service approval step.

To realize compliance checking for requests with self-service

Approving requests from an approver

By default, approvers can make approval decisions about requests in which they are themselves requester (UID_PersonInserted) or recipient (UID_PersonOrdered). To prevent this, you can specify the desired behavior in the following configuration parameter and in the approval step.

  • QER | ITShop | PersonOrderedNoDecide configuration parameter

  • QER | ITShop | PersonInsertedNoDecide configuration parameter

  • Approval by affected employee option in the approval step.

If the requester or approver is not allowed to make approval decisions, their main identity and all subidentities are removed from the group of approvers.

NOTE:

  • The configuration parameter setting also applies for fallback approvers; it does not apply to the chief approval team.

  • This configuration parameter does not affect the BS and BR approval procedures. These approval procedures also find the requester and the request recipient if the configuration parameter is not set. For more information, see Finding requesters.

Summary of configuration options

Requesters can approve their own requests if:

  • The PersonInsertedNoDecide configuration parameter is not set.

- OR -

  • The Approval by affected employee option is set.

Recipients can approve their own requests if:

  • The PersonOrderedNoDecide configuration parameter is not set.

- OR -

  • The Approval by affected employee option is set.

Requesters cannot approve if:

  • The PersonInsertedNoDecide configuration parameter is set.

    The Approval by affected employee option is not set.

Recipients cannot approve if:

  • The PersonOrderedNoDecide configuration parameter is set.

    The Approval by affected employee option is not set.

Example

A department manager places a request for an employee. Both of them are found to be approvers by the approval procedure. To prevent the department manager from approving the request, set the QER | ITShop | PersonInsertedNoDecide parameter. To prevent the employer from approving the request, set the QER | ITShop | PersonOrderedNoDecide parameter.

Approving requests from an exception approver

Similarly, you specify whether exception approvers are allowed to approve their own requests if compliance rules are violated by a request. For more information, see Restricting exception approvers.

Related topics

Setting up approver restrictions

To prevent recipients of requests becoming approvers

  • In the Designer, set the QER | ITShop | PersonOrderedNoDecide configuration parameter.

    This configuration parameter takes effect if the Approval by affected employee option is not set on the approval step.

To prevent requesters becoming approvers

  • In the Designer, set the QER | ITShop | PersonInsertedNoDecide configuration parameter.

    This configuration parameter takes effect if the Approval by affected employee option is not set on the approval step.

For individual approval workflows, you can allow exceptions to the general rule in the PersonInsertedNoDecide and PersonOrderedNoDecide configuration parameters. Use these options to allow the requester or recipient of requests to make approval decisions themselves in single approval steps.

To allow request recipients or requesters to become approvers in certain cases

  • On the approval step, enable the Approval by affected employee option.

Related topics
Documentos relacionados

The document was helpful.

Selecione a classificação

I easily found the information I needed.

Selecione a classificação