– All urls that hit OpenIG, containing a string ‘openam’ getting redirected to OpenAM URL
– All urls that hit OpenIG, that does not contain the string ‘openam’ getting redirected to:
OpenAM for Authentication if there is no valid User session and then on to OpenIDM UI
2. OpenIDM UI if there is a valid User sessionOpenIDM UI
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:
To know how ForgeRock OpenIG 4 is configured to fetch User Credentials from a Database for User Authentication (a process transparent to the User), the following Video log might help. I had posted a similar video on this space earlier, but that then the User Credentials were fetched from a Flat File (CSV). The flow isn’t quite different from that, just that a Filter used by ForgeRock OpenIG in this case is different and that we should configure the OpenIG to connect to the DB.
In the video, we’ll:
– Install the H2 Database. Create ‘Users’ table and load User data in it
– Configure OpenIG (deployed in Jetty) to connect to the Database
– Prepare OpenIG Route Configuration file to fetch User Credentials (based on a Email address) and post the data to HTTP Server, who responds with the User profile page
For those whose right side of the brain is more prominent, here’s the visual representation of what is mentioned above:
For those who don’t want to think too much looking at the illustration below, but would like to sit back, relax and enjoy watching a show, here’s the video. Enjoy!
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!
If you haven’t gotten started with the newer version of ForgeRock OpenIG, the following Video might be of some help. I’ve done this before, but using now an older version of the Product. So if you are familiar with that, then this gives you an assurance that everything continues to work as before, and that there is more to it (that’s a story for another day though). So if you haven’t gotten your hands dirty with ForgeRock’s Identity Gateway solution, I invite you to have a look at it, and everything that you may need to get started with it, you will find it in the video below.
Very quickly, let me tell what’s done in the Screen-cast:
– Install Jetty
– Deploy ForgeRock OpenIG in Jetty
– Install Minimal HTTP Server
– Configure ForgeRock OpenIG to post user Credentials to the HTTP Server to return a User Profile Page (so the authentication process is transparent to the user.
Please note that the practice of hard-coding the User Credential is something that you’ll probably never see in a real world scenario, but of course the intent here is only to get a rough idea of what the OpenIG can do. The illustration below might give you a decent idea on the flow:
The video, I’m confident, will make it more clear.Enjoy!
This update is based on the official ForgeRock documentation section here. The intent is only to give a demonstration of what is already written in there.
The screen-cast embedded at the end of this post, demonstrates how ForgeRock OpenIG intercepts a HTTP GET request from a client, process the request based on filter, handlers & conditions defined in its configuration files, redirect the HTTP GET request either as it is, or replacing it with other HTTP methods like POST to a HTTP server and then redirect the response that HTTP Server gives back to the client who originally invoked the request. Now, that was probably one of the lengthiest sentences, you would ever encounter. They say, picture speak a thousand words, so I’ll have you look at the following illustration, which by and large, summarizes a mouthful of words that I mentioned above:
You’re not supposed to understand the whole story by looking at the illustration above. For you to go get a clear picture of what I’m trying to convey, I’ve the following video log:
ForgeRock has four main products: OpenDJ, OpenAM, OpenIDM and OpenIG. A few days back I embarked on a journey to publish posts on my blog that demonstrated basic functionality of each of the aforesaid products. This post, it’s safe to say, might be the one leading to the chequered flag. So here’s the story so far:
and now to the last one in the series that demonstrates the functionality of OpenIG (Identity Gateway) at a very basic level of course. And as with the last blog entries, I present to you the video logs of OpenIG installation and configuration. The demonstration in the video is based on ForgeRock OpenIG Quick Start documentation.
What you get to see in the video log is:
– Creation of a new Linux Container ‘my-openig’
– Installation of Jetty
– Deployment of OpenIG in Jetty
– Installation of minimal http server
– Configuring the OpenIG to redirect requests to the minimal http server
