Automatic roles

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.

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.

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 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 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.

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.

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.

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

(to be completed)

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.