Object Schema Mapping Definition
The Schema Mapping Definition configures both the inbound and outbound sides, i.e. how to map attributes from applications to the IDM (inbound), and vice-versa (outbound). It defines an Attributes Mapping Definition, which configures attribute mappings for both inbound and outbound sides.
Overview
The Schema Mapping Definition configures both the inbound and outbound sides, i.e. how to map attributes from applications to the IDM (inbound), and vice-versa (outbound). It defines an Attributes Mapping Definition, which configures attribute mappings for both inbound and outbound sides.
In fact, the schema mappings are configurable per Object Type. Thus, the Schema Mapping Definition contains a list of Object Schema Mapping Definition, one per target Object Type.
Attribute mappings compute target attribute values. The computation may be configured according to strategies. As usual, there are 2 strategies available, and one and only one strategy must be chosen to map an attribute value:
simple attribute mapping strategy: the most basic configuration, suitable for simple needs. The attribute value(s) of an account are simply mapped to a target object attribute value(s). An optional Compute Rule may be evaluated in between to transform an account's input attribute value. The Compute Rule will be typically implemented with a Groovy script. If the attribute is multi-valued then each value is iterated over when evaluating the Compute Rule (if any is configured)
custom attribute mapping strategy: the most flexible configuration, meant to answer complex business cases. A Compute Rule implemented with a Groovy script is evaluated to produce a single value or a list of values. The Groovy script has tools at disposal, namely a method enabling to perform searches (more on that later)
Configuration
objectSchemaMappingDefinition Properties
Each objectSchemaMappingDefinition will have the following configuration:
Property Name | Type | Mandatory | Description | Values(default value in bold) |
---|---|---|---|---|
objectType |
| NO * | The target Object Type (as a simple String) such as "employee", "partner", etc. If not specified then the default type will apply as configured in (*) Among the list of | - |
objectClassId |
| YES | The class of objects to search on the external application. It must be coherent with | inetOrgPerson for LDAP, __ACCOUNT__ for CSV, etc. |
shadowKind |
| YES | The kind of Shadow corresponding to the technical Must be coherent with | ACCOUNT, ORGANIZATION, ENTITLEMENT |
enabled |
| NO | Whether this object schema mapping is enabled or not | true, false |
- | NO | The list of of inbound attributes mappings (see | - | |
- | NO | The list of of outbound attributes mappings (see | - | |
- | NO | Makes sense for the outbound case only. Configure how to search remote Application objects that may match a given object. See | - | |
- | NO | Makes sense for the outbound case only. Configure how to react in provisioning terms to events such as an object is deleted. | - |
applicationObjectLookupDefinition properties
This is the equivalent of the inbound Correlation Definition for the outbound case.
Configure how to search on a remote Application objects (Shadows) that could match a given IDM object.
Available Application Object lookup strategy is :
Simple Lookup Strategy Definition
Property Name | Type | Mandatory | Description |
---|---|---|---|
YES | The lookup configuration specific to the "attributes mapping" lookup strategy. |
simpleLookupStrategyDefinition properties
The Application Object lookup configuration specific to the "attributes mapping" lookup strategy.
This is the most basic lookup configuration, suitable for simple needs. The value of one or more attributes
of an IDM object are compared with the attribute(s) of the candidate Application Object.
A Normalize Rule may be evaluated in between to transform an IDM object's input attribute before
matching it with an Application Object's attributes. The Normalize Rule will be typically executed with a Groovy script.
Property Name | Type | Mandatory | Description |
---|---|---|---|
attributeLookupDefinitions | - | NO | If the list contains several attribute mappings they are ANDed together such as givenName = 'John' AND sn = 'Doe' This list must contain at least one element. |
attributeLookupDefinitions
Each objectSchemaMappingDefinition will have the following configuration:
Property Name | Type | Mandatory | Description |
---|---|---|---|
- | NO | The configuration of one attributeLookupDefinition. |
attributeLookupDefinition properties
Property Name | Type | Mandatory | Description |
---|---|---|---|
inputAttributeId |
| YES | The input object's attribute name (e.g. "login") whose value must match a target Application Object attribute. |
targetAttributeId |
| YES | The target Application Object attribute name (e.g. "uid" for a LDAP account) whose value must match input data. |
normalizeRule |
| NO | A Normalize Rule used to transform the input value(s) before comparing it with an Application Object attribute |
inboundAttributesMappingDefinitions or outboundAttributesMappingDefinitions properties
Regroup several attribute mappings. Note the plural "s" of this setting, not to be confused with Attribute Mapping Definition, which defines a single attribute mapping.
A container of attribute mappings that will be used to compute inbound or outbound rules.
Property Name | Type | Mandatory | Description |
---|---|---|---|
attributeMappingDefinitions | - | YES | The list of attribute mappings. |
validationRule |
| NO | A Validation Rule applied to the whole target IDM object, after all its attributes have been individually validated using |
- | NO | If the condition matches, then for the inbound case the input Shadow will be simply ignored, and for the outbound case the target Shadow will be ignored |
attributeMappingDefinitions properties
Each objectSchemaMappingDefinition will have the following configuration:
Property Name | Type | Mandatory | Description |
---|---|---|---|
- | NO | The configuration of one attributeMappingDefinition. The mapping computes the target attribute value(s). The computation is performed using a strategy. One and only one mapping strategy must be configured, among the 2 possible strategies. |
attributeMappingDefinition properties
Property Name | Type | Mandatory | Description | Values (default value in bold) |
---|---|---|---|---|
targetAttributeId |
| YES | The id of the attribute targeted by the mapping. | - |
targetAttributeType |
| NO | Give a hint about the target attribute type, useful to determine if attributes are equal or not when computing a patch to apply on an IDM object, see Attribute Types and Comparing Attribute Values. | STRING |
attributeValuePrecision | NO | Precision used to determine whether to attribute values are equal or not, see Comparing Attribute Values. The use of a precision is optional; if no precision is specified then strict equality is assumed. | - | |
mandatory |
| NO | Whether the computed target attribute value is mandatory or not. | true,false |
secret |
| NO | Whether the target attribute value is considered secret. | true,false |
validationRule |
| NO | A Validation Rule applied on the target attribute value(s) computed by this mapping. It comes in addition to | - |
- | NO | The simple attribute mapping strategy: source attribute to target attribute. | - | |
- | NO | The target attribute value is computed by a Groovy script. | - | |
mappingStrength |
| NO | Optional: the strength with which the mapping is applied, see Mapping Strength. | STRONG |
multiValued |
| NO | Boolean: whether the target attribute is multi-valued or not. Mono-valued assumed by default. If "true", then the ADDITIVE | true,false |
NO | Meaningful when this mapping holds a reference to an IDM object (or several references if the attribute is multi-valued). Mutually exclusive with other mapping strategies: "simple" and "custom". See Idm Identifier Resolution Definition | - | ||
syncChannel | NO | Limit application of this mapping only to a specific channel. If no channel is specified then the mapping will be applied for all channels. | - |
Mapping Strength
An optional "strength" may be associated with an attribute mapping. This defines whether the mapping source is authoritative or not. Note that the strength is configured for a given attribute mapping; different attributes may sport different strengths.
If no strength is configured, then "authoritative" (i.e. STRONG
) is assumed.
The following table lists the possible strengths:
Attribute Mapping Strength | Description |
---|---|
STRONG (default) | Authoritative mapping (the default): replace existing attribute value(s) with the mapped one(s), erasing old value(s). |
WEAK | Apply the mapping only if the target attribute does not have any value. This mapping strength is use to set initial (default) values for attributes. |
ADDITIVE | Pertains to multi-valued attributes only. Only add new value(s) if needed, never removing values. If the attribute is mono-valued, then this strength is equivalent to |
Comparing Attribute Values
When Synchronization service tries to determine whether changes occurred between a source and a target object, attribute values are compared. If attribute changes are detected, a "patch" is applied on the target object, so that the synchronization between the source and the target remains consistent.
By default, a strict equality between attribute values is evaluated to determine whether changes occurred or not. It is possible to soften this strict equality criterion, by configuring a "precision" allowing a "tolerance" when performing comparisons. This may help to avoid writing target values whereas no change "really" occurred, according to the required precision.
The following table lists the possible precision:
Precision Name | Attribute Type | Description |
---|---|---|
CASE_INSENSITIVE |
| Case-insensitive String comparison, e.g. "John" and "JOhN". |
UNACCENTED |
| Accent-insensitive String comparison, e.g. "Adèle" and "Adele". |
TRIMMED |
| Leading and trailing chars-insensitive String comparison, e.g. "John" and " John ". |
CASE_INSENSITIVE_UNACCENTED |
| Combine "case-insensitive" and "unaccented". |
CASE_INSENSITIVE_TRIMMED |
| Combine "case-insensitive" and "trimmed". |
UNACCENTED_TRIMMED |
| Combine "unaccented" and "trimmed". |
CASE_INSENSITIVE_UNACCENTED_TRIMMED |
| Combine "case-insensitive", "unaccented" and "trimmed". |
DAY |
| Dates are considered equal if their difference is less than one day. |
HOUR |
| Dates are considered equal if their difference is less than one hour. |
MINUTE |
| Dates are considered equal if their difference is less than one minute. |
SECOND |
| Dates are considered equal if their difference is less than one second. |
F0_1 |
| Floats are considered equal if their difference is less than one tenth. |
F0_01 |
| Floats are considered equal if their difference is less than one hundredth. |
F0_001 |
| Floats are considered equal if their difference is less than one thousandth. |
F0_0001 |
| Floats are considered equal if their difference is less than one ten thousandth. |
All other attribute types, such as INTEGER
or IDENTITY_REF
, require strict equality (see next section).
Attribute Types
To give a hint regarding possible precision evaluations, an attributes may be typed, such as String, Date, etc. If no type is explicitly configured then "String" is assumed.
The possible attribute types are:
STRING
(the default)INTEGER
FLOAT
BOOLEAN
DATE
DATETIME
IDENTITY_REF
ORGANIZATION_REF
RESOURCE_REF
simpleAttributeMappingStrategyDefinition properties
The simple attribute mapping strategy: source attribute to target attribute, with a possible transformation in-between.
Property Name | Type | Mandatory | Description |
---|---|---|---|
inputAttributeId | YES | The input attribute id (e.g. "uid" for an inbound LDAP mapping) whose value is mapped to the target attribute (see For inbound mappings, available attributes also include "built-in attributes", that must be configured using their armored format, e.g. "__objectId__". The list of inbound built-in attributes is provided in a later section, see Shadow Attributes. | |
inputValidationRule | NO | A Validation Rule applied on the input attribute value(s), e.g. the value of the "uid" attribute in the above example. | |
normalizeRule | NO | Optional: a Normalize Rule used to transform the input value before mapping it to the target attribute. The Normalize Rule will be typically executed with a Groovy script. |
customAttributeMappingStrategyDefinition properties
A Compute Rule is evaluated to compute the value of the target attribute. The Compute Rule will be typically executed with a Groovy script.
Property Name | Type | Mandatory | Description |
---|---|---|---|
computeRule |
| YES | The Compute Rule returning a |
computeRuleAttributeDependencies | - | NO | The list of attributes the Ideally this list should be automatically constructed when parsing the Groovy script, but, contrarily to Memority IDM Service, this feature has not been implemented in Synchronization service yet. So, for the moment, this list of attributes must be explicitly and manually configured:
|
idmIdentifierResolutionDefinition properties
It must be defined when the mapped attribute contains a reference to another IDM object (for example a "manager" attribute referencing an IDM Identity), and the reference value (which is the IDM identifier of the referenced IDM object) cannot be directly computed by an attribute mapping rule.
This configuration defines how to resolve the IDM identifier of the referenced IDM object..
Property Name | Type | Mandatory | Description | Values (default value in bold) |
---|---|---|---|---|
referencingAttributeId |
| Can be mandatory | The id of the attribute holding the reference, e.g. "manager". This property is mandatory if the resolution strategy involves the local Synchronization service repository, i.e. INTERNAL_REPOSITORY or INTERNAL_OR_CORRELATION. | - |
referencedObjectKind |
| NO | The referenced IDM object kind, which may be different from the referencing kind (e.g. an Identity referencing an Organization). If not provided, then the referencing Shadow's underlying Object Kind is assumed. | |
referencedObjectClassId | NO | Meaningful only if the identifier strategy retrieval involves the local Synchronization service repository (which is most common case): If not provided, then the referencing Shadow's underlying class is assumed. | ||
referencedObjectApplicationId |
| NO | Needed when:
If not provided, then the referencing Shadow's underlying application is assumed. | |
identifierResolutionStrategy |
| YES | The identifier resolution strategy. | INTERNAL_REPOSITORY: Lookup only in the local Synchronization service repository (most common case, fastest strategy, this is the default) IDM_CORRELATION : Lookup only in the remote IDM repository (rare case) |
correlationDefinition | - | Can be mandatory | Mandatory if the identifier resolution strategy involves IDM correlation i.e. IDM_CORRELATION or INTERNAL_OR_CORRELATION |
applicationObjectActivationDefinition properties
Configure how to react to an event such as "IDM object disabled" for a provisioned account.
Configure the provisioning operation to perform on an Application object for the following events:
an IDM object is deleted (either soft-deleted or hard-deleted)
an IDM object is disabled
an IDM object is no longer associated to the Application
Property Name | Type | Mandatory | Description |
---|---|---|---|
onIdmObjectDeleteEvent |
| NO | The provisioning operation performed in reaction to an IDM object deleted event (hard or soft delete). By default do nothing (NO_OP), which means the provisioning process is interrupted |
onIdmObjectDisableEvent |
| NO | The provisioning operation performed in reaction to an IDM object disabled event. By default it is null, meaning the provisioning process won't be interrupted when an IDM object is disabled, i.e. attribute mappings will be evaluated and the "regular" provisioning operation will go on. |
onApplicationUnassignedEvent |
| NO | The provisioning operation performed when a provisioned Application is no longer associated to an IDM object. By default do nothing (NO_OP), which means the provisioning process is interrupted. |
customAction |
| YES if a CUSTOM action is configured above | Optional: a compute Rule executed when the This Rule computes an The attributes contained in the patch are those of the application object, e.g. "givenName" for an LDAP account. The Rule's context contains:
A example of custom Action script :
CODE
|
objectIgnoredCondition properties
Configure a condition to ignore accounts. When synchronizing (inbound) and provisioning (outbound) accounts,
they will be marked as being "ignored" if this condition matches, i.e. they will be excluded from the synchronization/provisioning.
Accounts are typically ignored because they are "protected".
This concerns accounts such as "root", "administrator", that shall never we modified.
The account to be ignored is the "input" account, i.e.:
for the inbound case, it is the input Shadow
for the outbound case, it is the existing Shadow if it exists
Property Name | Type | Mandatory | Description |
---|---|---|---|
- | YES | If any condition matches in the list then the account is ignored |