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 of the identity, identity or contract attributes
• manually – through assigning based on the user’s request in the CzechIdM self-service or by a CzechIdM administrator.
• by business role - roles (sub) can be assigned automatically, when other role (superior) by defined role composition is assigned manually or by some automatic role.

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.

Roles are assigned to users via their contracts. If a contract is not valid (time validity) the roles on the contract are removed. In other words, the identity loses roles permissions in IdM and rights in connected systems.

Role with the same base code could be created from / for different environment. Final role code is combined from the base code and environment identifier. When role is created (or synchronized), then role attributes can be used:

• baseCode - base code without environment. If environment is not used, then baseCode value is the same as code value, e.g. roleOne
• environment - environment identifier, e.g. dev.
• code - complex code. If environment is not used, then baseCode value is the same as code value, otherwise complex code is combined from base code, environment and joined with separator (| by default). For example roleOne|dev.

One of the many strengths of CzechIdm is that it enables you to create and administer a whole array of finely tuned roles with varied levels of access to the application, assigning different rights to different users. There are three main ways to restrict or broaden users’ permissions, namely setting up:

• accessible agendas (parts of IdM or types of entities)
• scope of activities within these agendas (authorizations)
• data range allowed (through selected data evaluators)

A permission for CzechIdM is not necessarily defined for every role. A permission is, for example, READ on USERS. A user having a role with this specific permission can see the read-only detail of all identities in CzechIdM.

Every role can be assigned a level of criticality: who approves its assignment. Criticality ranges from 0 to 5.

Business roles (composition) can be defined on role detail. Business role could contain sub roles - all sub roles are assigned automatically, when business role is assigned to identity. Sub roles has the same validity as business role. When assigned business role is removed from identity, then all sub roles are removed automatically too. Sub roles are processed on the background asynchronously (by processors), only business roles (⇒ direct roles) are assigned synchronously. Sub roles defined by business roles are recalculated on the background (by long running tasks), when business role definition is created or removed - sub roles are assigned to identities, which already owns business (or any superior) role.

The role can be linked to a Tree structure (e.g. position in organizational structure). That role is assigned to and removed from a user based on adding/removing the user (via their contract or other contract position) to/from the organizational tree structure. If a contract is not valid yet, roles are assigned but are disabled until the contract starts.

The role can be also linked with value in attribute (value can be stored in Identity, Identity extended attribute, Contract and Contract extended attribute). That role is assigned to and removed from a user based on the value in the specific attribute. Recalculating of this automatic roles is done after saving identity, identity extended attribute attributes, contract and contract extended attribute attributes. All necessary attributes that defined automatic role by attribute are defined by agenda "Automatic role by attribute".

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

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

• Creating a role
• Defining permissions for a role
• Creating an automatically assigned role by organization structure
• Creating an automatically assigned role by identity attribute

• Role permission mechanism

• Authorization policies
• Automatic roles by organization structure
• Automatic roles by attribute
• Automatic role request