Tchater maintenant avec le support
Tchattez avec un ingénieur du support

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

Renewing requests

The request recipient receives a message before reaching the expiry date and has the possibility to extend the period. For more information, see Sequence for limited requests. The request is canceled once the expiry date has been reached.

The customer has the option to renew a request. If the customer uses this option, the extension (as in the original request) needs to approved through an approval process. The renewal workflow stored with the approval policy is used for this purpose. If the extension is denied, the original request runs out at the given date. You can also limit renewals in the same way. The renewal's expiration date is calculated from the date of the renewal's approval and the validity period of the product if no Valid until date was specified at the time of the renewal.

A limited request might look like the following a sequence:

Service item Validity period: 90 days
Requested on: 1/2/2017 Valid until: 4/1/2017 11:59 PM
Approved on: 1/5/2017 Valid until: 4/5/2017 11:59 PM
Renewed until: 3/31/2017 Renewal valid until: 4/30/2017 12:00 PM
Approved on: 4/2/2017 Valid until: 4/30/2017 12:00 PM
Canceled on: 4/10/2017 Unsubscribed as from: 4/14/2017 11:59 PM
Approved on: 4/11/2017 Valid until: 4/11/2017 11:59 PM

NOTE: Ensure that times in the One Identity Manager tools, for example, the Web Portal, are in the user's local time.

Related topics

Canceling or unsubscribing requests

DBQueue Processor checks whether the request's expiry date has passed using a scheduled One Identity Manager task, which compares it against current UTC time. If the expiry date has passed, the request is canceled; the resulting assignments removed. You can configure this behavior.

If necessary, temporary requests can be unsubscribed. If the expiry date has passed, the unsubscription workflow stored at the decision guideline is run in this case. The unsubscription must be approved; only then will the assignment be permanently removed. If another request exists for the product, perhaps with the status Pending, the expired request will be canceled and replaced by the pending request.

To unsubscribe temporary requests on expiry

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

If the configuration parameter is set, requests with the status Assigned or Renewal will be unsubscribed. The unsubscription workflow entered in the approval policy runs through if no other request exists for the product, which now takes effect. Once the unsubscription is approved, the assignment will be removed. Expired requests with the status approved, pending, request are canceled.

NOTE: If the unsubscription is denied, the approver must enter a new Valid until date. Otherwise, the request is given Assigned status and the unsubscription workflow runs again.

Related topics

Checking request validity periods

If a customer has requested a product with a limited validity period, the validity period must be tested for validity in subsequent requests for this product for the same customer. If the validity period is not in effect, the request is not permitted. By default, new requests are permitted if they fall in a time period that is not covered by another pending request. However, the validity periods of different requests may not overlap. You can define the desired behavior for the validity period over configuration parameters. The configuration parameters are set by default. In this check, all requests of the same product for the same request recipient are taken into account even if the product came from different shelves.

To define differing behavior

  • In the Designer, enable the desired option for the QER | ITShop | GapBehavior | GapDefinition and QER | ITShop | GapBehavior | GapFitting configuration parameters.

Table 54: Effect of the QER | ITShop | GapBehavior | GapDefinition configuration parameter

Option

Description

0

Only pending requests are taken into account by the check. (default)

1

Only approved requests are taken into account by the check.

2

Only assigned requests are taken into account by the check.

Table 55: Effect of the QER | ITShop | GapBehavior | GapFitting configuration parameter

Option

Description

0

Validity periods can overlap. (default)

A new request is accepted if its validity period fits into at least one free time slot between two existing requests.

1

Validity periods cannot overlap.

A new request is accepted if its validity period fits exactly into a free time slot between two existing requests.

2

The validity period is not checked.

A request is accepted even if there is already a request for the same validity period.

If the configuration parameters are disabled, One Identity Manager behaves as in option 0.

Figure 10: Example of possible validity period for GapDefinition = 0 and GapFitting = 0

Figure 11: Example of possible validity period for GapDefinition = 1 and GapFitting = 1

Related topics

Relocating a customer or product to another shop

If a customer requests a product from a shop or shopping center and then changes to another at a later date, the product request is closed and the product is canceled. The same applies if a requested product is moved to another shelf.

You can label product service items with Retain service item assignment on relocation to retain their requests when they relocate. All pending or approved requests in the shop are transferred to any shop in which the employee is a customer and that contains the requested products. In connection with this, pending requests are reset, which means the requests have to go through the approval process from the beginning again.

Detailed information about this topic
Related topics
Documents connexes

The document was helpful.

Sélectionner une évaluation

I easily found the information I needed.

Sélectionner une évaluation