Provisioningidentityprovisioning

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(IdmIdentity identity) - will do the provisioning for all the accounts themselves and systems related to a given identity.
doProvisioning(AccAccount account) - will do the provisioning for this account (for the identity to which the account is related and which is marked as the account itself)
doProvisioning(AccAccount account, IdmIdentity identity) - will do the provisioning for this account and for the given identity (in case a link to the account marked as the "account itself").
doDeleteProvisioning(AccAccount account) - will delete the account from the end system
changePassword(IdmIdentity identity, PasswordChangeDto passwordChange) - will change the password of a given identity also on the systems which have been set in the PasswordChangeDto object (contains also a new password). In PasswordChangeDto is collection AccAccount 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(AccIdentityAccount identityAccount) - will perform the authentication test on the end system for a given identity and account
The term account itself stands for the link between an identity 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.

Provisioning line

To extend or reconfigure the provisioning mechanism, the processing has been moved to the events on the entity SysProvisioningOperation and to the individual processors treating this identity (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 SysProvisioningOperation content through ProvisioningExecutor. The individual operations are serialized, saved in the line, 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 line (error code, return state). The GuardedStrings are not saved in the serialized state - the values are replaced and saved in a coded warehouse from which they are only read when needed (account re-calculation, provisioning implementation).

The operation content in SysProvisioningOperation 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 line, all the other requests for the provisioning of the same objects fall directly into the line - consistent sequence of operations on one object in the end system.

Provisioning lines functions:

Disabled system - requests for provisioning fall directly into the line. 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 line. 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 line and new running time is scheduled to them = another attempt will be executed by long running task RetryProvisioningTaskExecutor.
Break configuration (coming soon)
Possibility of asynchronous processing (coming soon)

More about attribute strategies (attributes merge and etc.) is here: