How are schemas mapped
To a target system with the One Identity Manager database, you must first 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 connected systems. 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 master 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:
- Schema properties of schema types from the target system and One Identity Manager schema.
- ,
- added by the user to extend the target system schema or the One Identity Manager schema
- added by the user to extend the connector schema or the One Identity Manager schema
|
| 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 processing step 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, Microsoft Exchange, and 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
What is a scope?
The scope specifies which parts of the connected system should be . The scope is set for the target system to be synchronized as well as for the One Identity Manager schema. If no scope is defined, all objects in the connected system are synchronized.
Example:
Active Directory domains "xyz" and "uvw" are managed through One Identity Manager. The containers "abc", "def", and "ghi" from the Active Directory domain "xyz" should be synchronized. A scope is defined for the target system connection and the One Identity Manager database connection which filters only these objects. The Active Directory domain "uvw" should initially not be synchronized.
Figure 8: Example for scope definition
To specify a scope, define a system filter and object filter.
Hierarchy filter
Some target systems offer an additional option to specify the scope: the . This filter limits the number of objects to load in the connected system. It is therefore effectively the same as a system filter. The hierarchy filter is built based on the target system's real objects. The objects are displayed in their hierarchical structure. All objects included in the scope are marked in the hierarchy. All objects that are not marked remain outside the scope and are not included in the synchronization. The hierarchy filter can only be applied to objects and not to their schema properties. Create an additional object filter to include schema properties as criteria in the scope definition.
A fully defined hierarchy filter can be transformed into a variable. Thus the filter can be redefined in a specialized variable set and used for other synchronization configurations.
Reference scope
References to objects in different target systems can be in the One Identity Manager database. In order to solve these references, the target system scope must be extended to include the referenced target systems. For this, you can additionally define a for each system connection. You can enter the reference scope for the database in the same way. This means that references to parts of the One Identity Manager database can be resolved which are not included in the general scope.
If no reference scope is defined, the general scope is also used for the reference resolution.
Example:
Active Directory domains "xyz" and "uvw" are trusted domains. User accounts from both domains are members in Active Directory groups in the Active Directory domain "xyz". Define a reference scope to assign referenced user accounts of the domain "uvw" during group membership synchronization. In the reference scope, specify that referenced objects should also be searched for in the Active Directory domain "uvw".
If you have not defined a reference scope, Active Directory SIDs are determined for Active Directory domain "uvw" user accounts during Active Directory domain "uvw" group membership synchronization and entered in the One Identity Manager data store.
Related topics
How does revision filtering work?
When you start , all synchronization objects are loaded. Some of these objects have not be modified since the last synchronization and, therefore, must not be processed. Synchronization is accelerated by only loading those object pairs that have changed since the last synchronization. One Identity Manager uses revision filtering to accelerate synchronization.
Prerequisites
- The target system supports revision filtering.
This data is supplied by the system connector.
- types own a schema property which is labeled as a revision counter.
This schema property stores the information about the last object modifications.
Example of an Active Directory group:
- In the target system schema: UNS Changed
- In the One Identity Manager schema: Date
- Revision filtering permitted for this synchronization workflow.
Revision filtering can be applied to workflows and start up configuration. The workflow setting is valid for all synchronizations with this workflow. In order to synchronize with the same workflow at different times, with, and without revision filtering, create different start up configurations and specify revision filtering for them.
To permit revision filtering on a workflow
-
Open the in the .
- Edit the workflow properties. Select the Use revision filter item from Revision filtering menu.
For more information, see How to edit a workflow.
To permit revision filtering for a start up configuration
For more information, see How to edit start up configurations.
Normally, each object keeps information about the last changes made. The highest change data value of all synchronized objects of a schema type is taken as the revision in the One Identity Manager database (DPRRevisionStore table, DPRRevisionStore column). This value is used as a comparison for revision filtering when the same workflow is synchronized the next time. This means that when this workflow is next synchronized, the object change data is compared with the revision saved in the One Identity Manager database. This involves finding object pairs where one has newer change data than the last time it was synchronized. Thus, only objects that have changed since the last synchronization are updated.
The reference parameter for revision filtering is also the last schema type synchronization with the same workflow. The table DPRRevisionStore contains one entry per workflow and schema type.
NOTE: One Identity Manager supplies a scheduled process plan, which regularly cleans up the contents of the DPRAttachedDataStore table. Entries for schema types that are no longer used in the synchronization configuration are deleted in the process. The process plan is executed during daily .
Related topics
