Creation of a newly connected system will be demonstrated on a database connector (ConnIdDBBundle). Firstly, we will create a new system named Table and choose the database connector. All settings for this connector are available in the Configuration tab. In the picture below is an example of the configuration:

When the connector is configured correctly, we can move on to the System scheme tab. There, we will create the scheme either manually or we will use the scheme which will be returned by the connector itself (according to the filled-in configuration).

The scheme will be automatically created by pressing Generate scheme.

After a successful generation, there should be a new entry (object class) __ACCOUNT__ in the object types table. This entry will contain available attributes in the system (for object ACCOUNT). In our case, it will contain an attribute for each column in the mapped table and the semantic attributes:

• __NAME__ - attribute identifying the account in the system (user name).
• __PASSWORD__ - attribute for password mapping for the given account.
• __ENABLE__ - attribute for mapping the indication whether the account is enabled or disabled.

When the system scheme is created, we can move on to attribute mapping in the Attribute mapping tab. Mapping serves two basic purposes:

1. Making the scheme attributes accessible in the IdM system. Only mapped attributes can be used in IdM for active operations (provisioning/synchronization). Mapping is always tied to the operation type and entity type (identity, group).
2. It defines which value will the attribute be mapped into in the IdM system. (identity, group, extended attribute, hidden attribute).

Firstly, we will create a group (operation type and entity type) which we would like to map. We will select Provisioning and Identity. Then we will start creating the individual mappings. It is very important to create a mapping for the account identifier in the system and connect it correctly to the IdM identity. This is done by adding a new attribute.

In the attribute mapping details we will fill in:

• The attribute from the system scheme which identifies the account, i.e. __NAME__.
• Fill in the name of the mapped attribute. It is pre-filled with the scheme attribute name but any other name can be used.
• Tick Is identifier.
• Tick Entity attribute. The attribute will be tied to the user name of the identity in IdM.
• Fill in username as the IdM key.

For optimalization, the attribut can be cached. New mapping attribute is marked as 'cached' by default.

• The cache key is a mapped attribute and attributes from the end system.
• The value is the transformed value from the system.

It's possible to send additional attributes to provisioning, when password is changed (e.g. password expiration in extended attribute). New flag sendOnPasswordChange was added to system attribute mapping - attribute with this flag checked will be send together with changed password to provisioning. Two ways for provisioning additional attributes are implemented:

1. send additional attributes together with new password in one provisioning operation
2. send additional attributes after password is changed in another provisioning operation

Two ways are be configurable by application configuration idm.sec.acc.provisioning.sendPasswordAttributesTogether:

• true: additional password attributes will be send in one provisioning operation together with password
• false: additional password attributes will be send in new provisioning operation, after password change operation (some systems doesn't support to change other attributes in the same request with password)

In the previous chapter we explained how to assign a role tied to a system. By doing this, we created an account which corresponds precisely to the mapping in the system. That was a default mapping. However, if want to create a role which will affect only a specific attribute, we will need to adjust the behavior (mapping) of the attribute, i.e. we will need to overload the attribute mapping.

• We will create a new role Table role - first name.
• Add the same system mapping as with the Table role role.
• In the Attributes mapped within this role table, we will add a new attribute which will overload the default attribute firstname.
  • Fill in the name - for example "firstname - overloaded attribute (adds the "overloaded value" suffix)".
  • Tick Entity attribute.
  • Fill in firstName as the IdM key.
  • Insert "return attributeValue + "overloaded value";"" in the script for transformation into the system.
  • Now, if the role is assigned to a user, the account on the end system Table will contain the overloaded value suffix in the firstname attribute.

The attribute strategy defines how will the attribute and primarily its value be dealt with during provisioning and synchronization.

The strategies are as follows:

The default strategy which sends the acquired value to the end system as IdM calculates it. If the value is the same on the end system, the attribute isn't sent.

This strategy is applied both to account editing and its creation.

The attribute value which is calculated by IdM is sent to the end system only if the end system value is calculated as equal to null. Before the final comparison whether the value is non-existent, transformation from the system is applied to the attribute value from the end system. The transformation is defined in the mapping of the attribute.

This strategy is applied both to account editing and its creation.

The attribute value which is calculated by IdM is sent to the end system only when creating a new account on the end system.

The CREATE strategy has a lower priority than WRITE-IF-NULL, SET, MERGE and AUTHORITATIVE-MERGE.

This strategy (identically to MERGE) alters the logic of calculating attributes and their values. With the other strategies applies the following: if there are more occurrences of the same strategy for the same attribute (more overloaded attributes in more roles), the one with the highest priority is found (according to role priorities or their names). The resulting value going into provisioning is calculated on the basis of this one attribute only.

The MERGE strategies are different, however. If there are more attributes overloading the same default attribute, all the values are merged into one. This resulting value (list) is sent to the IdM system as a "wish" of how the value should look like on the end system.

With authoritative merge, the original values of the attribute on the end system are not taken into account (i.e. if some other system or administrator had put a different value to the attribute, it would be ignored by IdM).

Therefore, in a situation where the resulting value of the merged attribute from IdM is [A,B] and the value of the same attribute on the end system is [C,D], then the end system attribute will gain the value of [A,B] after provisioning.

This strategy follows the same pattern as authoritative merge up until the phase of creating a "wish" for IdM.

A procedure different from authoritative merge occurs at the moment of provisioning. The goal is to ensure that the attribute on the end system can be shared by more systems (it means IdM is not authority for all values in the attribute).

Another goal is to ensure the correct removing of the managed values.

For identify what values are controlled by the IdM, we get it based on the settings of the roles mapping the system and overloaded this attribute (this 'calculation of the definition' approach is used since version 9.3.0. The previous approach, where the values ​​from the provisioning archive were used no longer used).

The controlled values ​​are currently valid values ​​(based on roles values) and values valid in the past. Such a "historical" value arises at the time of the definition of role change, typically in the following cases:

• Change the script defining the controlled value. For example, if we change the assigned value 'A' (in transformation to the system) to 'Z', then the currently contolled value will be 'Z' and the new historical value 'A'.
• By disabling the attribute - if we disable the attribute assigning the value 'A', then a new historical value 'A' will be created. The 'A' value will no longer be part of the currently controlled values ​​that are calculated based on the definition.
• Change the attribute strategy - if we change the strategy from 'Merge' to another, the value 'A' will again be only historical.

Because the calculation of which values are currently controlled could be time expensive operation, are that values cached in entity SysAttributeControlledValue which is mapped on system mapping attribute. That persisted 'cache' is evicted when definiton for that attribut is changed on the role (SysRoleSystemAttribute).

The evicted cache is recalculated by using the AttributeControlledValuesRecalculationTaskExecutor task, which is run after each save of attribute mapping on a role. In this case, this task recalculates the cache for all evicted attributes of the provisioning mapping.

Cache recalculation with this task can be started manually. At this startup, you must specify the system identifier and entity type (the 'IDENTITY' is filled in as default). It is also possible to deselect onlyEvicted. In this case, all attributes for that mapping will be recalculated even if their cache is not marked as evicted. Second situation when is cache recalculated is during provisioning. If the attribute is still marked as evicted.

Therefore, in a situation where the resulting value of the merged attribute from IdM is [A,B] and the value of the same attribute on the end system is [C,D], then the end system attribute will gain the value of [A,B,C,D] after provisioning.

Let us continue with the previous case, where the value [A,B,C,D] is on the end system. If we remove the role which was defining value B in IdM, then the value on the end system must be [A,C,D] after provisioning. We will then remove only the value which we are managing.

In our case we have the following information at our disposal:

• The current wish of IdM for this attribute is value A.
• From the definition of the controlled values for this attribute [A,B].
• The current value on the end system is [A,B,C,D].

By comparing these values, we can deduce that we have to remove value B, so that the result is value [A,C,D].

An advantage of this approach is the ability of detecting dynamic changes as well. This means that if we don't remove the role which assigned value B, but instead we change the calculation definition of this value, so that the result is X, then it follows from the above mentioned that we are able to correctly identify that we want to send value [A,X,C,D] to the end system.

Aside from a strategy, every attribute can also have the indications Always send and Send only if IdM value exists. These indications can be combined with all strategies.

• Always send - Ensures that the attribute will be sent to the end system even when it has been assessed that its value hasn't changed.
• Send only if IdM value exists - Ensures that the attribute will be sent only when the calculated IdM value has some value (if it is a String type value, it cannot be blank). This setting ensures that the IdM system doesn't delete attribute values on the end system when it can't calculate them.