If you’re in a hurry to know what each of the ForgeRock Identity Platform Components is meant to do, try the Full Stack Configuration. In just over fifteen minutes, you’ll see:
– Installation of ForgeRock OpenDJ
– Deployment of ForgeRock OpenAM
– Configuration of OpenDJ as an Identity Repository in ForgeRock OpenAM
– Installation of ForgeRock OpenIDM
– Configuring OpenDJ as External Resource in OpenIDM
– Running a reconciliation in OpenIDM from OpenDJ
– Provisioning a User from OpenIDM to OpenDJ
– Using OpenAM as the Authentication Module for OpenIDM
With a much awaited weekend around the corner, I couldn’t really get over the laziness to create a better illustration than the one below to help visualize what’s mentioned above.
ForgeRock OpenIDM, the Identity Management solution from ForgeRock offers nice and easy way to perform most of the common scenarios one can think of in the Identity Management domain. Once such commonly occurring situations is to link an account of a User in IDM with his/her Multiple accounts in a resource such as LDAP Server like ForgeRock OpenDJ. Let’s try to understand how that’s achieved in OpenIDM using the illustration below:
As you can make out, OpenIDM is connected to an OpenDJ instance. You could also see two OpenIDM Roles defined namely ‘Agent’ and ‘Insurer’. Each of the Role is attached to a Managed Assignment. And the Managed Assignment in turn has Attributes and Link Qualifiers. The Attribute refers to a User Attribute in OpenDJ with a corresponding value (say cn=Chat Users, ou=Groups,dc=example,dc=com) and Link Qualifier is used to construct a DN (say uid=bjensen,ou=Customers,dc=example,dc=com).
So a Role that has the Managed Assignments with the said Attributes and Link Qualifier would (i) be a member of ‘cn=Chat Users, ou=Groups,dc=example,dc=com‘ and will belong to a branch that’s determined by the DN uid=bjensen,ou=Customers,dc=example,dc=com. Clearly, multiple OpenIDM Role assignments to a single OpenIDM User will link that User’s account with multiple DNs in the OpenDJ instance. Please note that the LDAP group is omitted from the illustration above for brevity. The following equation might give us a rough translation of the above statements:
OpenIDM User (bjensen) <---- OpenIDM Role (Insurer) <---- Managed Assignment (cn=Chat Users,ou=Groups,dc=example,dc=com Attribute && dn: uid=?,ou=Customers,dc=example,dc=comLink Qualifier) ===> bjensen user in the ou=Customers branch of OpenDJ instance DIT (uid=bjensen, ou=Customers,dc=example,dc=com) and the user’s subscription to a LDAP Group cn=Chat Users, ou=Groups,dc=example,dc=com)
Not clear? Have a screen-cast for you. Please take a look and see if it gives you a clearer picture.
This post in inspired by Ludovic Poitou’s reply to a thread in the ForgeRock OpenDJ Forum around DSEE to ForgeRock OpenDJ migration. Consider this to be just a hint, and not an answer. In a video log that’s embedded just below this write up, you’ll see some clues on a couple of different methods that you could consider to move away from a product that’s now in sustaining stage to ForgeRock’s Directory Services Solution. I don’t need to mention here how important a task it is to carefully draft a plan for migration from one product to another, and I’m sure you’ll not take this video log as the only reference while doing so.
So if you’ve half an hour to spare, you’ll see in the video: Act 1:
– A ‘Flash Back’ on DSEE installation and configuration
– Exporting the data from the DSEE instance
– Installation & Configuration of ForgeRock OpenDJ
– Importing the DSEE instance backup to ForgeRock OpenDJ Act 2:
– Installation of ForgeRock OpenIDM
– Configuration of External LDAP Server (DSEE instance) as a Managed Resource in ForgeRock OpenIDM (using samples)
– Configuration of OpenDJ instance as a Managed Resource in ForgeRock OpenIDM (using the UI)
– Reconciliation between the DSEE instance (source) and OpenDJ instance (target)