Just yesterday, I concluded a five day ForgeRock University training program on ForgeRock OpenAM at Bangalore. I wish to express my sincere gratitude to each one in the picture below for showing up for a ForgeRock University course on our Access Management solution and wish them success in their ForgeRock Projects.
To know what we discussed during the training or to subscribe for one such program, all details are here.
If you aren’t looking for a detailed program on our Products as the one you find in the link above, we do offer half a day free (as in beer) overview session on both ForgeRock OpenAM and ForgeRock OpenIDM, the details of which are below (keep checking the links below for the next occurrence):
And now here’s the missing thread: in the last video, we authenticated the OpenAM users against their Facebook Account, but then they had their profile available in the OpenAM Identity Repository as well, which only meant that on Successful Authentication with Facebook, if the users did not have their profile in OpenAM, they were not let in. We take a different stand this time around allowing in even those users without an OpenAM profile, by having OpenAM provision their accounts in its Identity Repository using the attributes returned by Facebook on successful authentication.
The video demonstration embedded below this write-up is dangerously similar to the video here , published more than three months ago. I’ve had challenges making this one though, which is when my colleagues Jon Knight and Albert Ayoub stepped forward to lend a helping hand. So if you ready, let’s see how ForgeRock OpenAM lets a user authenticate against his/her Facebook account to gain access to OpenAM (read applications protected by OpenAM).
There is a very useful article around this right here.
If you experience Deja Vu by looking at the illustration just below, chances are that you’ve hit my blogs before, in particular on this entry, where we looked at ForgeRock OpenAM as an Identity Provider and ForgeRock OpenIG as a Service Provider.
A friend asked me if I could demonstrate a very simple configuration of Federation using two ForgeRock OpenAM instances, one acting as an Identity Provider (a.k.a IDP) and another one taking up the role of a Service Provider (a.k.a SP). It wasn’t difficult to do one, so here we have it embedded towards the end of this post.
So what do we have here:
– A Circle of Trust which has two OpenAM instances, one of which acting as an Identity Provider and another one as Service Provider
– User always authenticates against the Identity Provider
– The authentication process is intiated either by the IDP (known as IDP initiated SSO) or by the SP (SP initiated SSO)
– Once the user is authenticated successfully, IDP sends across a piece of security information to the SP (known as assertion) that could contain user attributes
– SP then gives the user access to protected resources
In the demonstration that follows, because ‘Auto Federation’ is not enabled, during the first login the user will be prompted for credentials both by the IDP and the SP. Once the account linking is done, it’s only the IDP who would challenge the user.
If the illustration and the briefing above hasn’t given you the complete picture, the video below might give a better one.