Child pages
  • 4. Situation Handling for Sync
Skip to end of metadata
Go to start of metadata

This page is work in progress and might contain errors or lack some steps. Still it should contain lots of useful information. It is currently based on rev. 464!

Introduction

The importance of the situation/action pair for the different possibilities was covered in the to first chapters of the run book already. Here the use of the complete set of situations and necessary actions, which need to be set depending on the relation ship between OpenIDM and external resource will be discussed. The relationship on OpenIDM and external resource depends on which system is supposed to be the leading system for object or attribute create and object or attribute update. Very often user objects are created in the HR system and then, depending of the role of the user in the organization, some extra attributes or resources need to be configured for the new user. The user may or may not have an account on some other external resources already. All that needs to be handled by the sync configuration in the right way.

About

In this chapter synchronization configurations for the very different requirements of user created externally, user created on OpenIDM, user exists on the peer system, user deleted on one system and so on will be handled.

Prerequisites

A running, fresh OpenIDM and OpenDJ server. OpenIDM needs to connect to OpenDJ.
One user in ldap, OpenIDM repository empty.

Delete the complete openidm/conf folder including sub-folders and unzip
config447_04Start.zip in the openidm folder. It will recreate the conf folder and its sub-folders.

Add a user to OpenIDM:

Files to Change (Summary)

  • Files to change
    • sync.json

Configuration Steps

Just Auditing/Examining

Having a look at the conf/sync.json will show that all reactions to the different situations are set to "IGNORE".

Initial settings for situations in sync.json
        "policies" : [ {
            "situation" : "CONFIRMED",
            "action" : "IGNORE"
        }, {
            "situation" : "FOUND",
            "action" : "IGNORE"
        }, {
            "situation" : "ABSENT",
            "action" : "IGNORE"
        }, {
            "situation" : "AMBIGUOUS",
            "action" : "IGNORE"
        }, {
            "situation" : "MISSING",
            "action" : "IGNORE"
        }, {
            "situation" : "UNQUALIFIED",
            "action" : "IGNORE"
        }, {
            "situation" : "UNASSIGNED",
            "action" : "IGNORE"
        } ]

Though no user from the LDAP server will be created, OpenIDM will still create a log entry in audit/recon with one record per user in the external resource as well as in the OpenIDM repository:

Kicking off the reconciliation against the REST interface will return the reconId. Use this for the query against the repository:

Query against the Repository for the reconciliation log
select status,action,reconciling,situation from audit_recon where reconId = 'reconId'

---+---------+--------------------+--------------------+--------------------+--------------------
  #| RID     |status              |action              |reconciling         |situation
---+---------+--------------------+--------------------+--------------------+--------------------
  0|         |SUCCESS             |IGNORE              |source              |ABSENT
  1|         |SUCCESS             |IGNORE              |target              |UNQUALIFIED
---+---------+--------------------+--------------------+--------------------+--------------------

Create from LDAP

Changing situations "CONFIRMED" to "UPDATE" and "ABSENT" to "CREATE" in the mapping "systemLdapAccounts_managedUser"

Changes to the Mapping "systemLdapAccounts_managedUser" in sync.json
            ...
            "situation" : "CONFIRMED",
            "action" : "UPDATE"
            ...
            "situation" : "ABSENT",
            "action" : "CREATE"
            ...

An new reconciliation will now result to:

Result of new Reconciliation
---+---------+--------------------+--------------------+--------------------+--------------------
  #| RID     |status              |action              |reconciling         |situation
---+---------+--------------------+--------------------+--------------------+--------------------
  0|         |SUCCESS             |CREATE              |source              |ABSENT
  1|         |SUCCESS             |IGNORE              |target              |UNQUALIFIED
---+---------+--------------------+--------------------+--------------------+--------------------

The LDAP user will be created and linked in OpenIDM. The link will be created in the class link_systemLdapAccounts_managedUser where the second link class, link_managedUser_systemLdapAccounts will still be without any like. This is because the mapping "managedUser_systemLdapAccounts" is still told to ignore all situations.

Running another reconciliation will now find the results in:

Result after a new Reconciliation
---+---------+--------------------+--------------------+--------------------+--------------------
  #| RID     |status              |action              |reconciling         |situation
---+---------+--------------------+--------------------+--------------------+--------------------
  0|         |SUCCESS             |UPDATE              |source              |CONFIRMED
  1|         |SUCCESS             |IGNORE              |target              |UNQUALIFIED
---+---------+--------------------+--------------------+--------------------+--------------------

The new situation is "CONFIRMED" with the action set to "UPDATE", even if there is currently nothing to update.

Creating a Link in the Reverse Linking Class

The situation for the LDAP user in the back mapping is "FOUND" since the following rule apply: qualifies=1, link=0, target=1
Two things must be changed to create the link in the second linking class:

  • Situation "FOUND" must be answered with the action "LINK"
  • A correlationQuery is needed to find the right object in the LDAP server to which the OpenIDM user should be linked.
Changes to the situation in Mapping "managedUser_systemLdapAccounts" in sync.json
            ...
            "situation" : "FOUND",
            "action" : "LINK"
            ...

The correlationQuery is formulated in java script and configured in the property "correlationQuery":

Adding a correlationQuery to the Mapping "managedUser_systemLdapAccounts" in sync.json
        "correlationQuery" : {
            "type" : "text/javascript",
            "source" : "var myarray = [source.uid];var map = {'query' : { 'Equals': {'field' : 'uid','values' : myarray}}};map;"
        }

The next reconciliation will create the link in the back linking class, but only if there was a change to the managed user object. Therefore before running the reconciliation a change to the user on the LDAP server is needed in one of the fields which will cause an update on the target. For instance the "description" attribute would be a good candidate.

Propagate the Deletion of Objects

External Deletion triggers Repo Deletion

In the fist example here, an external deletion should trigger a deletion of the user object in the Repository, i.e. if a user account is deleted on the external LDAP resource then the user object in OpenIDM should be deleted too.

The situation which is found after a deletion in LDAP is:
qualifies=0, link=1, target=1 and called "UNQUALIFIED". Here the action will be set to "DELETE", which would also be the default action if not set in the sync.json file at all.

Set the "UNQUALIFIED" situation for the systemLdapAccounts_managedUser mapping
            "situation" : "UNQUALIFIED",
            "action" : "DELETE"

The situation which is found for the back mapping, will then be also "UNQUALIFIED" as a result of qualifies=0, link=1 where the action should be set to "UNLINK" again to remove the link from the managed user to the external resource.

External Deletion triggers Repo Deactivate

Very often it is not desirable that a delete on an external resource also triggers a delete on OpenIDM. One of the purpose of centralized identity management is auditing and then it might not be appropriate to delete the user object. Disable is often a more appropriate reaction.

In the scenario described here the user object will be deleted on LDAP, and as a reaction OpenIDM should unlink the user and set a disabled flag to true in the repository.

Again the situation which is found after the deletion in LDAP is:
qualifies=0, link=1, target=1, called "UNQUALIFIED". But now the appropriate action needs to be set to "UNLINK".

Set the "UNQUALIFIED" situation for the systemLdapAccounts_managedUser mapping
            "situation" : "UNQUALIFIED",
            "action" : "UNLINKE"

In addition some logic is needed to take care of deactivating the user in OpenIDM, i.e. set the attribute in the repository. For that kind of logic OpenIDM has the onUnlik property, similar to the onCreate property:

Logic to set a Disabled Flag on Deletion of External Accounts
        "onUnlink" : {
            "type" : "text/javascript",
            "source" : "target.disabled = 'true'"
        },

For the Back link the user object will now be in the situation:
qualifies=1, link=1, target=0 called MISSING. That needs to be handled as well with the action UNLINK.

  • No labels