Systems - identifier chaos/mismatch/uppercase

User account identifiers might have a different format in one system than in another, e.g. prefixed, suffixed, uppercase/lowercase. This would be no big deal if CzechIdM was configured only to provision data to this system. However in a situation where we also need to synchronize the data including the identifier (e. g. the system is the only/the most complete source of usernames) from the system to CzechIdM and store the identifier in it's "normalized" form (e. g. without the prefix, suffix or in uppercase/lowercase), you need to use a transformation script both during the synchronization and during the provisioning. In this tutorial you will learn how to configure the mapping to work correctly for the Account Management module. This tutorial won't help you with the case with no exact rule of "de-normalization" of the identifier"

In the synchronization you need to create AccAccount (Accounts tab in the system detail) with an identifier that is in the same format as is the identifier of the account on the system. However when you put a transformation script into the mapping of the attribute marked as "identifier", the account identifier will be created in it's "normalized" form. Invoking an account management for that account would cause a creation of a duplicate AccAccount item and would "break" the mapping for the user.

To prevent this behavior you need to map the identifier attribute twice.

1. The first mapping of the attribute:
   • will be marked as the identifier for the mapping
   • won't be mapped to any attribute of the entity in IDM (or EAV)
   • won't use any transformation script
2. The second mapping of the attribute:
   • won't be marked as the identifier for the mapping
   • will be mapped to the attribute of the entity or EAV where you want to store the identifier's "normalized" form
   • will use a transformation script which will "normalize" the identifier

In the provisioning mapping there are no tricks. The identifier attribute will be mapped only once.

1. In the mapping the attribute:
   • will be marked as the identifier for the mapping
   • will be mapped to the attribute of the entity or EAV where the identifier's "normalized" form is stored
   • won't use any transformation script "from the system"
   • will use a transformation script "to the system" which will "de-normalize" the value (e. g. prefix, suffix, lowercase/uppercase)

In case you have already broken the mapping and generated a duplicate AccAccounts, the only solution is:

1. Set the system to the "read only" mode
2. Disable account's protection for the provisioning
3. Delete all AccAccounts (you can select all on page, then go to another page and repeat)
4. Delete (or cancel in case of a production environment) the provisioning queue
5. Delete all SysSystemEntity on Entities tab (you can select all on page, then go to another page and repeat)
6. Synchronize data to IDM and re-link accounts