Business Role Design

Last modified 31 Jul 2022 19:09 +02:00

This document describes example of attributes that should be defined for the business role. This does not represent visual display of the role, nor all the attributes. Attributes are not named exactly according to elements in midPoint schema. The document is showing more a user’s point of view.

The attributes of the role object should follow the midpoint schema, and may be expanded by additional attributes.

Almost all attributes of the role should be visible to end-users via GUI. Only exception is the additional configuration - the part of role configuration that can’t be displayed via GUI - only available via XML.

Application role display

Please take this picture just as inspiration, not all attributes are shown.
Attributes:

Description of the role should be defined here. It should contain any "user readable" element of role object (not limited to attributes listed below).

  • Role name - the name of the role

  • Description - free text - description of the role for end user

  • Documentation - free text - documentation of the role - for administrators and Role manager - not visible via self-service gui

  • Role type - link to some possible additional archetype(s) for managing roles

  • Environment - Environment for which the role is designed. This attribute makes sense when midpoint manages multiple environments in one implementation.

  • Owner - link to the midPoint user - acting as an owner

  • Access level - business description of the access risk. The values may be Standard user / Power user / Privileged user. In some environments this attribute may be computed based on content of the roles assigned in the business role.

  • Risk level - numeric value of role risk - value. In some environments this attribute may be computed based on content of the roles assigned in the business role.

  • Requestable - whether the role is requestable - Yes/No

  • Approval policy - link to predefined approval policy - app. admin should just select from existing approval policies.

  • Roles included - all roles that are in inducement element of this role. This is the list all roles that will be assigned to the user when he obtains this role.

  • Lifecycle state - This is DRAFT - should not be filled by author, being set during the process

  • How to use - free text - information for end user, that he can obtain via e-mail when the role is assigned to him - how to start with the role. Here may be URL to the application and some additional steps if these are needed.

  • Validity period - if the role validity should be limited, then it should be defined here.

  • Automatic assignment - the rule for automatic assignment (autoassign element) should be defined here. This is business policy of automatic roles assignment and should be visible to users.

  • Assigned in - all roles that the role is being assigned in. This is read only (computed) display.

Additional configuration

Not everything may be designed via GUI, so there should be an option to configure the details via XML. If such modification is performed (any element that is not displayed via UI), then notification that additional configuration is present should be displayed.