Request access
Many traditional Role-Based Access Control (RBAC) theories seem to be based on assumption that there is some kind of all-knowing authority that knows which user should have which role. This approach works in some kind of organizations, but in reality such organizations are very rare. In practice the knowledge about roles and role policies is not centralized. It is rather distributed among many people in the organization: application owners have part of the knowledge, line managers have more bits of knowledge, other parts are maintained by security officers and other specialists. It is almost impossible to analyze this knowledge and specify it in a form of an algorithm that a machine can execute. In addition to that, such policy is constantly changing. Implementing this a fully-automated system is almost always infeasible.
Therefore, most identity management and governance systems come with an alternative approach: user are requesting role assignment. The request is then routed through an approval process. If the request is approved, then the requested roles are assigned.
However, this approach requires end users to take part in the interaction. End users are usually not experts on RBAC and they do not have comprehensive knowledge about role design and structures used in the organization. Therefore, midPoint has a simplified view of Role catalog that is suitable for end users. The role catalog is used to present the roles in a similar way as an e-shop presents the products. The roles are sorted into categories and sub-categories. The user may browse the role catalog and select the roles.
User interface 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
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.
Autocomplete configuration can be customized using group/autocompleteConfiguration configuration option.
Concrete search behaviour can be customized using autocompleteConfiguration/searchFilterTemplate where filter with expression can be used.
Filter expression should contain input variable which will be replaced by user input.
Such filter will be joined with group defined filter/collection using and operator.
Search result items can be also modified using expression defined in autocompleteConfiguration/displayExpression.
Minimum number of characters needed to start autocomplete can be configured using group/autocompleteMinChars.
Default value is 2.
In following example filter template will create substring search givenName like '%King <VALUE_FROM_AUTOCOMPLETE_TEXT>%'.
Results will be displayed in format <USER_NAME> (<USER_OID>)
<group>
<identifier>kings</identifier>
<display>
<label>Kings</label>
</display>
<collection>
<collectionRef oid="1324096e-3b16-4097-86b2-47c43b1d2ad5" type="ArchetypeType"/>
</collection>
<autocompleteConfiguration>
<searchFilterTemplate>
<q:text xmlns:q="http://prism.evolveum.com/xml/ns/public/query-3">
givenName contains `"King " + input`
</q:text>
</searchFilterTemplate>
<displayExpression>
<script>
<code>return basic.stringify(object.name) + " (" + object.oid + ")"</code>
</script>
</displayExpression>
<autocompleteMinChars>1</autocompleteMinChars>
</autocompleteConfiguration>
</group>
Figure 2. Selection from group of users
Figure 3. Manual selection from group of users
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
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).
List of available relations is based authorizations and first user that was added in Person of interest step.
|
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 |
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)
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
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.
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.
Search behaviour can be customized using autoCompleteConfiguration configuration option, similar to auto-complete in Person of interest step.
Figure 8. Roles of teammate
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.
If there are items in the cart that has to be approved and items that don’t need approval process, then submit behavior can be configured using systemConfiguration/roleManagement/defaultExecuteAfterAllApprovals configuration option.
This boolean flag defines whether all changes are applied after all approvals or items can be assigned immediately if they don’t need approval process.
This flag is global and can’t be overridden via adminGuiConfiguration/accessRequest configuration.
Conflict solver
Figure 10. List of conflicts
Figure 11. Solved conflicts
Figure 12. Edit shopping cart item
Was this page helpful?
YES
NO
Thanks for your feedback