Application

Definition

Application is the main synchronization configuration entry point. An "Application" conceptually designates a remote system, external to Synchronization Service, exposing a repository of accounts (or organizations), such as a LDAP directory, or a CSV file.

Usually an Application is configured to perform either “inbound” operations, such as importing a CSV file, or “outbound” operations, such as provisioning an LDAP directory. Technically, the same Application could be configured to perform both inbound and outbound operations, but this is a rare functional case, because most of the time there is a single “authoritative side”. For example, a HR CSV file is the unique “source of truth” to create or update IM Identities, and in turn IM Identities are the source of truth to create or update accounts in a LDAP directory.

The Application namely defines “attribute mappings”, i.e. how to map an IDM object’s attributes (such as a last name) with the attributes of an object belonging to a remote system, such as the columns of a CSV file or the attributes of an LDAP account.

Attribute mapping rules may vary according to the type of an IDM object, e.g. for an IDM object of type “employee” the mapped attributes could differ from an IDM object of type “partner”.

An Application's population may thus be divided into several IDM Object Types, hence the possible diversification, within an Application's configuration, of sub-configurations per Object Type, as shown in the schema below:

Among all sub-configurations segregated by Object Type, a single sub-configuration may have a null Object Type. This is the “default” sub-configuration, applied when no sub-configuration matching a given Object Type was found.

In the above schema, the term “Shadow” designates remote accounts known and registered into the Synchronization Service. A “Shadow” is thus the “projection” of an IDM object on a remote system, according to the configured attribute mapping rules.

In the same way as an IDM object, which can be of kind “Identity” or “Organization”, a Shadow has also a kind:

Shadow Kind	Corresponding IDM Object Kind	Note
ACCOUNT	IDENTITY
ORGANIZATION	ORGANIZATION
RESOURCE	RESOURCE
ROLE	ROLE
ROLE_PUBLICATION	ROLE_PUBLICATION
ENTITLEMENT	N/A	An “Entitlement” is a generic representation of an Application-side asset, such as a group, role, privilege, or access right. It is not mapped to an IDM object.

The term “Object Class Id” designates the technical class of an object on a remote system. For example, it can be inetOrgPerson for the provisioning of an LDAP directory. Accounts to sync are searched on the remote Application using this class criterion, even for the CSV Connector case when reading the CSV file.

The Object Class Id is fixed by convention to __ACCOUNT__ for the CSV Connector, the SQL Connector and the SAP Connector. The __ACCOUNT__ Object Class Id shall not be confused with the ACCOUNT Shadow Kind. A CSV file can indeed contain Organizations, whereas the Object Class Id remains fixed to __ACCOUNT__, because that’s a technical convention of the CSV Connector.

The triplet [Object Class Id, Shadow Kind, Object Type] enables to identify a configuration in a non-ambiguous way, for both inbound and outbound operations. This triplet must be unique for a given sub-configuration.

Configuration

You can access the Application configuration :

by clicking on "Synchronization" → "Applications"
by clicking on "System" → "Configurations"->”Synchronization Service” and perform an import/export.

Properties

The main configuration elements are :

Property Name	Type	Mandatory	Description
id	`String`	YES	The Application identifier.
name	`String`	YES	The Application name.
description	`String`	NO	The Application description.
citadelApplicationId	`String`	NO	The identifier of the Memority application, which enables to map a Memority application to a Synchronization service application. If not specified, it is supposed that Memority references the application directly using the `id` property.
connectorId	`String`	YES	The identifier of a Connector Definition.
synchronizationDefinition	-	YES	The configuration of the inbound synchronization.
schemaMappingDefinition	-	YES	The configuration of attribute mappings (inbound or outbound).

synchronizationDefinition properties

The Synchronization Definition configures the inbound side, i.e. the synchronization behaviour when performing reconciliation, import of live synchronization tasks. It defines:

how to map an application account to an Object Type, via the Object Type Resolution Definition
how to perform the correlation process to determine a synchronization situation, via the Correlation Definition
how to react to a synchronization situation, via a Synchronization Reaction Definition

In fact, the correlation and reaction are configurable per IDM Object Type. Thus, the Synchronization Definition contains a list of Object Synchronization Definition, one per target Object Type.

If the Object Type is configured to null, then the Object Synchronization Definition is considered the default one.

Property Name	Type	Mandatory	Description	Values (default value in bold)
objectTypeResolutionDefinition	-	YES	The configuration enabling to resolve the target Object Type from an application account properties.	-
objectSynchronizationDefinitions	-	YES	The list of inbound synchronization configurations per Object Type. This list must contain at least one element.	-
objectTypeMigrationAllowed	`Boolean`	NO	Whether migrating from one Object Type to another is allowed or not (for example from "partner" to "employee"). This is a safeguard against unwanted type migrations that could be involuntarily triggered by inaccurate information within data to import.	true, false

objectTypeResolutionDefinition properties

An account belonging to a remote application must be "transposed" to an IDM object. Thus the target IDM object type must be determined, such as "employee" or "partner", from the account properties. This is achieved via an Object Type Resolution Definition. It configures the object type resolution process according to a list of Object Type Assignment Rules. An object type is associated with each rule. The first matching rule wins; the rule's object type is then assigned. If no rule matches, a default IDM object type is assigned. Each rule is configured using a strategy, among 2 possible strategies (one and only one strategy must be chosen for each rule):

simple object type assignment strategy: the most basic configuration, suitable for simple needs. If the value of an account attribute matches a configured regex, the rule matches
custom object type assignment strategy: the most flexible configuration, meant to answer complex business cases. It is based on the execution of a custom Groovy script that must return a Boolean value, indicating whether the rule matches or not

Determining early the target IDM object type is essential because synchronization and attribute mapping settings can be configured per IDM object type. Once the target object type is known, then the other appropriate synchronization settings can be applied during the synchronization process.

Property Name	Type	Mandatory	Description
defaultObjectTypeId	`String`	YES	Object Type that is assigned by default when no assignment rule matches, e.g. "employee".
assignmentRules	`Rule`	NO	Mutually exclusive with custom Assignment Rule. The Object Type of the first matching rule is assigned. If this list is empty then default Object Type Id will prevail.
customAssignmentRule	`Rule`	NO	Mutually exclusive with assignment Rules. A Compute Rule returning the Object Type as a String, which may be null. If null then default Object Type Id will prevail.

assignmentRule properties

The configuration of a rule determining whether or not an Object Type may be assigned to an account.

Property Name	Type	Mandatory	Description
objectTypeId	`String`	YES	The Object Type assigned when the rule matches, e.g. "partner".
objectMatchingCondition	-	YES	The rule matching condition.

objectSynchronizationDefinitions properties

The inbound synchronization configuration for a specific Object Type (such as "employee").

Property Name	Type	Mandatory	Description
name	`String`	NO	An optional name only used to enhance the configuration display in the admin console GUI.
objectType	`String`	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 Object Type Resolution Definition. () Among the list of Object Synchronization Definitions, only one* is allowed to have a null object Type field. All object Types may be non null, but there cannot be more than one null object Type.
objectClassId	`Enum`	YES	The class of objects to search on the external application: "inetOrgPerson" for LDAP, "__ACCOUNT__" for CSV, "Identity" for Mongo Collection,etc. It must be coherent with `objectKind`.
shadowKind	`Enum`	YES	The kind of Shadow corresponding to the technical `objectClassId`, among: `ACCOUNT`, `ORGANIZATION`, `RESOURCE,ROLE,ROLE_PUBLICATION,ENTITLEMENT`. Must be coherent with `objectClassId`.
enabled	`Boolean`	NO	Whether this synchronization configuration is enabled or not (true by default).
correlationDefinition	-	YES	The correlation configuration used to determine the owner of an application account.
reactionDefinitions	`List<reactionDefinition>`	NO	The list of reactions to apply when a synchronization situation occurs. The list may be empty but this is not recommended.
synchronizationActionDecisionDefinition	-	NO	If defined it prevails on the above standard reaction Definitions
customAction	`Rule`	NO	A Compute Rule Definition, it must be defined if a `CUSTOM` action has been configured in reaction to a sync situation. The rule computation result must be of type `ObjectPatch` . This feature is mainly used to generate a custom patch for the `DELETED` sync situation (typically CSV lines that are no longer present in a CSV files), instead of the standard builtin reactions like `SOFT_DELETE_IDM_OBJECT` or `SOFT_DELETE_IDM_OBJECT` By convention, if the rule execution returns `null` then no action is performed. A example of custom Action script : CODE `return MANAGE.newPatch() .set("company").value("custom_company") .get()`

correlationDefinition properties

Correlation

Correlation is a mechanism enabling to identify potential IDM owner(s) of a given application account. The Correlation process takes information from the account and constructs a search query. This query is then used to locate IDM owner(s). The result of the correlation process is categorized into a synchronization situation as explained in the previous sections.

Number of IDM objects found after correlation	Synchronization situation
0	`UNMATCHED`
1	`UNLINKED`
> 1	`DISPUTED`

The Correlation Definition configures the correlation process, according to 2 possible strategies (one and only strategy must be chosen):

simple correlation strategy: the most basic configuration, suitable for simple needs. The value of one or more attributes of an account are simply compared with the attribute(s) of the candidate IDM objects. An optional Compute Rule may be evaluated in between to transform an account's input attribute before matching it with an IDM object attribute. The Compute Rule will be typically implemented with a Groovy script
custom correlation strategy: the most flexible configuration, meant to answer complex business cases. A Compute Rule is evaluated to produce a Correlation Result. The Compute Rule will be executed by a Groovy script performing the complex business search(es) using a Object Finder available in the Groovy context (more on that later)

Optional correlation metadata may be recorded by a custom Groovy script during the correlation process, to keep track of information that will be later helpful during the inbound attributes mapping step, namely to conditionally map some attributes or not when executing custom mappings also implemented by Groovy scripts. This will be detailed in a later section about crafting custom Groovy scripts.

The correlation configuration used to determine the IDM owner of an application account.

One and only one correlation strategy must be configured, among the 2 possible strategies.

Property Name	Type	Mandatory	Description
simpleCorrelationStrategyDefinition	-	NO	Simple attribute(s) value(s) comparison: search IDM objects based on one or more attribute values.
customCorrelationStrategyDefinition	-	NO	Evaluation of a custom Groovy Script, performing the IDM search, and producing a `CorrelationResult` containing the IDM object(s) found.

simpleCorrelationStrategyDefinition properties

The value of one or more attributes of an application account are compared with the attribute(s) of the candidate IDM objects.

A SearchExpression is built using the given attribute mappings (see AttributeCorrelationDefinition below).

If several mappings are provided (e.g. for "login" and "email") then they are AND ed together such as: login=jdoe AND email=john.doe@acme.com.

If an attribute is multi-valued then the attribute values arORed together such as: login=jdoe AND (email=john.doe@acme.com OR email=jdoe@internal.acme.com.

Property Name

Type

Mandatory

Description

attributeCorrelationDefinitions

-

YES

The list of attributes participating in the Correlation process, see Attribute Correlation Definition. Must contain at least one element.

If the list contains several attributes they are ANDed together such as to produce: firstName = 'John' AND lastName = 'Doe'

attributeCorrelationDefinitions properties

The configuration of the attribute mapping used to correlate an application account with a object(s).

Property Name

Type

Mandatory

Description

inputAttributeId

String

YES

The input application account's attribute id (e.g. "uid" for a LDAP account) whose value must match a target Object attribute.

Available attributes also include "built-in attributes", that must be configured using their armored format, e.g. "__objectId__".

The list of built-in attributes is provided in a later section.

idmAttributeId

String

YES

The target object attribute name (e.g. "login") whose value must match the value of inputAttributeId.

normalizeRule

Rule

NO

Optional: a Normalize Rule used to transform the input value before comparing it with an IDM object attribute. The Normalize Rule will be typically executed with a Groovy script.

customCorrelationStrategyDefinition properties

A Compute Rule is evaluated to produce a CorrelationResult. The Compute Rule will be typically executed with a Groovy script performing the complex business search(es)
using a ObjectFinder available in the Groovy Context.

Property Name	Type	Mandatory	Description
computeRule	`Rule`	YES	The Compute Rule returning `CorrelationResult`. It is up to the Compute Rule to search for IDM objects using an `ObjectFinder` and compute the `CorrelationResult`.

customCorrelationStrategyDefinition Example

XML

               <correlationDefinition>
                  <customCorrelationStrategyDefinition>
                     <computeRule>
                        <script><![CDATA[                                    
                                    import com.memority.toolkit.core.api.search.expression.SearchExpression

                                    # The CSV file contains the "FirstName" and "LastName" columns
                                    String firstName = SHADOW.FirstName
                                    String lastName = SHADOW.LastName
                                    
                                    if (firstName && lastName) {
                                        LOG.info("My import - Correlation on firstName {}, lastName {}", firstName, lastName)
                                        SearchExpression searchExpression = expr {
                                            prop('type').eq("internal")
                                                    .and(prop('firstName').eq(firstName))
                                                    .and(prop('lastName').eq(lastName))                                                    
                                        }
                                        
                                        List<ApiObject> identities = FIND.identity().allMatching(searchExpression)
                                        LOG.info("My import - {} correlated identity(ies) found matching firstName {} and lastName {}", identities.size(), firstName, lastName)
                                        return new CorrelationResult(identities).addCorrelationContext("My import - Correlation step", "firstName + lastName")
                                    }  else {
                                        return CorrelationResult.error("Missing FirstName and/or LastName")
                                    }                                   
								]]></script>
                     </computeRule>
                  </customCorrelationStrategyDefinition>
               </correlationDefinition>

reactionDefinitions properties

Property Name	Type	Mandatory	Description
reactionDefinition	`reactionDefinition`	NO	Configuration of the reaction to a synchronization situation.

reactionDefinition properties

Each reactionDefinition will have the following configuration:

Property Name	Type	Mandatory	Description
name	`String`	NO	An optional name only used to enhance the configuration display in the admin console GUI.
situation	`Enum`	YES	The synchronization situation triggering this reaction ("unmatched", "linked", etc.) The possible values are listed in Synchronization Situations.
actions	-	NO *	The list of actions to apply in reaction to `situation` (may be empty, but not recommended). The possible values are listed in Reactions to Synchronization Situations.

Synchronization Situations

A synchronization event is categorized into a synchronization situation (or simply "situation"). Determining a situation is important because reactions may be configured.

The situation deals only with the existence or non-existence of an application account (e.g. a LDAP account), and with ownership of the account by an IDM object. In other words, it deals only with "links": an account is linked to an IDM object. It does not deal with the legality of the account (whether an IDM Identity should have an LDAP account). The situation also does not deal with changes in account attributes, this is the role of the "reaction".

The situation is evaluated by the correlation process, consisting in finding potential IDM owner(s) for the account (more on that later).

The following algorithm is used to determine a situation:

if the account has been deleted then the situation is "deleted"
the account's owner is looked up in the internal Synchronization service repository. If an owner is found then the situation is "linked"
if there is no current IDM owner referenced in the Synchronization service repository then the correlation is used to determine potential IDM owner(s) for the account. If potential owner(s) are found, the situation is either:
- "unlinked" (single owner)
- "disputed" (several owners)
no owner found: the situation is "unmatched"

The list of possible situations is summarized in the following table:

Situation	Description	Examples
`LINKED`	Nominal case: an account is linked to an IDM object. They are synchronized.	An attribute of a remote application account was changed and it is reflected to the owning IDM object.
`UNLINKED`	An account is found on the remote application, the correlation process determines exactly one existing IDM owner for that account, and the IDM owner does not have the account linked (yet)	The IDM repository is already populated with IDM objects and a new application whose repository is also already populated with accounts is registered to Synchronization service.
`DELETED`	An account does not exist on the remote application anymore. It is still referenced in Synchronization service’s internal repository but no account in the remote application matches it.	A legal account is manually deleted on the remote application.
`UNMATCHED`	An account is found on the remote application, and no matching IDM owner was found for the account by the correlation process.	Initial import, or the account was created on the remote application using native administration tools.
`DISPUTED`	An account is found on the remote application, and two or more potential IDM owners are found for it by the correlation process.	An ambiguous account is created manually on the remote application, e.g. using a login `smith` that matches the surname of several IDM Identities.
`COLLISION`	Should never happen: the account is linked to two or more IDM objects.	Bug or inconsistent database.

Reactions to Synchronization Situations

Once a synchronization situation has been determined, reaction(s) happen. Reactions are configurable. Several reactions may be associated with a given situation.

When the synchronization task type is "import", the reaction is always forced to "add an IDM object". To implement a more flexible behavior, where for example it is not desired to create new IDM objects but only update existing ones, just configure a synchronization task of type “reconciliation”, and configure a “NO_OP” reaction to the “DELETED” situation.

The list of possible reactions of class SyncAction is summarized in the following table:

Reaction	Description	Compatible Situations	Examples
`SYNCHRONIZE_IDM_OBJECT`	Reflect the account changes to the corresponding existing IDM object	`LINKED`	An attribute of a remote application account was modified by a local application's administrator.
`ADD_IDM_OBJECT`	Add an IDM object	`UNMATCHED`	Initial import.
`DELETE_IDM_OBJECT`	Remove an IDM object	`DELETED`	When an application account is deleted then the corresponding IDM owner must also be deleted.
`INACTIVATE_IDM_OBJECT`	Inactivate an IDM object	`DELETED`	When an application account is deleted then the corresponding IDM owner must be deactivated.
`SOFT_DELETE_IDM_OBJECT`	Soft delete an IDM object	`DELETED`	When an application account is deleted then the corresponding IDM owner must be soft deleted.
`ADD_APPLICATION_OBJECT`	Add an account on the remote application	`DELETED`	An account was accidentally deleted by a local application's administrator; it must be re-created.
`DELETE_APPLICATION_OBJECT`	Remove an account from the remote application	`UNMATCHED` `UNLINKED` `DISPUTED`	"Unmatched" and "unlinked": Non authoritative application. An "illegal" account was created on the Application using native administration tools. "Disputed": remove ambiguous application accounts that were created manually on the Application.
`INACTIVATE_APPLICATION_OBJECT`	Inactivate an account on the remote application	`UNMATCHED` `UNLINKED` `DISPUTED`	Idem above.
`LINK`	Link (i.e. mark as "synchronized") an account and an IDM object	`UNLINKED`	An existing application account and a matching IDM owner have been created separately in their respective repositories, but they were not synchronized. They will be now.
`UNLINK`	Unlink (i.e. mark as "not synchronized anymore") an account and an IDM object	`DELETED`	An account was deleted on purpose by a local application's administrator; no further synchronization attempt should be performed anymore.
`NO_OP`	Do nothing, ignore the Shadow	N/A	Typically configured by an `ActionDecisionRule`.
`CUSTOM`	Patch an IDM object (inbound case) or a remote application account (outbound case)	`DELETED`	When an application account is deleted then the corresponding IDM owner must be patched. Do to this a configured custom action is applied.

Some reactions are implicit, i.e. they occur even if they are not explicitly configured. For example, after a new application account has been successfully imported into the IDM, i.e. a new IDM object has been created, the application account and the IDM object are linked.

synchronizationActionDecisionDefinition properties

Pertains to the inbound case only. Enable to configure more finely the action(s) to execute during a synchronization task, namely according to the input data, instead of solely relying on SynchronizationReactionDefinition.

Property Name	Type	Mandatory	Description
decisionRules	`List<ActionDecisionRule>`	NO	Mutually exclusive with `customDecisionRule` (see below). The list of `ActionDecisionRule`. All the rules are evaluated, and all the actions configured with all matching rules will be aggregated to form a list. See Action Decision Rule.
customDecisionRule	`Rule`	NO	Mutually exclusive with `decisionRules` (see above). A Compute Rule returning the actions as a `List<SyncAction>` or a single `SyncAction`. The returned list may be empty or null. If the returned list is empty or null then `defaultActions` will prevail (see below).
defaultActions	`List<SyncAction>`	NO	Optional: the default action(s) to perform when no decision rule matches (see `decisionRules` or `customDecisionRule` fields above). If not configured, then the "standard" `SynchronizationReactionDefinition` will be applied if no decision rule matches.

decisionRules properties

The content of an element of the decisionRules list field of a SynchronizationActionDecisionDefinition (see above section). It represents the configuration of a rule determining which synchronization action(s) to execute when the rule matches (see Synchronization Action Decision Definition).

Property Name	Type	Mandatory	Description
actions	-	YES	The action(s) to perform when the rule matches, as a list of `SyncAction`.
objectMatchingCondition	-	YES	The rule matching condition.

Example of a SynchronizationActionDecisionDefinition with a custom Rule stating to do nothing (“no op”) if the IDM object does not possess “some_attribute”. If the IDM object possesses the attribute then it is synchronized as usual.

XML

            <synchronizationActionDecisionDefinition>
               <customDecisionRule>
                  <script><![CDATA[if (IDM_OBJECT?.some_attribute) { return [] } else { return SyncAction.NO_OP }]]></script>
               </customDecisionRule>
               <decisionRules/>
            </synchronizationActionDecisionDefinition>

Example of a SynchronizationActionDecisionDefinition with a list of ActionDecisionRules. In this somewhat contrived example, if the last name of the IDM object matches “Doe”, then the IDM object is synchronized. No operation is performed otherwise.

XML

            <synchronizationActionDecisionDefinition>
               <decisionRules>
                  <decisionRule>
                     <actions>
                        <action>SYNCHRONIZE_IDM_OBJECT</action>
                     </actions>
                     <objectMatchingCondition>
                        <objectKind>ACCOUNT</objectKind>
                        <objectTypes/>
                        <simpleObjectMatchingStrategyDefinition>
                           <inputAttributeId>lastName</inputAttributeId>
                           <regex>Doe</regex>
                        </simpleObjectMatchingStrategyDefinition>
                     </objectMatchingCondition>
                  </decisionRule>
               </decisionRules>
               <defaultActions>
                  <action>NO_OP</action>
               </defaultActions>
            </synchronizationActionDecisionDefinition>

schemaMappingDefinition properties

Property Name	Type	Mandatory	Description
objectSchemaMappingDefinitions	-	YES	The list of attribute mapping configurations per Object Type. This list must contain at least one element.

LDAP Provisioning Considerations

This section contains elements specific to the LDAP provisioning.

An LDAP entry possesses some "special" attributes:

DN
objectClass

When provisioning an LDAP entry, those 2 attributes must be set. They have specific target mapping names, imposed by the Evolveum LDAP connector conventions (see table below). Other LDAP attribute mappings, such as "givenName" or "uid", have the usual target names, such as "givenName" or "uid".

LDAP Attribute

Target Attribute Mapping Name

Attribute Mapping Example

DN

__NAME__

CODE

                            <attributeMappingDefinition>
                                <targetAttributeId>__NAME__</targetAttributeId>
                                <targetAttributeType>STRING</targetAttributeType>
                                <mandatory>true</mandatory>
                                <simpleAttributeMappingStrategyDefinition>
                                    <inputAttributeId>id</inputAttributeId>
                                    <normalizeRule type="NORMALIZE" category="ATTRIBUTE" engineType="JAVA">
                                        <spec><![CDATA[constructDnFromRdnOpenAm:com.memority.domino.service.sync.domain.init.openam.ConstructDnFromRdnOpenAmRule]]></spec>
                                        <config xsi:type="dmn:ConstructDnFromRdnOpenAmRuleConfigurationType">
                                            <baseDn>ou=people,dc=example,dc=com</baseDn>
                                            <rdnAttributeName>uid</rdnAttributeName>
                                        </config>
                                    </normalizeRule>
                                </simpleAttributeMappingStrategyDefinition>
                            </attributeMappingDefinition>

Where ConstructDnFromRdnOpenAmRule is a Java Rule helping formatting DNs (it could be a Groovy script returning a DN as a String)

objectClass

__AUXILIARY_OBJECT_CLASS__

If a provisioned LDAP entry should have the objectClass attribute multi-valued as:

top
person
organizationalPerson
inetOrgPerson
iamUser (the main class)

then the following attribute mapping must be configured:

CODE

                            <attributeMappingDefinition>
                                <targetAttributeId>__AUXILIARY_OBJECT_CLASS__</targetAttributeId>
                                <targetAttributeType>STRING</targetAttributeType>
                                <multiValued>true</multiValued>
                                <customAttributeMappingStrategyDefinition>
                                    <computeRule type="COMPUTE" category="OBJECT" engineType="GROOVY">
                                        <spec><![CDATA[
                                            ["top", "person", "organizationalPerson", "inetOrgPerson"]
                                            ]]></spec>
                                    </computeRule>
                                </customAttributeMappingStrategyDefinition>
                            </attributeMappingDefinition>

Note that this list does not contain the main iamUser object class, because it is already defined in the <objectClassId> section of the schema mapping:

CODE

                    <objectClassId>
                        <value>iamUser</value>
                    </objectClassId>

Example

Here is an XML representation of an Application.

Application example

CODE

<dmn:Application id="my_application" 
xmlns:search="http://www.memority.com/toolkit/search-expression/1_0" 
xmlns:rule="http://www.memority.com/toolkit/rule/1_0">
    <name>Name of my_application</name>
    <description>Description of my_application</description>
    <connectorId>my_connector</connectorId>
    <schemaMappingDefinition>
        <objectSchemaMappingDefinitions>
            <objectSchemaMappingDefinition>
                <enabled>true</enabled>
                <inboundAttributesMappingDefinitions>
                    <attributeMappingDefinitions>
                        <attributeMappingDefinition>
                            <targetAttributeId>attr-target-1</targetAttributeId>
                            <targetAttributeType>STRING</targetAttributeType>
                            <mandatory>true</mandatory>
                            <validationRule type="VALIDATION" category="ATTRIBUTE" engineType="JAVA">
                                <spec>validationRegex:com.memority.toolkit.rule.domain.model.builtin.RegexValidationRule</spec>
                                <rule:RegexValidationConfiguration>
                                    <regex>.*</regex>
                                </rule:RegexValidationConfiguration>
                            </validationRule>
                            <simpleAttributeMappingStrategyDefinition>
                                <inputAttributeId>attr-input-1</inputAttributeId>
                                <inputValidationRule type="VALIDATION" category="ANY" engineType="GROOVY">
                                    <spec>return null</spec>
                                </inputValidationRule>
                                <normalizeRule type="NORMALIZE" category="ANY" engineType="GROOVY">
                                    <spec>return null</spec>
                                </normalizeRule>
                            </simpleAttributeMappingStrategyDefinition>
                            <multiValued>false</multiValued>
                        </attributeMappingDefinition>
                        <attributeMappingDefinition>
                            <targetAttributeId>attr-target-2</targetAttributeId>
                            <targetAttributeType>STRING</targetAttributeType>
                            <mandatory>true</mandatory>
                            <validationRule type="VALIDATION" category="ATTRIBUTE" engineType="JAVA">
                                <spec>validationRegex:com.memority.toolkit.rule.domain.model.builtin.RegexValidationRule</spec>
                                <rule:RegexValidationConfiguration>
                                    <regex>.*</regex>
                                </rule:RegexValidationConfiguration>
                            </validationRule>
                            <simpleAttributeMappingStrategyDefinition>
                                <inputAttributeId>attr-input-2</inputAttributeId>
                                <inputValidationRule type="VALIDATION" category="ANY" engineType="GROOVY">
                                    <spec>return null</spec>
                                </inputValidationRule>
                                <normalizeRule type="NORMALIZE" category="ANY" engineType="GROOVY">
                                    <spec>return null</spec>
                                </normalizeRule>
                            </simpleAttributeMappingStrategyDefinition>
                            <multiValued>false</multiValued>
                        </attributeMappingDefinition>
                        <attributeMappingDefinition>
                            <targetAttributeId>attr-input-4</targetAttributeId>
                            <targetAttributeType>STRING</targetAttributeType>
                            <mandatory>true</mandatory>
                            <customAttributeMappingStrategyDefinition>
                                <computeRule type="COMPUTE" category="ANY" engineType="GROOVY">
                                    <spec>return null</spec>
                                </computeRule>
                            </customAttributeMappingStrategyDefinition>
                            <multiValued>false</multiValued>
                        </attributeMappingDefinition>
                    </attributeMappingDefinitions>
                    <objectIgnoredCondition>
                        <objectMatchingConditions>
                            <objectMatchingCondition>
                                <objectKind>ACCOUNT</objectKind>
                                <objectTypes>
                                    <objectType>matching-type1</objectType>
                                </objectTypes>
                            </objectMatchingCondition>
                            <objectMatchingCondition>
                                <objectKind>ACCOUNT</objectKind>
                                <objectTypes>
                                    <objectType>matching-type2</objectType>
                                </objectTypes>
                            </objectMatchingCondition>
                        </objectMatchingConditions>
                    </objectIgnoredCondition>
                </inboundAttributesMappingDefinitions>
                <objectClassId>
                    <value>inetOrgPerson</value>
                </objectClassId>
                <objectType>objectType1</objectType>
                <shadowKind>ACCOUNT</shadowKind>
            </objectSchemaMappingDefinition>
        </objectSchemaMappingDefinitions>
    </schemaMappingDefinition>
    <synchronizationDefinition>
        <objectTypeMigrationAllowed>false</objectTypeMigrationAllowed>
        <objectSynchronizationDefinitions>
            <objectSynchronizationDefinition>
                <correlationDefinition>
                    <simpleCorrelationStrategyDefinition>
                        <attributeCorrelationDefinitions>
                            <attributeCorrelationDefinition>
                                <inputAttributeId>sn</inputAttributeId>
                                <idmAttributeId>lastName</idmAttributeId>
                                <normalizeRule type="NORMALIZE" category="ANY" engineType="GROOVY">
                                    <spec>return null</spec>
                                </normalizeRule>
                            </attributeCorrelationDefinition>
                        </attributeCorrelationDefinitions>
                    </simpleCorrelationStrategyDefinition>
                </correlationDefinition>
                <enabled>true</enabled>
                <name>Name for type objType1</name>
                <objectClassId>
                    <value>inetOrgPerson</value>
                </objectClassId>
                <objectType>objType1</objectType>
                <reactionDefinitions>
                    <reactionDefinition>
                        <actions>
                            <action>ADD_IDM_OBJECT</action>
                            <action>LINK</action>
                        </actions>
                        <name>name1</name>
                        <situation>LINKED</situation>
                        <syncChannel>IMPORT</syncChannel>
                    </reactionDefinition>
                    <reactionDefinition>
                        <actions>
                            <action>ADD_IDM_OBJECT</action>
                            <action>LINK</action>
                        </actions>
                        <name>name2</name>
                        <situation>LINKED</situation>
                        <syncChannel>IMPORT</syncChannel>
                    </reactionDefinition>
                </reactionDefinitions>
                <shadowKind>ACCOUNT</shadowKind>
                <synchronizationActionDecisionDefinition>
                    <decisionRules>
                        <decisionRule>
                            <actions>
                                <action>ADD_IDM_OBJECT</action>
                            </actions>
                            <objectMatchingCondition>
                                <objectKind>ACCOUNT</objectKind>
                                <objectTypes/>
                                <simpleObjectMatchingStrategyDefinition>
                                    <inputAttributeId>givenName</inputAttributeId>
                                    <regex>matching-jdoe</regex>
                                </simpleObjectMatchingStrategyDefinition>
                            </objectMatchingCondition>
                        </decisionRule>
                    </decisionRules>
                    <defaultActions>
                        <action>LINK</action>
                    </defaultActions>
                </synchronizationActionDecisionDefinition>
            </objectSynchronizationDefinition>
            <objectSynchronizationDefinition>
                <correlationDefinition>
                    <customCorrelationStrategyDefinition>
                        <computeRule type="COMPUTE" category="ANY" engineType="GROOVY">
                            <spec>return null</spec>
                        </computeRule>
                    </customCorrelationStrategyDefinition>
                </correlationDefinition>
                <enabled>true</enabled>
                <name>Name for type objType2</name>
                <objectClassId>
                    <value>inetOrgPerson</value>
                </objectClassId>
                <objectType>objType2</objectType>
                <reactionDefinitions>
                    <reactionDefinition>
                        <actions>
                            <action>ADD_IDM_OBJECT</action>
                            <action>LINK</action>
                        </actions>
                        <name>name1</name>
                        <situation>LINKED</situation>
                        <syncChannel>IMPORT</syncChannel>
                    </reactionDefinition>
                    <reactionDefinition>
                        <actions>
                            <action>ADD_IDM_OBJECT</action>
                            <action>LINK</action>
                        </actions>
                        <name>name2</name>
                        <situation>LINKED</situation>
                        <syncChannel>IMPORT</syncChannel>
                    </reactionDefinition>
                </reactionDefinitions>
                <shadowKind>ACCOUNT</shadowKind>
                <synchronizationActionDecisionDefinition>
                    <decisionRules>
                        <decisionRule>
                            <actions>
                                <action>ADD_IDM_OBJECT</action>
                            </actions>
                            <objectMatchingCondition>
                                <objectKind>ACCOUNT</objectKind>
                                <objectTypes/>
                                <simpleObjectMatchingStrategyDefinition>
                                    <inputAttributeId>givenName</inputAttributeId>
                                    <regex>matching-jdoe</regex>
                                </simpleObjectMatchingStrategyDefinition>
                            </objectMatchingCondition>
                        </decisionRule>
                    </decisionRules>
                    <defaultActions>
                        <action>LINK</action>
                    </defaultActions>
                </synchronizationActionDecisionDefinition>
            </objectSynchronizationDefinition>
        </objectSynchronizationDefinitions>
        <objectTypeResolutionDefinition>
            <defaultObjectTypeId>default_type</defaultObjectTypeId>
            <assignmentRules>
                <assignmentRule>
                    <objectTypeId>type1</objectTypeId>
                    <objectMatchingCondition>
                        <objectKind>ACCOUNT</objectKind>
                        <objectTypes/>
                        <simpleObjectMatchingStrategyDefinition>
                            <inputAttributeId>attr1</inputAttributeId>
                            <regex>1_.+</regex>
                        </simpleObjectMatchingStrategyDefinition>
                    </objectMatchingCondition>
                </assignmentRule>
                <assignmentRule>
                    <objectTypeId>type2</objectTypeId>
                    <objectMatchingCondition>
                        <objectKind>ACCOUNT</objectKind>
                        <objectTypes/>
                        <customObjectMatchingStrategyDefinition>
                            <conditionRule type="CONDITION" category="ANY" engineType="GROOVY">
                                <spec>return null</spec>
                            </conditionRule>
                        </customObjectMatchingStrategyDefinition>
                    </objectMatchingCondition>
                </assignmentRule>
            </assignmentRules>
        </objectTypeResolutionDefinition>
    </synchronizationDefinition>
</Application>

Configuration

Properties

synchronizationDefinition properties

objectTypeResolutionDefinition properties

assignmentRule properties

objectSynchronizationDefinitions properties

correlationDefinition properties

Correlation

simpleCorrelationStrategyDefinition properties

attributeCorrelationDefinitions properties

customCorrelationStrategyDefinition properties

reactionDefinitions properties

reactionDefinition properties

Synchronization Situations

Reactions to Synchronization Situations

synchronizationActionDecisionDefinition properties

decisionRules properties

schemaMappingDefinition properties

LDAP Provisioning Considerations

Example

Read Next