Request access

Last modified 16 Oct 2023 12:32 +02:00
Since 4.6
This functionality is available since version 4.6.
Table of Contents

Request access functionality is a complete rewrite and redesign of midPoint role requesting UI.

New UI takes form of proper wizard with up to four steps:

  • Person of interest

  • Relation

  • Role catalog

  • Shopping cart (checkout)

First two steps may be hidden, or skipped based on configuration or authorizations of user that is currently logged in.

Configuration and some examples can be found here.

Person of interest

Person of interest
Figure 1. Person of interest

First step of request access wizard allows user to choose one or more users for whom new roles will be requested. There are two type of tiles:

  • Myself - to select user currently logged in

  • Group - defined by collection or query filter. Group allow to select one or more users via autocomplete text field or by clicking Select manually button.

Autocomplete search withing group is done using user/name property with norm poly-string matcher by default.

Concrete search behaviour can be customized using group/searchFilterTemplate where filter with expression can be used. Search result labels can be also configured using expression defined in group/userDisplayName. Minimum number of characters needed to start autocomplete can be configured using group/autocompleteMinChars.

Since 4.8 search behaviour configuration was moved to autoCompleteConfiguration configuration option.

In following example filter template will create substring search givenName like '%King <VALUE>%'. Results will be displayed in format <USER_NAME> (<USER_OID>)

<group>
    <searchFilterTemplate>
        <q:substring>
            <q:path>givenName</q:path>
            <expression>
                <script>
                    <code>
                        return "King " + input
                    </code>
                </script>
            </expression>
        </q:substring>
    </searchFilterTemplate>
    <userDisplayName>
        <script>
            <code>return basic.stringify(object.name) + " (" + object.oid + ")"</code>
        </script>
    </userDisplayName>
    <autocompleteMinChars>2</autocompleteMinChars>
</group>
Selection from group of users
Figure 2. Selection from group of users
Manual selection from group of users
Figure 3. Manual selection from group of users
User selected
Figure 4. User selected

If user can request only for himself then this step is not visible (and skipped). Restarting Request access wizard and going through Person of interest step again will overwrite previously selected users.

Relation

Relation
Figure 5. Person of interest

Second step of wizard requires user to choose relation which will be used for new roles. List of relations is based on static relations and relations defined in system configuration. Default set of relations is:

  • Default

  • Manager

  • Approver

  • Owner

Set of relations, their label and icon can be configured, see Relations and Configuration.

If there’s only one relation to be selected, then this step is not visible (and skipped).

If relations are handled only implicitly via authorizations, then relation step will be visible at least when wizard is initialized. Reason for this is that until user selects at least one user (person of interest), midpoint is not able to compute available relation list and therefore can’t decide whether relation step can be hidden.

In case relation step should be hidden at all times, please configure defaultRelation and allowOtherRelations=false in request access configuration.

Role catalog

Role catalog
Figure 6. Role catalog

Role catalog displays roles (also organizations and services) that can be assigned to list of users defined earlier. Catalog can be currently displayed in two ways:

  • Tiles (picture above)

  • Table (see picture below)

Role catalog in table
Figure 7. Role catalog in table

Both types of view can be enabled or disabled via configuration. Menu in role catalog consists of 3 types of items also defined in configuration:

  • Role catalog defined via org. structure

  • Collections of objects

  • Roles of teammate

Role catalog

Role catalog is defined via reference to organization tree. Org. tree is then used to load hierarchical menu. By default, up to 3 levels, all roles on deeper levels are shown in that 3rd level menu. Assignable roles have to be part of this org. tree.

In 4.8 or later number of levels can be configured using roleCatalogDepth configuration option.

Collection of objects

Collection of objects can be used to create custom menu item representing specific set of object via reference to object collection or using query filter.

Roles of teammate

This is custom menu item that uses search for another user and list his assignments. Roles of teammate option can be disabled via configuration.

Search for teammate will by default create filter using user/name property with norm poly-string matcher by default.

Since 4.8 search behaviour can be customized using autoCompleteConfiguration configuration option.
Roles of teammate
Figure 8. Roles of teammate

Shopping cart (checkout)

Shopping cart (checkout)
Figure 9. Shopping cart (checkout)

Last step in request access wizard is checkout. In this step user can finalize whole request, review and solve conflicts if necessary. If configuration allows comment for this request can be added also with custom validity period for requested items. This can be done either globally for whole cart or for each item separately.

Conflict solver

List of conflicts
Figure 10. List of conflicts
Solved conflicts
Figure 11. Solved conflicts
Edit shopping cart item
Figure 12. Edit shopping cart item
Was this page helpful?
YES NO
Thanks for your feedback