Roles

A role in CzechIdM is an entity representing a set (1 or many) of permissions/privileges on the end system or in CzechIdM itself. Users acquire roles:

• automatically – according to the organizational placement
• manually – through assigning based on the user’s request in the CzechIdM self-service or by a CzechIdM administrator.

From the perspective of the identity manager, it does not matter whether the user acquires an account in a specific application, is placed in a group in LDAP, his indication is set to “can use VPN”, or a permission is set for him in the application. In all the cases, a role is assigned. A simplification carried out like this allows general rules to be applied for assigning all types of permissions (~roles) in the same way.

To create a new role, go to Role agenda and Role management tab, then click Add. A unique name for the role must be chosen within all the roles. The role can also be placed in one or more folders in the catalogue of roles.

Každá role může mít nastaveno, kdo je jejím garantem, na garanta se mohou vázat další události jako například schválení přidání role, změna platnosti a její odebrání. Více viz sekce schvalovaní rolí.

A guarantee can be set for every role. Other processes can be related to the guarantee such as approval of assigning a role, change in time validity and its removal from user. See more in the section about role approval.

The following attributes can be set with every role:

• Role name – a required unique attribute. The role name is displayed in the majority of GUI forms.
• Role type – a descriptive attribute, it does not influence working with roles at the moment.
• Priority level
  • Determines the approval agent of assigning and removing of a given role.
  • During provisioning (writing of data to the end system), a one-value attribute is filled with a role with higher priority
• Priority – read only, a numerical representation of the priority level.
• Catalogue folder – every role can be placed in the role catalogue, which is meant for organizing them.
• Role authorizers – a role guarantee is an identity responsible for managing the role, i.e. they can see them in the role list (Role tab) and are able to act as approvers of assigning/removing of a role (depending on the configuration of the priority level)
• Role removal approval – if this box is checked, then removing of the role is approved according to the process set in the configuration of CzechIdM. The default selection of CzechIdM configuration for the approval process of removing roles is Approval by role authorizers. Therefore, by checking this box without further configuration, removing of the role from the user will be approved by the role authorizers.
• Description – an additional description of the role.
• Inactive – Inactive roles are displayed in grey colour in menus and users are forbidden to select them, i.e. they cannot be requested for, for instance.

After all the requested selections have been entered, click on Save and continue. This will bring you straight to the menu Role → Role management, specifically to the detail of the newly created role.

Extended role attributes can be edited in the tab More information. A separated chapter is thia guide is dedicated to extended role attributes.

Role permissions – Permissions of a given role for administrator actions in CzechIdM are defined in the tab Permissions. A permission for CzechIdM is not necessarily defined for every role.

To add some permissions for actions in CzechIdM to a role, click the button Add. The following attributes can then be worked with:

The following attributes can then be worked with:

• Role (Read Only) – the name of the role, whose permission for CzechIdM you would like to change.
• Entity type – A form in GUI of an object type in CzechIdM, for which you would like to edit the permission. For example, to add the permission to display the audit logs to the holder of the role, select the item Audit.
• Permission – The type of permission which you would like to assign to the holder of the role for an agenda / entity selected in the previous step. The typical permissions are reading/removing/creating etc. Some agendas, such as Audit, do not allow any selection of permissions (it is read-only), that is why this box can be in grey colour as well.

  • Order – If the user has more permissions from more roles, the order is determined by the order of evaluations of these permissions. The logical principle of or is applied. If the user has role A, which permits reading subordinates, and role B, which permits editing subordinates, then the user has both the permission to read as well as to edit his subordinates. However, the permissions can be restricted using an evaluator in the next attribute Evaluation type. In that case, the order set in this attribute will be applied.
  • Description – an optional description
  • Inactive – a permission marked in this way will not be valid after saving. This selection is used mainly when you would like to prepare a set of permissions with a future starting date of validity, for example.
  • Evaluator type – This item is sometimes called the evaluator as well. Evaluators are used to delimit a group of objects (Agenda / Entity type), for which the holders of the role get a permission. If the chosen entity type is Users (IdMIdentity), then e.g. SubordinatesEvaluator can be chosen and role holders will get persmission to manage their subordinates. Some entity types, e.g. Audit, do not allow selecting Evaluation type since they relate directly to a given form in GUI or object instance.

The tab Automatic roles allows integrating a given rolen into an organizational tree. This means that the role will be assigned to and removed from users based on adding/removing of a user to/from the organizational tree structure. The automatic roles agenda displays the current list of tree structure elements (organizations) in which the currently edited role is set as automatic role.

A new automatic role can be created by clicking the button Add. The following parameters of automatic roles can be set.

• Role (read only) – role name
• Tree structure element – it defines a point in the organizational structure where the role will be placed
• Recursion type – denotes the ability to assign the role in the tree:
  • Without recursion – the role will be given only to the users whose contracted position is situated on the same element of organization as the role.
  • Down by structure - the role will be given to all the users whose contracted position is situated on the same element of organization + of all structure elements below. For example: Assigning a role to the highest point of the organizational structure (to the “top”) will result in assigning of the role to all users in the whole organization structure.
  • Up by structure - the role will be given to all the users whose contracted position is situated on the same element of organization + of all structure elements above it.

The validity of user's contracted position is checked when integrating the user into the organization structure. If the user’s contracted position is not valid (according to the contracted position's attributes Valid from and Valid till), then

• the role is assigned, if the validity of the contracted position starts in future. In fact the "role to user" validity (other validity then contracted position validity) applies the same time the contracted position starts. In other words if the role e.g. gives the user account in MS AD, the account is not created untill the contracted the role is assigned to starts.
• The role is not assigned, if Valid to of the relation is in the past, i.e. automatic roles are not assigned if the contracted position has already ended.

If the validity of the user’s contracted position, for which he has been assigned an automatic role, changes, then the validity of "role to user" relation changes as well. This ensures that, at the beginning or the end of the contracted position, the role will always be removed or added regardless of how the validity has been changing in course of time.

If a role is added as automatic into a structure where there is already a user, the user will be assigned this role immediately. On the contrary, if an automatic role is removed from a structure where there is already a user, it will be removed from these users immediately.

There are several ways of role assignment in CzechIdM. This chapter describes the manual process of role assignment

• by the administrator – Users menu → User detail (magnifying glass symbol) → Roles. Click the button Manage authorizations.
• by a user itself – Profile → Roles. Click the button Manage authorizations.
• by the user's manager (if a permission is set) – Profile → Subordinates → User detail (magnifying glass symbol) → Roles. Click the button Manage authorizations.

In each of the previous points, a Change permissions request is created. CzechIdM contains a process, which ensures approving of this request in the following steps:

• Helpdesk – the whole request is approved by holders of the role designated for helpdesk department representatives. The specific name of the role is defined in CzechIdM configuration under the property idm.sec.core.wf.approval.helpdesk.role.
• User manager – the whole request is approved by holders of the role designated for helpdesk department representatives. The specific name of the role is defined in CzechIdM configuration under the property idm.sec.core.wf.approval.manager.role.
• Manager – approved by managers of the user for whom the role is requested. Managers are not defined by a role as in the previous steps but they are calculated by all user’s contracted positions. Any manager can approve. In applications where the approval of specific managers according to individual contracted position is needed, we recommend disabling this step in configuration and set approval by managers to be operated by the criticality of roles - see the next step.
• Roles Criticality – The whole request disintegrates in this step. Every role which the request was composed of is now approved individually. The way of approving of each role is determined by the settings of each one. More specifically, the attribute Criticality is set for each role. Only after of all individual roles assignment is resolved (approved/denied) does the process continue into the following step.
• Security – The request formed again by all the roles approved in the previous step is now approved by the holders of the role which is defined in CzechIdM configuration under the property idm.sec.core.wf.approval.security.role. If a role has been denied in the previous step, it is not present in the request in this step.

In steps 1, 2, 3, and 5, the request is approved as whole; i.e. all roles approved in the previous steps proceed into the next round of approval. In the approval rounds 1, 2, and 3, the realizator can return the request for a revision, deny it, or approve it. If the approving agent returns or denies the request, the requesting agent is notified about it. After the request has been successfully approved in last round, a notification is generated which show the resulting state of the request, i.e. which roles have been approved and which not.

Enabling or disabling of these approval rounds (as well as the definitions of role names for the individual approving rounds) can be configured in the configurational file application.properties or by an explicit entry in the tab Settings → Configuration:

• idm.sec.core.wf.approval.helpdesk.enabled – true/false, enabling or disabling of approval by helpdesk (role),
• idm.sec.core.wf.approval.manager.enabled – true/false, enabling or disabling of approval by manager (role),
• idm.sec.core.wf.approval.usermanager.enabled – true/false, enabling or disabling of approval by user's manager,
• idm.sec.core.wf.approval.security.enabled – true/false, enabling or disabling of approval by security.

The main process of a permission change can disintegrate into smaller subprocesses depending on the application settings. Under the menu item Settings → Configuration, properties of the form idm.sec.core.wf.role.approval<1-5> can be set. The value of each property is the name of the workflow which approves the given criticality level.

The basic workflow names are: approve-role-by-guarantee (approved by the guarantee of the role), approve-role-by-manager (approved by the manager of the user for whom the role is requested).

Approval of individual roles which were requested within the main process is now realized in the subprocesses. This approval is done asynchronously for all roles. The main process is resumed after finishing the last subprocess (be its denial or approval).

On role detail tab panel, there is tab called Accounts as you can see in the screenshot below. When you access this page, it will show all accounts which were created by provisioning of some system which has mapping for Roles.