Chat now with support
Chat with Support

Identity Manager 9.2 - 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 Approval recommendations for requests 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
The request overview Requesting products more than once Requests with limited validity period Relocating a customer or product to another shop Changing approval workflows of pending requests Requests for employees Requesting change of manager for an employee Canceling requests Unsubscribe products Notifications in the request process Approval by mail Adaptive cards approval Requests with limited validity period for changed role memberships Requests from permanently deactivated identities Deleting request procedures and deputizations
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 Product bundles 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

Request risk analysis

Everyone with IT system authorization in a company represents a security risk for that company. For example, an identity with permission to edit financial data in SAP carries a higher risk than an identity with permission to edit their own main data. To quantify the risk, you can enter a risk value for every company resource in One Identity Manager. A risk index is calculated from this value for every identity that has this company resource assigned to it directly or indirectly. Company resources include target system entitlements (for example, Active Directory groups or SAP profiles), system roles, subscribable reports, software, and resources. In this way, all the people that represent a particular risk to the company can be found.

Every time a company resource with a specified risk index is assigned, the identity's risk index may exceed a permitted level. You can check the risk index of company resources if they are requested through the IT Shop. If the risk index is higher than the specified value, the request is denied.

To set up risk assessment for requests

  • Create an approval workflow.

    1. Add an approval step with the RI approval procedure.

    2. In the Condition field, enter the comparison value for the risk index. Enter a number in the range 0.0 to 1.0.

    3. Enter other approval levels if required.

The approval step is granted approval by One Identity Manager if the risk index of the requested company resource is lower than the comparison value. If the risk index is higher or equal to the comparison value, the approval step is not granted approval.

Risk assessment of requests works for both direct company resource request and assignment requests. Only risk indexes with inputted values are examined for the approval decision; calculated risk indexes are not taken into account. Therefore, risk assessment of requests only works if the product's original table or one of the member tables of a requested assignment has a RiskIndex column. If the table only has the RiskIndexCalculated column, the request is automatically approved. If both member tables of an assignment request have a RiskIndex column, the highest of the two risk indexes is used as the basis for the approval.

If the company resource request or an assignment has been granted approval, the identity's risk index is recalculated the next time the scheduled calculation task is run.

For more information about risk assessment, see the One Identity Manager Risk Assessment Administration Guide.

Related topics

Testing requests for rule compliance

Installed modules: Compliance Rules Module

You can integrate rule conformity testing for IT Shop requests within an approval workflow. A separate approval procedure is supplied for this. This approval procedure checks whether the request's recipient will violate compliance rules if the requests are granted approval. The result of the test is logged in the request's approval sequence and approval history.

Table 44: Approval procedures for compliance checking

Approval procedure

Description

CR - compliance check (simplified)

Checks the current request for possible rule violations. It takes into account the requested product and all the company resources already assigned to the request recipient.

Prerequisites for request validation

Compliance checking requests

To retain an overview of potential rule violations, you can run a simplified compliance check. Use the CR approval procedure to test requests for possible rule violations before finally approving them.

The following data of a recipient's request is taken into account by the compliance check:

  • All pending requests

  • All company resources already assigned to the recipient

  • All the recipient's user accounts

  • All entitlement in the target system (for example, Active Directory groups or SAP roles) the recipient has obtained through these user accounts

Auxiliary tables for object assignments are regularly evaluated for the compliance check. Auxiliary tables are calculated on a scheduled basis. Furthermore, the approval procedure only takes into account compliance rules that are created using the simplified definition.

Rule checking does not completely check the requests with this. It is possible that under the following conditions, rule checking does not identify a rule violation:

  • Customer permissions change after the auxiliary table have been calculated.

  • If memberships are requested in business role or organization, a rule is violated by an object that is inherited through the business role or organization. Inheritance is calculated after request approval and can therefore not be identified until after the auxiliary table is calculated again.

  • The customer does not belong to the identities affected by a rule until the request is made.

  • The rule condition was created in expert node or as an SQL query.

TIP: A complete check of assignments is achieved with cyclical testing of compliance rule using schedules. This finds all the rule violations that result from the request.

It is possible that under the following conditions, rule checking identifies a rule violation where one does not exist:

  • Two products violate one rule when they are assigned at the same time. The product requests are, however, for a limited period. The validity periods does not overlap. Still a potential rule violation is identified.

TIP: These requests can be approved after checking by exception approver as permitted by the definition of the violation rule.

The compliance check is not only useful for specifying which rule is violated by a request, but it can also find out which product in the request caused the rule violation. This makes a detailed analysis possible of the rule violation. The request can still be approved by exception approval, the definition of compliance rules permitting. Additional approval steps are added in approval workflows to deal with exception approval.

Conditions for compliance checking requests

  • You can add only one approval step per approval policy with the CR approval procedure.

  • The rule conditions were created in the simple definition.

  • IT Shop properties that are specified for each rule are taken into account in the rule testing. Identification of a rule violation depends on the setting on Rule violation identified.

  • The compliance check should be added as the last approval level in the approval workflow. The subsequent approval levels only get one approval step to determine the exception approver if approval is denied.

Compliance check sequence
  1. If an approval step for compliance checking using the CR approval procedure is found in the request’s approval procedure, all products in pending requests are assigned to the customer. It is assumed that all pending requests will be approved and therefore the customer will obtain all the products. The current request is then analyzed with respect to potential violations against the defined rules.

  2. If no rule violations are found, the approval step is automatically granted approval and the request is passed on to the approver at the next approval level above.

  3. If a rule violation is detected, the request is automatically not granted approval. The request can still be approved by exception approval, the definition of rule violations permitting.

For more information about compliance checking, see the One Identity Manager Compliance Rules Administration Guide.

Detailed information about this topic

Identifying rule violations

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.

Specify which violation should be logged for the rule by using the Rule violation identified IT Shop property.

Table 45: Permitted values
Value Description

New rule violation due to a request

Only rule violations that are added through approval of the current request are logged.

Unapproved exception

Rule violations that are added through approval of the current request are logged. Already known rule violations that have not yet been granted an exception are also logged.

Any compliance violation

All rule violations are logged, independent of whether an exception approval has already been granted or not.

This value is automatically set when the Explicit exception approval option is set.

If the QER | ComplianceCheck | EnableITSettingsForRule configuration parameter is not set, new rule violations are logged through the current request.

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

Related Documents

The document was helpful.

Select Rating

I easily found the information I needed.

Select Rating