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!
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.
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.
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
Having a look at the conf/sync.json will show that all reactions to the different situations are set to "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:
Create from LDAP
Changing situations "CONFIRMED" to "UPDATE" and "ABSENT" to "CREATE" in the mapping "systemLdapAccounts_managedUser"
An new reconciliation will now result to:
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:
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.
The correlationQuery is formulated in java script and configured in the property "correlationQuery":
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.
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".
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:
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.