Account Management
The aim of the account management is to create accounts in the IdM internal warehouse (AccAccount entity) in such a form in which they should be created (according to the IdM settings) on end systems.
The account management therefore does not do the provisioning itself but it is its indicator in most cases.
The account management defines how the account should look like (according to IdM) on end systems
The account management is run depending on the event that can have an impact on the change of the account on the end system:
The event of the creation/modification/deletion of an identity.
The event for creating/modifying/deleting the assigned role to a given identity.
The event for creating/modifying the definition of mapping the attributes for a role.
The account management is ensured by the service AccAccountManagementService with the following methods:
boolean resolveIdentityAccounts(IdmIdentityDto identity) - will evaluate the account for this identity depending on the roles that are currently assigned to it. Returns true if it is requested to do provisioning.
deleteIdentityAccount(IdmIdentityRoleDto identityRole) - will delete the accounts created within the assignment of this role.
String generateUID(AbstractDto dto, SysRoleSystem roleSystem) - will generate a UID for the identity and the system. If there are overloaded attributes for UID, they are used, if not, the default attribute for UID is used.
Example of account life cycle
We have a provisioning mapping system and a primary attribute (marks as Is identifier). In this attribute, we will have a transformation into the system, the output of which will be the username with the postfix @idm.eu.
Assign a role to this system to, for example, user john-doe.
An internal account (AccAccount) will be created in IDM, where the value of this account (UID) will be john-doe@idm.eu.
After an internal account is created, provisioning will be made on the end system. This creates a new account john-doe@idm.eu on the end system.
If there is a change in the way the IDM of the account ID is being created. For example, the script will change so that postfix will be new @czechidm.eu, then john-doe@czechidm.eu will be returned during the provisioning from the primary attribute. This new value will also be stored in your account ID (AccAccount.uid).
Some systems ( LDAP ) can generate own the primary account ID . If the system returns a different identifier than the one in the IDM account (AccAccoutn.uid), then this value is stored in SysSystemEntity.uid . When communicating with the system, this identifier ! is always used
If the output from primary attribute is null, then the SysSystemEntity.uid as account ID (UID) is automatically used.
Name of account in IDM
Name of account is in IDM stored in the entity AccAccount (field UID).
This name is an internal account name and is particularly important when account management is executed but provisioning has not yet. At this point, the account name is the only account identifier.
After a end system is called (provisioning), SysSystemEntity is created (updating) and contains the account identifier returned by the system. This identifier may be different from the one stored in AccAccount.uid , and it always takes precedence over communication with the end system.
If the name of account generated by IDM is changed (during the Account management), then it will be updated.
During synchronization from the end system to IDM, an internal IDM account (AccAccount) is also created. In this case, an attribute identified as an identifier is used to generate the account name. A transformation from the system is called for this.
If the account name in AccAccount.uid differs from the generated one during synchronization, it will update it.