Two modes of synchronizationsyncidentity

In case you need to create a more complicated filter criterion, it is possible to use this script. In the example below, you can find the situation when you want to filter by the chosen attribute and operation (the filter enters as variable into the script), but at the same time, you want to limit the result with one more condition. In this case, the condition is that all the results must have the attribute "lastname" equivalent to the "Doe" value.

import  eu.bcvsolutions.idm.ic.filter.impl.IcFilterBuilder;
import  eu.bcvsolutions.idm.ic.api.IcAttribute;
import  eu.bcvsolutions.idm.ic.impl.IcAttributeImpl;
 
IcAttribute attr = new IcAttributeImpl("lastname", "Doe");
 
return IcFilterBuilder.and(filter, IcFilterBuilder.equalTo(attr));

IcFilterBuilder provides the following operations:

• IcFilterBuilder.equalTo(…)
• IcFilterBuilder.contains(…)
• IcFilterBuilder.startsWith(…)
• IcFilterBuilder.endsWith(…)
• IcFilterBuilder.lessThan(…)
• IcFilterBuilder.greaterThan(…)
• IcFilterBuilder.or(…)
• IcFilterBuilder.and(…)
• IcFilterBuilder.not(…)

The output of this script must be an object of the type IcFilter. If the output is null, then the filter will not be applied and synchronization will be launched over all the accounts.

In default state, synchronization can administer the identities (create, update, delete). Yet if you need a more complex solution, e.g. when you need to establish industrial relations, the standard synchronization mechanisms won´t be sufficient.

The solution is to use the own workflow which will perform the required operation (e.g. the creation of industrial relations mentioned above). The workflow can be set up separately for each situation.

If the synchronization finds out that workflow is set up in a given situation, it will launch it. In such case, the synchronization does not do anything with the given account anymore, i.e. all the active operations are performed by the workflow.

The workflow which should be possible to be used in synchronization, must satisfy several criteria. The first one is the category in which the workflow is included.

For synchronization, the workflow further expects the following input variables:

- uid (String),
- entityType (enum SystemEntityType),
+ icAttributes (List of IcAttribute),
- syncConfigId (UUID for SysSyncConfig),
- actionType (String)
- situation(String),
+ accountId(UUID),
+ entityId(UUID)

An example of how such workflow may look like is the following demonstration process (syncActionExampl). This process will establish an approval task for the administrator (admin) for every account of which the UID starts with test. All the other accounts will go through standard implementation according to the evaluated situation and the set-up action. The workflow is also showing that only one process resolving all the situations can exist.

The synchronization logs are divided into three parts:

• SysSyncLog - The main log which is formed after the start of the synchronization. It contains the time of start, time of end, and the log for the whole process. It also contains the information if the synchronization has been launched and if some error occurred.
• SysSyncActionLog - is linked to the main log, categorizing the individual elements according to the action performed. It also contains the number of the iterations performed for each action. The log may attain the following types of actions:

        CREATE_ENTITY,
	UPDATE_ENTITY, 
	DELETE_ENTITY,
	LINK_AND_UPDATE_ACCOUNT, //create link and produce entity save event (call provisioning)
	LINK_AND_UPDATE_ENTITY, // create link, update entity
	LINK,
	UNLINK,
	UNLINK_AND_REMOVE_ROLE,
	CREATE_ACCOUNT, // produce only entity save event (call provisioning)
	UPDATE_ACCOUNT, // produce only entity save event (call provisioning)
	LINKED, // situation (for IGNORE and WF sort)
	MISSING_ENTITY, // situation (for IGNORE and WF sort)
	UNLINKED, // situation (for IGNORE and WF sort)
	MISSING_ACCOUNT, // situation (for IGNORE and WF sort)
	IGNORE,
	UNKNOWN;

Each of these types may attain the following states:

 	SUCCESS,
	ERROR,
	WARNING,
	IGNORE,
	WF

• SysSyncItemLog - is linked to the actions log. It records the course of the synchronization of each element. It contains the identifier and the name of the element.

You can configure additional synchronization options for specific uses:

• Default role - The value can be any role in CzechIdM. This value is used in the case that the synchronization links an existing system account to an existing or a new identity in CzechIdM. If the default role is specified, this role will be assigned to the identity for its main valid contractual relationship. Then the link to the account will be created with the property Assigned by role set to the default role. If the default role is empty, the link to the account will be created as well, only without the property "Assigned by role".
  • The main use-case for this option is initial linking of accounts during the reconciliation of a system, where the accounts will be further managed by CzechIdM - e.g. LDAP, AD. The default role will be usually configured for provisioning on this system, see Provisioning - role and queue configuration.
  • This option is supported in the following actions of the synchronization: Missing Entity → Create entity, Not Linked → Create link, Create link and update entity, Create link and update account.
  • The role assignment skips an approval process - the corresponding role request will be processed Without approval.
  • If the identity doesn't have any valid contractual relationship, the synchronization will take action based on the Behavior of the default role for inactive identities option (see below).
  • Note that the role will be assigned to the identity regardless of other role assignments of the identity. So even if the identity already had the same role assigned, the role would be assigned again and the created account's link will be related to this new assignment.
• Behavior of the default role for inactive identities (since 9.2.3): This option is required in the case that a Default role (see above) is specified for the synchronization. If the synchronized identity doesn't have any valid contract, then the default role can't be assigned to it. So you must specify by choosing one of the following options, how the synchronization should behave in such situations:
  • DO_NOT_LINK: The account won't be linked and the identity won't be updated or created at all. The result of processing this item is Ignore. Typically, you will use this option when you connect a system to IdM in which you expect some old unwanted accounts, and you don't want to manage them anymore.
  • LINK_PROTECTED: The account will be linked to the identity without the property "Assigned by role", but it will be put into the protected state. The length of the protection is based on the last expired contract of the identity and the Length of protection interval configured in the provisioning mapping for this system. Note that this can be in the past if you have a short protection interval, so the account can be deleted as soon as the task for deleting expired accounts (AccountProtectionExpirationTaskExecutor) starts. If the identity doesn't have any expired contract (it has no contracts, or only future contracts), the current date is used as the start of the protection. Typically, you will use this option if you connect a system to IdM in which you intentionally keep old accounts, and you want to have some control over these accounts by IdM (e.g. if the original owner got a new valid contract, the original account should be reused). This option requires an existing provisioning mapping with Account protection enabled, otherwise the synchronization wouldn't start.
  • LINK: The account will be just linked to the identity without the property "Assigned by role". The result of processing this item is Warning, because such account is not managed by role assignment - it will exist as long as the corresponding identity exists regardless of its (in)activity. This option is for backward compatibility mainly, because such was the behavior in the versions < 9.2.3.
• After end, start the automatic role recalculation - After synchronization correctly ended recalculation of automatic role will be started.
• Create default contracts for new identities - If a new identity is created during synchronization, a default contract will be created for the identity. To use this feature, you must also enable creating default contracts in the application configuration (idm.pub.core.identity.create.defaultContract.enabled=true).

Synchronization makes use of the standard mechanism of events in IdM, adding three new events:

• SysSyncItemLog.START_ITEM

and new processors:

• synchronization-item-processor - The processor in its default state performs the synchronization of each of the synchronized elements (SynchronizationService.doItemSynchronization).

For the scheduled activation of the synchronization, the task SynchronizationSchedulableTaskExecutor has been created which has the uuid as an input parameter of the configuration of the running synchronization.

The task will read the synchronization configuration according to the entered uuid, and will launch it in the same way as a direct launching from the overview of the configured synchronization configurations on the system detail.

After the launching, it is possible to observe and possibly stop the running synchronization from the overview of running tasks. When the task is finished, the final log can be seen not only in the synchronization agenda on the system, but also in the overview of all tasks.