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)
If this was a book, what we have here is a prologue. Just as you don’t expect the prologue to throw a full story at you, so does this web log unveil absolutely no details around Certification in ForgeRock OpenIDM. What it does though is to setup a ‘plot’ for a possible video demonstration on Certification facility in ForgeRock’s Identity Management Solution. And that’s coming soon…
So in the video log, that’s actually a visual representation of the brilliant ForgeRock Documentation on OpenIDM, you’ll see:
– Installation of ForgeRock OpenDJ
– Configuration of OpenDJ as an external resource managed by OpenIDM (using sample files)
– Performing the initial reconciliation using REST to load users from OpenDJ to OpenIDM
Soon we’ll put all those users in action for Certification in OpenIDM. For now, just as you’d skim through the prologue of a book, take a quick look at the ~5 minute video
I’m a big fan of Brendan Gregg. The DTrace Book that he co-authored with Jim Mauro stands one of the best I’ve read in Computer Science. While I continue to take my baby steps in DTrace, I thought I’d share with you my video log on attempting to explore ForgeRock OpenDJ using the pid provider in DTrace. Brendan Gregg has published a number of blogs around the pid provider, all of which is accessible from his consolidated blog entry here. OTN has very generously published one chapter from the DTrace Book that talks of using DTrace on Applications, in which the pid provider and its use is detailed.
This one is rather uncomplicated. ForgeRock OpenIDM does provisioning well, be it to a Directory Server, a Database or even to several other external resources. The following video log demonstrates exactly that. You’ll see:
– Super quick installation of ForgeRock OpenIDM
– Installation of PostgreSQL database, creation of user with super user role in PostgreSQL, creation of a database and finally creation of a table
– Configure the OpenIDM Database connector to connect to the PostgreSQL database table created in the above mentioned step
– And finally see how the users from OpenIDM are provisioned on to the PostgreSQL database table
It’s all very simple and easy to understand. So enjoy!
In this episode, you’ll see ForgeRock OpenAM’s two factor authentication feature employing it’s Adaptive Risk Authentication Module instance and HOTP module instance
So in the video demonstration that follows this post, you’ll see a user attempting to login against an Authentication Chain (say ‘MyAuthChain’) which has three module instances namely (i) Data Store, (ii) Adaptive Risk and (iii) HOTP. If the user is able to supply the right credentials against the Data Store, he or she is allowed in without any further challenge. On the other hand, if the the attempt to authenticate against the first Module instance (Data Store) fails, then the user is prompted for additional credentials like One Time Password.
The following illustration might give a rough idea on the what’s discussed above and the video that follows might make it pretty clear.
First things first, screen-cast that follows this write up is based on the ForgeRock documentation on OpenIG that’s found here. Secondly, if you aren’t familiar with ForgeRock OpenIG or ForgeRock OpenAM, I’d recommend you to do some reading on the products from the official ForgeRock documentation or watch the following screen-casts on it to become familiarized with it:
Cut to present, we have OpenIG acting as a resource server. So in the video log, you’ll see the curl command being used to contact OpenAM to get an Access Token, use the same command to contact OpenIG with the Access Token, which is when OpenIG (acting as a resource server), will contact OpenAM (acting as an authorization server) for validating the token. Once validated, OpenIG will apply additional filters to post the credentials to a HTTP Server and get the user profile in response to it. A one-liner definition for the mouthful of jargon I used above can be found here. The illustration below might make the long story said above slightly shorter.