Well, you’ve possibly heard about the release of newer version of the ForgeRock Identity Platform with several enhanced capabilities. If not, you can read about it all here. One of the new features in the Access Management component of ForgeRock Identity Platform is SAML2 Authentication Module. What that offers is, after configuring Federation, we could supply all the required details like the IDP entity, the binding method etc. in an Authentication Module instance of the ForgeRock Access Management solution and use it just like any other Authentication Module (LDAP, Database, HOTP etc.). Let’s see how that’s done in a video demonstration that follows this write up. And, by the way, if you’d like to get a quick idea what’s new in the newer version of ForgeRock Access Management solution, read the release notes here.
We’ve already discussed OpenAM Federation on this space before. Here’s list of links from the past:
While the following video walks through the OpenAM Federation Configuration from the scratch, if you feel there are details missing in it, please feel free to have a look at the web logs mentioned above. The main focus of the screen-cast below is only to see how SAML2 is used as an Authentication Module instance in the version 13 of ForgeRock OpenAM.
The following illustration might give a quick idea on what’s demonstrated in the video embedded below this post.
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.