Provisioning identity provisioning

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 operation
• EXECUTED - the operation was successfully executed
• EXCEPTION - there was an exception during execution
• NOT_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 provisioning - provisioning is started by publishing 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.
• Disabled system - requests for provisioning fall directly into the queue with state NOT_EXECUTED. The end system is not contacted at all.
• Read only system - requests for provisioning are prepared, the actually changed attributes on the end system are counted, and the request falls into the queue as 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.
• Retry mechanism - the requests 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 RetryProvisioningTaskExecutor.
• Possibility of asynchronous processing - end system can be switched to use asynchronous provisioning. Then requests for active provisioning operations fall directly into the queue and is processed by long running task periodically ProvisioningQueueTaskExecutor.
• Break configuration (coming soon)

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.