Account Management

The aim of account management is to create accounts in the IdM internal warehouse (AccAccount entity) in the same form in which they should be created (according to the IdM settings) on end systems. Account management therefore does not run provisioning as such but it is its indicator, in most cases.

Basic account management is used for all entities that support provisioning. Identities utilise more complex account management, relying on roles assignments.

If an entity supports basic account management, then the method ProvisioningService.accountManagement is executed when the entity has been created/updated.

Provisioning ensures the following:

1. Finds all systems with the provisioning mapping for this entity type.
2. Generates the account identifier `uid` for this entity.
3. For all found systems, checks whether or not an account with the same `uid` already exists. If so, then this method comes to an end.
4. For all found systems, checks if the mapping includes the script 'Can an account be created?'. If this script is filled, it is executed. If the script returns `Boolean.FALSE`, then an account on this system is not created (this method comes to an end).
5. Account on the system is created (AccAccount).
6. A relation between the created account and the entity is created, too.

Account management is carried out when triggered by events that impact accounts on the end system. These events may include:

• creation/modification/deletion of an identity.
• creating/modifying/deleting the assigned role to a given identity.
• creating/modifying the definition of mapping the attributes for a role.

By default, if there is a contract that is valid in the future, and you assign a role to this contract (assigning a system), this assigned role is then discarded (not currently valid) during account management. That is, no accounts are created on end systems. This behavior constitutes the default and correct result.

In some cases, however, you need to create an account on an end system before a respective contract becomes valid (for example, when a new employee is expected to arrive). As a solution to this requirement, you can use forward identity account management.

In some cases, one user can have multiple accounts in one target system (think of testing or admin accounts). IdM can manage these as well. See this tutorial for more details.

Account lookup is based on exact match of:

• systemId
• UID (case sensitive)

If the newly computed UID is different from an existing UID, a new account is created.

Example:

• anovak != ANovak
• asykorova != anovakova

This can result in multiple main personal accounts for one identity on the same system.

Duplicates can occur in the following situations:

• Change in UID mapping script
• Manual change of UID
• Rehire of identity with a different login
• Rehire of identity after UID mapping change

Identity rename is supported and functional.

• If systemId + UID match exactly, the existing account is reused.
• If UID differs, a new account is created.
• Multiple accounts per identity on one system are supported.
• Later UID unification may cause a database constraint error (ux_account_uid).
• Manual intervention may be required.

Automatic account merge based on:

• case-insensitive UID comparison, or
• ownerId / identityId

is not implemented.

Reasons:

• Risk of incorrect account merge.
• Risk of linking unrelated accounts.
• Existing tests depend on current behavior.
• Current behavior is deterministic and predictable.

• Do not change UID mapping in production without impact analysis.
• Validate behavior in a test environment before applying mapping changes.
• For large duplicate scenarios, use a controlled merge script.
• The merge script must be executed manually and reviewed.

If the AccIdentityAccount link is removed and UID changes, IdM cannot reliably determine the original ownership. Automatic recovery is not possible in this case.

Some accounts are not owned by an identity but are managed as technical accounts. This class of accounts can be managed by the IdM with a separate module. See here for more details.