Table of Contents

System

The CzechIdM system determines the behavior towards connected end systems.

The system allows:

Creating a copy of a system

The system in CzechIdM can be duplicated. The duplicate contains the entire system configuration:

The system name must be unique, so a unique name is generated when duplicating. For example, if you duplicate a system named LDAP, then the resulting system is Copy-of-LDAP. If this system already exists, then a number postfix is added (Copy-of-LDAP1) and etc.
A newly created duplicate is always set as an inactive system (with provisioning queue available). Likewise, all possible sync settings are set to inactive (with provisioning queue available).

End systems connected to CzechIdM

Systems get connected to IdM through synchronization and provisioning operations.

Steps to connect a new system:

  1. a new system named Name-of-your-choice must be created
  2. you choose a suitable database connector for it
  3. you need to set the connector up
  4. create a system scheme: either manually, or it is returned by the connector. In doing so, you get all the attributes available in the system
  5. then, map all these attributes. This serves two basic purposes:
  6. makes the scheme attributes accessible to the IdM system-users
  7. defines which value the attribute is to be mapped into in the IdM system (identity, group, extended attribute, hidden attribute).
  8. for optimalization purposes, an attribute can be cached. New attribute mapping is marked as 'cached' by default.
  9. in order to create an account for this user in the end system,


Synchronization

The basic task of synchronization is to ensure the correct state of the data on the end system (typically, users accounts) and in IdM. The correct state is defined both by the data in IdM (account management) and by the IdM configuration itself. This is usually taken care of by setting provisioning and synchronization on a given system.

Entities that support sync

Name Entity name (DTO) More details
Identity IdmIdentityDto synchronization
Contractual relationship IdmIdentityContractDto relation-sync
Time slices of contractual relationship IdmContractSliceDto contract-slice-sync
Tree IdmTreeNodeDto tree-sync
Role IdmRoleDto role-sync
Role catalogue IdmRoleCatalogueDto

A typical synchronization process runs as follows:

During synchronization, identities can be evaluated for different situations they find themselves in, namely:

- (non)-existent links
- (non)-existent entities
- (non)-existent accounts

More on this topic later.

Synchronization/provisioning strategies

An attribute mapping strategy defines how attributes, and particularly their values, will be handled during provisioning and synchronization.

Here’s a list of strategies to consider:

The WRITE-IF-NULL strategy has a lower priority than SET, MERGE and AUTHORITATIVE_MERGE. Therefore, if we define one attribute with the SET strategy and another one with the WRITE-IF-NULL strategy in the default mapping on the system, then the value of the WRITE-IF-NULL attribute is never used. In this case, it is advisable to define the attribute with only the WRITE-IF-NULL strategy in the default mapping. The other attribute with the SET strategy will have to be defined in the role as an overload of the default attribute.

The CREATE strategy has a lower priority than WRITE-IF-NULL, SET, MERGE and AUTHORITATIVE-MERGE.

A situation where there are two overloaded attributes for the same default attribute, one having the AUTHORITATIVE_MERGE strategy and the other the SET or MERGE strategy, will not be valid. Such a situation is collisional and will result in an exception during provisioning!
Both the MERGE and AUTHORITATIVE_MERGE strategies can be linked only to a multi-value scheme attribute!

Additional characteristics of strategies

Aside from a strategy, every attribute can also have the indications Always send and Send only if IdM value exists. These indications can be combined with all the above strategies.

Password for confidential storage

In previous IdM versions (>7.6.0), confidential storage may store passwords for remote connector servers for systems that don’t exist. If you encounter difficulties with stored passwords you can remove these values by a database query. From version 7.6.0 onwards, all values from the confidential storage are deleted once a system has been removed.