Table of Contents

, , , , , ,

Systems - DB: Source of identities

Basic configuration

This tutorial deals with how to connect an authoritative (primary) system as a source of identities. To this end, the basic Database Table Connector will come in handy. The source table we are going to use consists of 4 columns: id, username, first name, and last name.

First, click on the Add button on the Systems tab item. Pick a system name, say, Some base. Check the ReadOnly checkbox field - your database is to serve as a source of data only, you don't actually wish to be able to write to it. Keep other attributes of the system as they are by default. Then click on the Save and continue button.

Connector configuration

Go to the Configuration tab and select the Database Table Connector (connId). Next, enter the path to the DB and the user login that IdM will use to get access to the DB. This user must be authorized to read the connected table, as a minimum. Specific settings in our example:

At the time of writing this tutorial, the driver for PostgreSQL can be downloaded here: https://jdbc.postgresql.org/download.html

Apart from the settings in the system configuration in CzechIdM, the driver file must be placed into the library location of the application server. In our case, CzechIdM runs on the Tomcat application server, so we place the driver into the lib folder. Alternatively, the driver can be placed into WEB-INF/lib directly in the CzechIdM application location.

Leave the other connector attributes empty or with their default pre-filled values.

If everything has been set correctly and CzechIdM can access our DB, we can verify the configuration by clicking on the green Test connector button at the top of the page.

System schema

Go to the System schema tab (described in chapter 2.3.2 FIXME) and click on the Generate schema button. The connector automatically returns the list of attributes available on the connected system. The object returned by the connector is of the __ACCOUNT__ type by default, which suits our purpose of connecting identities. As expected, the connector also returned 4 attributes corresponding to our columns in the DB. They can be displayed by clicking on the magnifier icon next to the object type.

In addition, the connector returned the __NAME__ attribute, which is defined by the ConnId standard. The Database Table Connector (connId) implementation we use follows this specification, but it does not use this attribute for synchronization, so we will not need it for reading data from the source system.

By clicking on the magnifier icon next to the attribute name, you can display the configuration details of the particular attribute.

Figure 22: Attribute detail in the system schema

In our case, all the attributes have the same configuration except for the `id` and __NAME__ attributes, which are marked as required.

Synchronization mapping for the DB

Once the system schema is ready, we can proceed to the synchronization mapping. It allows us to define which attributes from the available schema will be synchronized into IdM, and also which Identity attributes will be filled with the attributes from the account.

On the Attribute mapping tab, click on the Add button and fill in:

After creating the mapping, open its detail and set the particular bindings of the account attributes to the identity attributes. Set the mapping for all our attributes: `id`, `name`, `surname`, `username`.

For example, the `id` attribute is set according to the picture above. The other attributes are set the same way, except for the following items:

As you can see, not all attributes have to be mapped to an attribute in CzechIdM. Those which are not mapped will not be filled in the entity in CzechIdM. In our case, the `id` attribute will not be transferred to the entity - we do not want to use it any further, nor do we plan to send it to managed systems.

In our example, we mapped the account attributes on the system to the basic Identity attributes. Every entity in CzechIdM has a basic set of attributes, which can however be extended. If you want to map attributes to extended attributes of CzechIdM entities in the synchronization, you must first prepare the EAV attribute form for the given entity, see chapter 2.10 FIXME.

Synchronization settings

In the previous chapter, we prepared the attribute mapping for the synchronization. Now we will set up the synchronization process itself, which will use this mapping.

Go to the Synchronization tab and click on the Add button. In the synchronization, fill in the name and enable it according to the picture. We can also check Reconciliation - we are going to read all accounts without any restriction. As the set of mapped attributes, select the `users` mapping which we created in the previous chapter.

Then proceed in the form to the settings of operations for the individual account and entity states and set them as follows:

Leave the Workflow items empty - they are used for advanced scripting of the individual actions.

On the Filter sub-tab, we do not set anything - we do not want to restrict the synchronization to only some accounts. The Logs tab is informative only and contains the audit log of the synchronization.

Starting the synchronization and the log

If we have successfully gone through the settings in the previous chapters, we can now proceed to starting the Synchronization itself. Go to the Connected systems tab, select our configured system and go to the Synchronization tab. Start the synchronization with the green triangle button at the end of the row with the synchronization configuration.

Running synchronizations have the Running column filled in. If you open the detail of a running synchronization (by clicking on the magnifier icon) and then go to the Logs tab, you can see an overview of all synchronizations, including the currently running ones.