Provisioning ensures the implementation of accounts settings on end systems according to the settings in IdM. The provisioning itself then only propagates information to the end system. It does not make the evaluation of which identities should be subject to provisioning on a particular system. This is the task of accounts aministration which is an integral part of IdM and precedes the provisioning itself.
As it has been already said, the provisioning is preceded by accounts administration. In most cases, provisioning is therefore run by the service ensuring accounts administration. If this service evaluates that such a change of the account which requires provisioning has occurred, it will call the service ProvisioningService. This service includes the following methods:
All provisioning operations are processed through provisioning queue. The individual operations (create, update, delete) are serialized, saved in the queue, and then processed. If provisioning operation is completed, then archive provisioning operation record is created ⇒ active provisioning operation is executed and is moved into archive.
Three entities was created to persist provisioning operations and their state:
SysProvisioningOperation - active (unresolved) provisioning operations. Contains operation type, state and provisioning context with transformed attributes (from IdM account), which have to be provisioned ("wish") and really provisioned attributes (connector attributes), read more below.SysProvisioningBatch - container for active provisioning operations for one system entity on one system. Aggregates active operations for single entity (e.g. identity, role). When provisioning fails or is stopped (e.q. when system is switched to be read only, disabled, asynchronous), then all provisioning operations for single entity are grouped in one batch. Operations can be executed in the same order, as they was inserted into queue ⇒ preserve entity state on target system. Operations from queue are processed by their batch ⇒ respectively batches are processed from queue.SysProvisioningArchive - archived (processed) provisioning operations - logged operations. Last archived provisioning operation can be used for getting provisioned context with contains really provisioned attributes.Supported provisioning operation states:
CREATED - newly created, not processed operationEXECUTED - the operation was successfully executedEXCEPTION - there was an exception during executionNOT_EXECUTED - the operation was not executed because of some reason - operation for the same entity is already in queue, readonly system etc.CANCELED - canceled by some reason (administrator etc.)
To extend or reconfigure the provisioning mechanism, the processing has been moved to the events on the dto SysProvisioningOperationDto and to the individual processors treating this dto (the list of the registered processors has been extracted to the application on the module page). Calling the provisioning then takes places through publishing the events with the SysProvisioningOperationDto content through ProvisioningExecutor. The individual operations are serialized, saved in the queue, and transmitted to the processors. If a provisioning error occurs or some of the processors stops working, then it is possible to find what happened in the agenda placed above the queue (error code, return state etc.). The GuardedStrings (e.g. passwords) are not saved in the serialized state - the values are replaced and saved in a confidential storage from which they are only read when needed (account re-calculation, provisioning implementation).
The operation content in SysProvisioningOperationDto is called ProvisioningContext and is divided into two logical units:
accountObject - counted attributes according to the set-up mapping on the IdM page ⇒ wish.connectorObject - real attributes sent to provisioning counted after contacting the end system (reading of the existent object and changes comparison).
First the accountObject (wish), then the connectorObject which is the real provisioning input is calculated. When repeating the operation, a new connectorObject from an accountObject is always calculated so that the possible changes which could occur right on the end system are taken into consideration.
Once the object (defined by the identifier on the system and the idm entity) is in the queue, all the other requests for the provisioning of the same objects fall directly into the queue - consistent sequence of operations on one object in the end system.
Provisioning queue functions:
start event on IdM account, then account attributes are resolved by configured provisioning mapping, provisioning operation for this account is created and inserted into queue for processing.NOT_EXECUTED. The end system is not contacted at all. not_executed. The check and reading of the original existing object on the end system take place - this is how the real operation UPDATE vs. CREATE is specified, if the object exists/does not exist on the end system. An active operation for provisioning does not take place.Provisioning operations ending with an error are placed into the queue and new running time is scheduled to them = another attempt will be executed by long running task periodically - long running task RetryProvisioningTaskExecutor configuration is needed. Only failed operations are processed from queue by retry mechanism.
Then requests for active provisioning operations (create, update, delete) fall directly into the queue as CREATED and is processed by long running task periodically - long running task ProvisioningQueueTaskExecutor configuration is needed.
Change password operation is still synchronous - is needed to change passwords immediately.