Basics of target system synchronization
To configure you must have knowledge of the One Manager's basic procedure for synchronizing and provisioning data. These basics are explained in the following sections.
Synchronization Editor communications
A server installed with the and, if necessary, other target system specific software, is required for . This server (named the in the following) requires direct access to the target system. The synchronization server communicates directly with the One Identity Manager database by default. You can also set up a connection over an application server for this.
Figure 4: Communication paths for synchronization
To configure synchronization with a target system, One Identity Manager must load the data from the target system. One Identity Manager communicates directly with the target system to do this. Sometimes direct access from the workstation, on which the is installed, is not possible. For example, because of the firewall configuration or the workstation does not fulfill the necessary hardware and software requirements. If direct access is not possible from the workstation, you can set up a remote connection.
Figure 5: Communication paths for configuration
Related topics
How are schemas mapped
To a target system with the One Manager database, you must first map the data models of both systems to each other. The data models (schema) are different for each system. They must be extended in such a way that they can be uniquely mapped.
The One Identity Manager distinguishes between four sorts of schema: One Identity Manager schema, target system schema, connector schema, extended schema. Each schema is characterized through schema types and schema properties. You can extend schema with schema classes and schema properties such that they can be mapped uniquely.
Just how the schema are mapped to each other is defined in mappings. Mappings group together the rules used to map the schema properties of two . Object matching rules assign schema properties through which system objects can be uniquely identified. Property mapping rules describe how the target system schema properties are mapped in the One Identity Manager schema.
Figure 6: mapping
Table 20: Terms for schema mapping
Schema |
Data model of a connected system. The schema describes all the main data from the connected system.
The One Identity Manager distinguishes between four sorts of schema: One Identity Manager schema, target system schema, connector schema, extended schema. |
One Identity Manager schema |
The One Identity Manager data model. |
|
Data model of a specific target system. |
|
The system connector extends the target system schema with additional information which is required for mapping in the . This includes:
- Information about which schema properties map memberships
- Information about which schema properties represent references to other objects
- Virtual properties that the system connector creates
If a target system does not deliver its own schema, the system connector generates the connector schema based on the imported data structure, for example, the import of CSV files by the . |
|
A schema can be customized in the Synchronization Editor, for example, to allow or simplify mapping of complex schema properties. The following options are available:
- Add new schema classes
- Define user-specific virtual schema properties
- Derive schema properties
Label the modified schema as "extended schema". |
|
Defines an object type within a schema. A schema type refers to exactly one table or view of the database based schema or exactly one object type of the non-database based schema. |
|
Subset of a schema type. The result list of a schema type is filtered by defined criteria. The number of objects found is limited thus.
Example: Active Directory contacts (schema class) are Active Directory user accounts (schema type) with their own object class = 'CONTACT' (filter criteria). |
|
Property of a schema type. A schema property refers to exactly one column of a table or view of the database based schema or exactly one object type property of the non-database based schema. There are two different sorts of schema property:
|
Virtual schema properties |
Schema class property added by the system connector or the user.
Virtual schema properties extend the basic schema with additional data required for the mapping. You can use virtual schema properties to represent combinations of schema properties as well as results as schema properties. |
|
Specifies how a concrete object of a target system schema class can be set in relation to a concrete object of a One Identity Manager schema class. An object matching rule encompasses the target system schema property based on which the target system objects can be uniquely identified. |
|
Describes how a target system schema property is mapped in the One Identity Manager schema. |
Related topics
What are filters?
You can define different filters in the . You can use filters to define the scope of a , define schema classes or to create virtual schema properties. There are three sorts of filter that differ in their effect and way they are defined. The number of objects to be synchronized can also be limited by a revision filter.
Table 21: Sorts of filter
|
This filter limits the number of objects to load in the connected system. It is more effective than the object filter and object matcher because the system connector only load the objects that are really required. You cannot link more than one filter criteria with logical operators.
The filter is given in system specific notation, for example, as LDAP filter for an LDAP system.
The following connected systems support system filters: Active Directory, LDAP, One Identity Manager databases. |
A special form of the system filter is the . The hierarchy filter is built based on the target system's real objects. All the objects to be filtered are selected from the object hierarchy.
The hierarchy filter can be used in the definition of the scope of certain target systems. |
|
The filter affects objects already loaded. All schema properties of the schema can be used as filter criteria and linked with logical operators.
The filter is formulated as a query applied to loaded objects. It can be used when the scope is defined and by virtual schema properties. |
|
The filter affects objects already loaded. All schema properties of the schema can be used as filter criteria and linked with logical operators. In order to ensure that the filter returns the desired results when provisioning single objects, you must add additional system filter criteria to the filter condition.
The filter is formulated as a query applied to loaded objects. It can be implemented in the schema class definition. |
|
This filter determines all object that have changed since the last synchronization run. The deciding factor being the revision property modification.
The filter can be applied to workflows and start up configurations. |
It is recommended you combine system filter and object filter/schema class filter to utilize the advantages of the various filters.
If scope, schema class, and virtual schema property filters are defined in the synchronization configuration and revision filtering is permitted, the number of objects to be synchronized results from the combination of all filters.
Figure 7: Effects of the filter
Variables can be used in the filter conditions. This enables the same synchronization project to be used for synchronizing different target systems or different objects within the same target system.
Related topics