Table of Contents

IdM data export/import agenda

, , ,

This agenda is used to transfer configuration data from one IdM to another. A typical use scenario is when you already have IdM configured on a test environment and now you need to migrate the tested configuration to a production environment.

Without this tool, you must manually transfer the settings. Ie. you must create roles, system definitions, including their configurations such as guarantors, linked attributes, etc. So the main goal is to facilitate configuration transfer between individual IdM systems.

This transmission is divided into two basic parts Export and Import:

Export

You can export data from the source IdM by using bulk operations over the appropriate agendas.

For example, if you want to export roles, then first select the appropriate roles in the role agenda and then run the Export Roles bulk operation. The result of this operation will be to create a new export batch in the Menu → Settings → Export/Import agenda. This export batch will contain all exported data that can be downloaded in ZIP format.

Import

Import is performed in the target IdM, when in the same agenda Menu → Settings → Export/Import, we upload the batch that we exported in the source IdM (ZIP).

The import batch can then be run in the so-called demo mode. This mode serves to test what the given batch will actually change in the target IdM.

When we are sure that we really want to make the changes that the batch makes, we can proceed to the launch of the import itself.

Dry run mode

Dry run is a mode where we first want to check what changes will be made to the target IdM. For example, due to authoritative mode, some objects that are not part of the imported batch may be deleted during import. Starting dry run mode allows us to find out what data will be deleted.

It also allows us to solve some error situations. This means, for example, a situation where the exported system contains provisioning brake provisioning, including the definition of specific recipients of notifications. These recipients can be defined by role or identity. However, these may not exist on the target IdM. In this case, the import would failed with an error because the recipient would not be found. If we run dry run mode in the same situation, we will see error results on the third tab "All modifications", which will indicate that the given recipient was not found. The message will also contain the recipient's code (identity or role) and thus we can create (before the import itself) the missing recipient according to the obtained code.

Dry run mode can be started using the blue play button on the export / import table.

How it works?

Each export of a given type of object is implemented as a separate bulk action, which ensures correct data export. The export action must also ensure that the export metadata is correctly created. Export metadata is the file export-batch.json, which is part of each exported batch. This file contains metadata, such as the batch name and a descriptors for each exported object type.

Export descriptors

Export descriptors primarily define the order in which data is exported (the same order is used during import). In addition, each descriptor contains additional metadata that defines how the import should handle that type of object. The descriptor metadata also defines:

Since version 10.6.0 is token field excluded from a import of system sync.

What can be exported

Version 10.2.0 implements export of roles, systems, application configurations, and some related objects (such as form definitions or catalogs …).

Passwords (stored in confidential storage) are never exported. When you first import an object that contained a password (for example, a connector configuration (EAV attributes) or password in remote connector server), the password will not be filled in the target IdM. If it is an update of an existing object, then the password in the target IdM will not be modified in any way.

Roles

Roles are exports with this related objects:

Systems

Systems may have a relation to a roles (provisioning breaks or roles that allocate the system), so you must always export and import roles before importing systems.

Systems are exports with this related objects:

Since 10.6.0: Sync contract/slice configuration contains relation on a organization structure and organization node. If this objects will be not found (by ID or code), then whole configuration of the sync will be skipped (not updated, not created, not deleted)
Virtual systems may be imported with some limitations, see the section Limitations.

Application configuration

Application configurations without authoritative mode.

Authorization policies

For execute an export action you will need to have:

To successfully export, you must have the permissions to read all objects that will be exported. For example, if a role contains business roles and you do not have the permissions to them, then the export will fail!

For execute an import action in dry-run mode you will need to have:

For execute an import action you will need to have:

Only import / export administrator can run import batches!

Performance tests

Performance testing took place with using numbers of Systems (specifically CSVDir system) with assigned several roles, set mapping etc. to increase overall number of entities to export. The goal was to find both particular time of duration and estimation of the export/import complexity.

Following table shows number of testing systems and measured times of their export and import. The growth of the operation time is roughly linearly proportional to number of testing systems and by extension overall processed entities.

System numOverall entity num Export time [min]Import time - Dry run [min]Import time - Apply changes [min]Zip size [MB]
11126911132,18
201485113103,93
4159982210358,08
8151958243813015,8

Limitations

Cannot be used to update systems / roles that have not been created by the import function

Export/Import in version 10.2.0 is primarily intended for export and import of new data (roles / systems). Ie. it is not intended to update the date in the target IdM that was not created by the import. The reason for this limitation is the basic property of how import imports existing objects in the target IdM and in the batch. This pairing is based primarily on the identifier, where the same object receives the identifier from the source IdM. This makes it possible to effectively identify an object that is to be updated in the target IdM and to be created as a new one.

In addition to the basic match of identifiers, a unique code-matching mechanism is implemented in version 10.2.0 (the object must conform to the Codeable interface). This mechanism works very well for objects such as roles, identities, systems, catalogs, those that have unique code.

However, there are a number of objects that require unique attributes based on two or more attributes. For example, a scheme of a system that requires its name to be unique within the system. Pairing of these objects is not supported in version 10.2.0. Trying to update such an object will result in the import attempting to create a system schema with a duplicate name, which will result in the entire import failing.

No skip implemented

Omitting for recalculation of business roles, incompatible roles or provisioning is not implemented in version 10.2.0!

Virtual systems

Full support of the virtual system export and import has been available since version 11.1. Following workaround should not be necessary anymore.

When importing a virtual system, you must make some further adjustments so the imported system behaves in the same way as the exported system. Especially if you use the "rights" attribute or if you changed or removed some of the default attributes. After you import the system:

More info here.