Special thanks to my colleagues Anupkumar Rajan & Ravi Kiran Jayanthi for helping me get some of the basics right on the Micro Focus Access Management products.
I hope some you’d find the screen-cast useful. Enjoy!
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.
We know of it as a job usually done by the OpenAM Web/J2EE Policy Agent to enforce a Policy Decision sent by the Access Management Solution. To help you recollect, this is how it works:
– An End User tries to access a resource (say, a URL)
– The Web/J2EE Policy Agent deployed in the Container, intercepts the requests and redirects the request to Access Management Solution
– The Access Management Solution, first Authenticates the User, does a redirection to the the Resource (URL), where Agent would again receive it
– The Agent would now ask the Access Management Solution whether the Authenticated User has access to the Protected Resource (Authorization)
– Based on the policies defined in the Access Management Solution for the Protected Resource, it constructs a Decision and sends it back to the Agent
– Whatever the decision Agent receives from the Access Management (whether to ALLOW or DENY access to the Protected Resource), the Agent Enforces it!
The story in the video below is a bit different. In fact, the protagonist is different. The honours of Enforcing a Policy Decision sent by OpenAM is on ForgeRock OpenIG 4. As for the flow, it by and large remains what is mentioned above, just that the OpenIG uses its Route Configuration file to decide whether it should redirect the Client requests to OpenAM (should the SSO Cookie is absent in the request), ask OpenAM for Policy Decisions on Protected URLs by Authenticated Users and finally to enforce a Decision that is sent by OpenAM (whether to ALLOW or DENY access to Protected URLs).
Very roughly, here’s an illustration of the flow:
To see it in action, watch the screen-cast below. Enjoy!
If it perplexes you the difference between an Identity Repository and an Authentication Repository (a.k.a Credential Repository) in ForgeRock OpenAM, maybe the video tutorial on this post can render some hint. It’s basic, so shouldn’t be difficult to understand, if you don’t know it already. Before getting to the video, let me mention here a couple of points:
OpenAM has the following repositories:
– Configuration Repository where the OpenAM Configuration Data is stored
– Identity Repository where the User Profiles are stored
– Authentication Repository or Credential Repository used by the ForgeRock to validate a User Credential
In the demonstration that follows, OpenAM connects to a MySQL Database for authenticating a User (Credential/Authentication Repository) and pulls up the User’s profile from an embedded OpenDJ instance (Identity Repository). If the User’s profile does not exist in the Identity Repository, OpenAM dynamically creates it.
Interested to see how ForgeRock Identity Gateway orchestrates with the ForgeRock Access Management solution to replay a User Credential on to a Legacy Application giving him/her access to it? There’s a screen-cast right below this write up. I had already posted a couple of entries on this space, demonstrating how OpenIG fetches User Credentials from different Datastores like a CSV file and a JDBC Database. While it’s not a prerequisite to know it before viewing the Video below, it might help get a good grip on the steps performed. So if you haven’t come across those blog entries yet, here it is:
– A user tries to access ‘http://openig.mydomain.com:8080/replay’ url
– A Java EE OpenAM Policy Agent sitting in front of the ‘http://openig.mydomain.com:8080′ url intercepts the request from the client (user’s browser) and redirects the request to ForgeRock OpenAM (http://openam.mydomain.com:8080/openam)
– ForgeRock OpenAM will send the OpenAM Login Page back to the user
– The user supplies the credential, which the OpenAM verifies. If authentication is successful,OpenAM adds the username of the user and his/her encrypted password to the session and sends it to Java EE Policy Agent
– Java EE Policy agent validates the user’s session, gives control to OpenIG.
– Because the URL that the client requested for (http://openig.mydomain.com:8080/replay), matches a specific route (say 04-route.json) configured in OpenIG, it applies the filters in the route configuration file. The first filter will use a shared key (also known to the OpenAM) to decrypt the encrypted password sent by OpenAM. The second filter will retrieve the username and password from the exchange and replaces your browser’s original HTTP GET request with an HTTP POST login request that contains the credentials to authenticate and the third filter will remove the username and password headers before continuing to process the exchange.
– The HTTP server validates the credentials and respond back to OpenIG with user’s profile page
– OpenIG sends that response to the End user
Note: OpenAM in our setup is configured to process a ‘Password Replay’ Java Class on successful authentication. The Java EE agent in OpenAM is configured only for Single Sign On (SSO) and is configured to add the UserToken (username) and sunIdentityUserPassword (password) as session attributes in HTTP header. And the FQHN of OpenAM deployment in the Video demonstration is ‘idp.mydomain.com’ and not ‘openam.mydomain.com’
To satisfy your Visual Cortex, here’s an illustration of the steps above:
If we’ve just moved ahead of ‘Getting Started with OpenIG 4‘, the following screen-cast might of some interest. In fact, this is a remake of a video that’s posted here, which was based on now older version of ForgeRock OpenIG.
So what’s in the video here? We’ve a CSV file with some User details. A user tries to access a URI, which hits OpenIG, who by using some Route Configuration files, looks up User Credentials from the CSV file and posts it to the HTTP Server, to get a User Profile Page (Post Authentication Landing Page) in return. So the Client, without having to go through the inconvenience of supplying his/her User Credentials, gets the Post Authentication Landing Page from the HTTP Server. See, if my attempt to capture the flow below makes sense.
If that didn’t make your life easy, hopefully the demonstration in the video will. Enjoy!
I had left a task unfinished yesterday. When I published my previous post on to my little space in the blogosphere, I kept aside a crucial piece of information. If you haven’t read/viewed my earlier blog on ForgeRock OpenAM Social Authentication (Facebook) Using OAuth2 and don’t know how to configure OAuth2 Authentication Module in ForgeRock OpenAM, I’d request you to first take a look at it.
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).
Enjoy!
There is a very useful article around this right here.
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.
In this episode, you’ll see how ForgeRock OpenIG picks up user credentials from ForgeRock OpenAM, and gives the user access to an application. Now that’s quite a bit of information in a single line. So let’s break it down into pieces:
– A user tries to access ‘http://openig.mydomain.com:8080/replay’ url
– A Java EE OpenAM Policy Agent sitting in front of the ‘http://openig.mydomain.com:8080’ url intercepts the request from the client (user’s browser) and redirects the request to ForgeRock OpenAM (http://openam.mydomain.com:8080/openam)
– ForgeRock OpenAM will send the OpenAM Login Page back to the user
– The user supplies the credential, which the OpenAM verifies. If authentication is successful,OpenAM adds the username of the user and his/her encrypted password to the session and sends it to Java EE Policy Agent
– Java EE Policy agent validates the user’s session, gives control to OpenIG.
– Because the URL that the client requested for (http://openig.mydomain.com:8080/replay), matches a specific route (say 04-route.json) configured in OpenIG, it applies the filters in the route configuration file. The first filter will use a shared key (also known to the OpenAM) to decrypt the encrypted password sent by OpenAM. The second filter will retrieve the username and password from the exchange and replaces your browser’s original HTTP GET request with an HTTP POST login request that contains the credentials to authenticate and the third filter will remove the username and password headers before continuing to process the exchange.
– The HTTP server validates the credentials and respond back to OpenIG with user’s profile page
– OpenIG sends that response to the end user
A couple of things though: OpenAM in our setup is configured to process a ‘Password Replay’ Java Class on successful authentication. The Java EE agent in OpenAM is configured only for Single Sign On (SSO) and is configured to add the UserToken (username) and sunIdentityUserPassword (password) as session attributes in HTTP header.
The picture below may not speak thousand words, but it does speak all the words I uttered above:
This update could be considered a variant of an earlier post around ForgeRock OpenIG. And it’s highly recommended you watch my screen-cast on ‘OpenIG Authentication From File DataStore’ (or the blog update mentioned above) before viewing the video embedded below. As always, for making the video demonstrations that you see below, I just followed the neat instruction from the ForgeRock documentation.
An illustration below for giving you an idea of what’s in store in my 8 minute video:
And here’s quick explanation on what’s happening: step (1) OpenIG intercepts your browser’s HTTP GET request. The request matches the new route configuration (“/sql”) Step (2) The OpenIG ‘SQLAttributesFilter’ looksup credentials for ‘sholmes@example.com’ in the H2 database step (3) The ‘SQLAttributesFilter’ stores the credentials fetched in step 2 in Exchange step (4) The ‘StaticRequestFilter’ retrieves the credentials from Exchange, replaces the original HTTP GET request with HTTP POST login that contains the credentials to authenticate step (5) OpenIG now sends HTTP POST to the Application (listening on port 8081) Step (6) The application (on port 8081) validates the authentication credentials and sends the response to OpenIG step (7) The OpenIG now sends the response to the client (which happens to be user profile)
