Identity is the most basic object in CzechIdM. From the user's point of view, they must have an identity to login to the IdM.
Identity is used for:
Structure of the Identity object:
The basic static fields of Identity object are here
IdmIdentity.
Dynamic fields - Object Identity, supports
EAV attributes that allow the dynamic addition of additional fields.
Roles in CzechIdM are mainly used to assign permissions to the user. By assigning a specific role, the user gets permission to access application agendas. Permissions obtained from role also provide access to specific agenda data (rights on data).
For example, we can have a "Worker" role that allows the user to see only their own profile. We can also have the role a "Leader". This role allows a leader to gain access to the data of his or her subordinates and grants him or her permission to edit it.
In addition to controlling permissions within CzechIdM, it allows the role to assign and manage an account on an end system. An example is the "LDAP" role, the assignment of which results in an account being created on the LDAP end system.
Role is used for:
Assigns permissions on agendas and their data in CzechIdM. A detailed description of the permissions, including the configuration example, is
here.
Assigns an account to the end system. More specifically, it defines the link between the role and the system. Allows overloading mapped system attributes. An example of how to create link a role-system and how overload the default attributes is
here.
The role can be assigned
manually (user request) or automatically.
Automatic role assignation is based on tree structure (usually on organizational structures). This means that if the identity is assigned to the tree structure to which the automatic role is attached, this role will be assigned to identity.
Structure of the Role object:
The basic static fields of object Role are here
IdmRole.
Dynamic fields - Object Role, supports
EAV attributes that allow the dynamic addition of additional fields.
This binding object defines a contractual identity relationship. A typical example is when the user has a contract in the company. This contractual relationship defines its name (position name), position in the organizational structure, and the validity of this contract. The relationship also determines who is the leader and subordinate. The leaders for the contract may result from the position in the organizational structure. Leaders can also be manually defined directly for the contract.
An important one is that all assigned roles of an identity are always assigned through a contractual relationship. In general, each identity has at least one contractual relationship. This feature allows for effective identity control (after the expiration of the contractual relationship, appropriate permissions will also be removed).
Example: We have a "john.doe" user who has two jobs in the company (two contracts). The first working relationship is a "doorman", this job has no subordinates. The second working relationship is the "chief caretaker" who has 5 subordinates.
As a result, the identity of "john.doe" ends up having two contractual relationships created. The first one was called "doorman", the second was called "chief caretaker". Both are then linked to the tree of the organizational structure. This will result from both the leaders and the subordinates. For each contract, appropriate roles are created to grant permissions to the user. For example, if the second job ends, only the permissions that belong to that relationship are removed.
Contract relation is used for:
Define identity contractual relationships. See more
here.
Assigns (controls) identity rights. All assigned roles are linked through a contract.
Defines leaders and subordinates by assigning identity (contract) to a specific tree node (typically a tree of organizations).
Assigns permissions based on tree node binding. If the tree node has automatic roles defined, these roles will be assigned after the creation of the contract. See more
here.
Defines leaders by direct link to the contract. This allows you to manually define a leaders.
Structure of the Contract relation object:
-
Dynamic fields - Object Relation, supports
EAV attributes that allow the dynamic addition of additional fields.