In a couple of blog posts published in the recent past, One on ForgeRock OpenAM and another on ForgeRock OpenIDM, we had a look at configuring E-mail Services in the aforesaid Products. And it’ll be grossly unfair, if we don’t touch upon the same topic in ForgeRock’s Directory Services solution: OpenDJ
No one wants to stay logged in on to the User Interface of a Provisioning Tool, waiting for the approval requests to flood into their queue in order to take an appropriate action. We have other things to do in life and for matters that require our attention we all expect notifications, don’t we? Without doubt, one very common and an easy channel for notification is Email, which some consider to be the first and the last killer app of the Internet. Just like many other configurations, setting up Outbound Email in ForgeRock OpenIDM is a walk in the park. If you have just over 5 minutes to spare, watch how it’s done in the video below:
This post is based on the ForgeRock Documentation on configuring OpenIG as SAML 2.0 Service Provider. The video logs embedded just below this write up is a visual representation of what is already there in the document that I mentioned above. For a detailed study, please read through the documentation and then sit back, relax and watch the demonstration in the screen-cast below
SAML 2.0 as you probably know is a standard to exchange information between a SAML authority (a Identity Provider a.k.a IDP) and a SAML Consumer (a Service Provider a.k.a SP). In the demonstration that follows ForgeRock OpenAM acts as an Identity Provider and ForgeRock OpenIG acts as a Service Provider. So the authentication of a user is done by the IDP, who will then send a piece of information (Assertion) to the SP that could contain the attributes of user from the user’s profile in the IDP DataStore. SP will then use the information thus obtained (Assertion) to take further action (like giving access to the user etc.)
There are two ways of getting this done:
(i) SP initiated SSO
(ii) IDP initiated SSO
In simple words, in a SP initiated SSO, the user contacts the Service Provider, who in turns gets in touch with the Identity Provider, who would validate the user credentials and then exchange a piece of information (Assertion) that could contain the user attributes to the Service Provider. Whereas a IDP initiated SSO, the IDP will authenticate the user, and would then send an unsolicited message (Assertion) to the SP, who would then take further action (like giving access to the user etc.)
The following two illustrations might give a rough idea:
In our story (above in the illustration and below in the video), a user authenticates against ForgeRock OpenAM (IDP), who will send then an assertion (containing user’s mail and employeenumber attribute) to ForgeRock OpenIG (Service Provider), who will apply filters (like extracting the attributes from assertion and posting it as username and password) to post the user’s credentials to a protected application (Minimal HTTP Server)
If you’ve got a vague picture on what’s discussed above, I’d believe it’ll be clearer after watching the video below:
In an earlier post, we saw User Self Registration in ForgeRock OpenAM using XUI. It’s likely that you may not want to use the UI that comes with OpenAM, but may have reasons to build your own UI/Application on the REST API to operate on ForgeRock’s Access Management Solution. Keeping that in mind, a discussion on User Self Registration in OpenAM is incomplete without showing you how it is done using REST. Like many other examples you may already be familiar with around REST calls to ForgeRock products, you’ll see the usage of simple, yet powerful ‘curl’ to invoke REST calls to OpenAM for Self Registering a User. Here’s a list of related video blogs that you may want to watch before watching the one that’s embedded below.
ForgeRock OpenAM is not meant for User Provisioning. Consider, ForgeRock OpenIDM for the same. Still, OpenAM does offer a facility for User Self Registration. In this segment, let’s have a look at how it’s done using the User Interface of OpenAM (XUI). As you can guess, it’s not a difficult task at all. Have a look.
Before I forget, the E-mail Service needs to be configured in OpenAM for the User Self Registration to work, so if you don’t know how that’s done, we have another video here.
In a less than 2 minute video that follows, you’ll see me setting up E-mail service in ForgeRock OpenAM, a facility that is used by OpenAM features such User Self Registration. Because I know for certain I’ll have to refer to this video on a number of occasions in future while demonstrating other capabilities of OpenAM, I’ve decided to keep this video tutorial separate and independent. It’s tiny, of course:
This post picks up from where we left last time and takes the next step to demonstrate Subentry Based Password Policy in ForgeRock OpenDJ. I owe a great detail of gratitude to the ForgeRock documentation team for this neat write up on OpenDJ Password Policy as well to Ludovic Poitou for his blog post. So in under 5 minutes time, we take our discussion on OpenDJ Password Policy to conclusion.
Someone asked me if I could do a video on ForgeRock OpenDJ Password Policy. Though it took me a while to get over my laziness to do one, finally I’ve the first of two part video that demonstrates the Password Policy in OpenDJ. In the first part that’s embedded below, we get to know about the System based Password Policy in OpenDJ and how to make changes to it. OpenDJ installation is covered very quickly, so if you aren’t too comfortable with the OpenDJ installation or the basic LDAP commands for that matter, I humbly suggest you take a quick look here first.