7.4:dev:provisioning

Provisioning

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.

Provisioning is an integral part of the ACC module (ACCount management)

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:

  • doProvisioning(AbstractDto dto) - will do the provisioning for all the accounts themselves and systems related to a given dto (e.g. dto for identity, role, role catalogue, tree node).
  • doProvisioning(AccAccountDto account) - will do the provisioning for this account (for the dto to which the account is related and which is marked as the account itself)
  • doProvisioning(AccAccountDto account, AbstractDto dto) - will do the provisioning for this account and for the given dto (in case a link to the account marked as the "account itself").
  • doDeleteProvisioning(AccAccountDto account) - will delete the account from the end system
  • changePassword(AbstractDto dto, PasswordChangeDto passwordChange) - will change the password of a given dto (mainly is used for identity) also on the systems which have been set in the PasswordChangeDto object (contains also a new password). In PasswordChangeDto is collection AccAccountDto and for them will be change password.
    • doProvisioningForAttribute - enables to do the provisioning only for a specific attribute. This is for example what needs to be done to change the password.
    • authenticate - will perform the authentication test on the end system for a given username and system.
    The term account itself stands for the link between an dto and an account. Provisioning is done exclusively for the links which are marked as theaccount itself. Otherwise such a link is only an "informational" one. For example, the administrator´s account may have more identities, but only its owner may change it.

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)
More about attribute strategies (attributes merge and etc.) is here.

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.