9.3:documentation:identities

Identities (users)

In identity management an identity is a set of informations that describes a real person. Some of the information like First Name, Last Name, Login or Password are crucial for many IT systems, since they process them, or e.g. use them for authentication or authorization. Identity management systems process the data related to identity, transform them and use them to manage accounts on connected systems.

 Identity in identity management

The representation of a user in CzechIdM system is an entity called identity. Put simply, an identity can be described as a user registered in CzechIdM with all his attributes e.g. first name, surname, phone number, etc. The identity representation is rather complex discipline. To be able to handle automatic identity lifecycle processes CzechIdM presents other entities with attributes that have a relation to an identity. Those are Contracts, Roles and Tree nodes forming Tree structures.

 Entities relations

The relation of identities in CzechIdM with a company or organization is represented by an entity called contract. A contract can be imagined as:

  • job contract for work – employees
  • study – pupils/students
  • contract/arrangement – external co-workers
  • etc.

A user can have many contracts. A contract is in relation with other objects in CzechIdM:

  • Identity – described above
  • Tree structure – a contract can be added to a tree (organizational) structure, which effectively allows integrating the user into a hierarchical division in an organization.
  • Roles – roles in CzechIdM are assigned to contracts, i.e. a user gets roles through their contracts. Due to this, all manually created identities can (application option) have one automatically prepared contract called Default.
Every active user should have their contract. Via contracts Roles are assigned to users and users are placed into Tree structure (working position)

Identity life cycle is controlled by state. State is changed automatically by system - when identity is created, contract to identity is added or removed etc.

Identity states:

  • created - identity is enabled. State is assigned to newly created identity.
  • no contract - identity is disabled. Identity doesn't have a contract. All contract were deleted.
  • future contract - identity is disabled. Identity has valid contract in the future, but not now.
  • valid - identity is enabled. Identity has valid contract.
  • left - identity is disabled. Identity has invalid contracts only.
  • disabled - identity is disabled. Identity contracts are excluded.
  • disabled manually - identity is disabled manually, e.g. by administrator / synchronization. Manually disabled identity can be enabled manually only again.

When identity starts to be valid (some of their contract starts to be valid) and identity has account at least on one target system, then new password is generated and changed on all identity's accounts ⇒ identity will have the same password in all accounts. Notification (see acc:newPasswordAllSystems template) is send to identity about new password on which accounts were changed.

Time slices of contracts

On many projects, we encounter a source of data about users, employees or org. structures that work with so-called time slices. For better works with this time slots, agenda of contract's time slices was created.

The basic idea is that time slices are stored in a self-contained agenda. This agenda only contains time slices for identity contracts. If a given slice is currently valid, its values will be copied into the linked identity contract. Every day a scheduled task is performed, which calculates whether another slice is valid. Such a slice becomes currently used as a contract (its values are copied into the contract).

In one day only one slice per one contract may exist. Every slice must contain all contract data. Slice is a snapshot of a contract!

See more information about contract time slices in the develop guide here .

Sometimes there may be a situation where one of the time slices ends the contract, and at the same time there is a next time slice that restarts this contract. If there is no gap between termination and restart, then the contract will not terminate (no accounts will be deleted). If the dates do not follow, then (by default) will be contract terminated and all connected accounts will be removed from the target systems.

However, in some situations (projects), a protection period is required during which the contract will not be terminated, provided that there is a next slice in the contract, which restarts the contract. Furthermore, the gap between the termination and the beginning of the contract must be less than or equal to the protection interval.

See more information about this protection in the develop guide here .

Read more