Automatic roles

Automatic roles

To be revised

Users get these roles automatically based on their attributes or placing them into organizational structure. Defining or updating an automatic role is a subject of the approval process.

Types of automatic roles

Automatic roles assigned by organizational structure

These are roles assigned based on their placement in the organizational structure. Every identity in CzechIdM has an implicit relationship (~CR) that is tied to a component of the organizational structure.

Linking a role to the organizational structure

Everyone permitted to edit a role can assign this role to a component of any organizational structure. The assigning/removing is subject to approval in the same way as if an ordinary user was assigned the given role. The approval of role assignment sets off a sort of "pre-approval" for all the users embedded in the organizational structure. From then on, assigning a role to a user does not require special approval (it has already been approved for the organizational unit in which a user is located).

Displaying information about automatically assigned roles

Displaying information about the roles linked to the organizational structure will occur at least in the following places:

In the structure component detail, there is a list of roles which have been assigned to it
For each role, a list of structure components (the whole path in the tree) for which this role is used for automatic assignment to a user is displayed.
For each user, there is a list of assigned roles they have been granted automatically.

Automatic roles by attribute

Automatic roles by attribute are similar to automatic roles by organizational structure. For automatic roles by attribute, one cannot update them and change the name attribute. When setting up an automatic role by attribute, you fill in the required fields:

  • name - the name of the automatic role by attribute, and
  • role - the role that will be assigned after pass rules.

If you mark a role as a concept – using a flag – this signals that the automatic role by attribute is not to be recalculated for users.

Rules for automatic roles and AND operator

For all automatic rules is allowed use only short text EAV attributes. Please in older version IdM is possible use another attributes like datetime, entity and etc. as attribute for compare. Please don't use this attributes.

For Mssql (sql server) and IdM < 10 doesn't work comparison for boolean data type. For this database works only shorttext (string).

At the moment, individual rules for automatic roles by attribute can be linked only with AND operator. If you still want to read more on this topic, go to the devel section here.

After saving identity (save from identity detail) it will be done recalculation for all automatic roles that have at least one rule with type IDENTITY, recalculation from identity is done for all contracts for saved identity. After saving contract extended attributes (save from extended attribute detail) it will be done recalculation for all automatic roles that have at least one rule with type CONTRACT_EAV.

Approving automatic roles definition

Automatically assigned roles have a significant safety impact.

Processes of defined by the role criticality is defined here. Only processes approve-role-by-guarantee and approve-role-by-guarantee-security supported approving for automatic roles.

Some processes used to approve role assignments to a user may not support approving changes to automatic roles (for example, approval by the supervisor). In this case, the default process is used (approval with role guarantee).

The process supports automatic roles when it has the variable "supportsAutomaticRole* set as true".

Request approver

If you want an identity to be able to approve automatic role requests, you can use the IdmAutomaticRoleRequest|Read|AutomaticRoleRequestByWfInvolvedIdentityEvaluator authorization policy evaluator. This evaluator grants the user permission to read requests (in WF task), which can be approved by logged identity. It's a good idea to have autocomplete permission to IdmAutomaticRoleAttribute and IdmRoleTreeNode.

moreover, the user should have other permissions like:

Permission to all requests: Requests for automatic roles (IdmAutomaticRoleRequest) | Admin | BasePermissionEvaluator
Permission to all requests rules: Requests for automatic roles (rules of the attributes) (IdmAutomaticRoleAttributeRuleRequest) | | AutomaticRoleRuleRequestByRequestEvaluator
Permission to read all exists automatic role by attributes: Automatic roles (attributes) (IdmAutomaticRoleAttribute) | Read | BasePermissionEvaluator
Permission to read all exists automatic role rules by attributes: Rules for automatic roles (attributes) (IdmAutomaticRoleAttributeRule) | Read | BasePermissionEvaluator
Permission to read all exists automatic role by tree: Automatic roles (organization structure) (IdmRoleTreeNode) | Read | BasePermissionEvaluator

Automatic roles assigned by an end system

(to be completed)

Requests for change automatically assigned roles

Automatically assigned roles have a significant safety impact. When creating, editing, or deleting, it is necessary that the process is approved. For this purpose, an agenda for requests for change of automatic roles have been created.

This request gets the approval process from the criticality defined for that role. Critical role determines what process the application must accomplish to implement it.

Processes of defined by the role criticality is defined here. Processes for approval change of an automatic role are different then processes using for approving assign role to one user. For clarity, both processes (role assignment, change of the automatic role) are defined in one final process.

Table of Contents