Application Role Design

Last modified 03 Jun 2022 15:18 +02:00
This page is work in progress.

This document describes example of attributes that should be defined for the application 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.

The attributes of the role are separated to business description, technical details and additional configuration.

  • business description - the data that will be visible to end-users in midPoint GUI

  • technical details - what the role assignment will perform. The technical provisioning operation.

  • additional configuration - the part of role configuration that can’t be displayed via GUI - only available via XML.

Business attributes:

Business 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

  • Application - link to the application object (the service in midpoint)

  • 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

  • Risk level - numeric value of role risk - free value

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

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

  • Lifecycle state - This is DRAFT - should not be filled by author, 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.

Technical details

Technical details of the role should contain definition of inducement element (but not limited only to this element) of the role. Identification of managed resources, entitlements. Also, this component should contain assignments of some metaroles, if there are any.

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.