Connector configuration and attribute mapping

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:

The configuration below is only an example.The system in its default state doesn't contain the mapped table "system-users"

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.

Create mapping for the other attributes in the same way. Below you can find a table with the resulting mapping:

If we want map password attribute is enough to map attribute PASSWORD and not fill anything else (no attribute uf entity and nothing else). Because we do not know current user password it's new password for system generated by password policy for the system, but only in case CREATE and if attribute PASSWORD is NULL. New password it will be send to user with topic newPassword.

In the previous paragraphs, we created a system which contains a scheme and mapped attributes for an identity and provisioning. In order to create an account for a specific user in the end system we have to create a role which will be assigning this system and, at the same time, we have to assign this role to the user.

  • We will create a new role Table role.
    • In the Connected systems tab, we will create a new connection to our system Table for the entity Identity.
    • We will assign this role to a user. We will do this in the user details in the Assigned roles tab.
    • After successfully assigning the valid role, a corresponding account in the system should be created. We can check this in the "System accounts" tab, where a link to the account should have been created.
    • We can also check the account creation in the Table system. A link to the user account should have been created in the System entities tab.
    • System identifier, which is an identifier returned by the system after the creation of the account.

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 need to create a role where, after it has been assigned, the linked accounts will contain first name + the "overloaded attribute" invariable in the firstname attribute.
  • 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 klíč.
    • 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 atribute.

Mapped attribute strategy

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

The strategies are as follows:

SET (set as IdM calculates)

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.

WRITE-IF-NULL (Set only if the value on the system is null)

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.

This strategy is also implemented in the case of synchronization. The function is similar to that of provisioning. The opposite is only the source and destination. In the case of synchronization, it is the source account on the end system and the goal is synchronized entity. Before comparing, a transformation to the system is applied.
The WRITE-IF-NULL strategy has a lower priority than SET, MERGE and AUTHORITATIVE_MERGE. Therefore, if we define one attribute with the SET strategy and another with the WRITE-IF-NULL strategy in the default mapping on the system, then the value of the WRITE-IF-NULL attribute will never be used. In this case, it will be necessary to define only the attribute with the WRITE-IF-NULL strategy in the default mapping. The other attribute with the SET strategy will have to be defined in the role as an overload of the default attribute.

CREATE (Set only when creating)

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

This strategy is also implemented in the case of synchronization. The function is similar to that of provisioning. The opposite is only the source and destination. The value of the attribute from the system is set to the entity only when it is creating.

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

AUTHORITATIVE_MERGE (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.

Both the MERGE and AUTHORITATIVE_MERGE strategies, can be linked only to a multi-value scheme attribute!

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.

A situation where there are two overloaded attributes for the same default attribute, one having the AUTHORITATIVE_MERGE strategy and the other the SET or MERGE strategy, will not be valid. Such a situation is collisional and will result in an exception during provisioning!

With authoritative merge, the values not taken into account are those put into such an attribute on the end system from other systems.

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.

MERGE (Merge)

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.

A situation where there are two overloaded attributes for the same default attribute, one having the MERGE strategy and the other the SET or AUTHORITATIVE_MERGE strategy, will not be valid. Such a situation is collisional and will result in an exception during provisioning!

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.

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

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.

A provisioning archive is used to effectively identify which values were added by IdM. The archive contains the history of all the executions of provisioning, both the values actually sent to the end system and the "wish" calculated by IdM. It is this wish that enables us to delete the correct values (i.e. those added by the IdM system).

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

  • The current wish of IdM for this attribute is value A.
  • From the history of the last successful provisioning, we know that the previous wish of IdM was value [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.

A simple way of how to verify which attributes (values) were "wishes" in IdM and which were actually sent to the end system can be seen in the provisioning archive (Audit / Provisioning / Archive)

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.