– 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
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!
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!
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.
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:
First things first, screen-cast that follows this write up is based on the ForgeRock documentation on OpenIG that’s found here. Secondly, if you aren’t familiar with ForgeRock OpenIG or ForgeRock OpenAM, I’d recommend you to do some reading on the products from the official ForgeRock documentation or watch the following screen-casts on it to become familiarized with it:
Cut to present, we have OpenIG acting as a resource server. So in the video log, you’ll see the curl command being used to contact OpenAM to get an Access Token, use the same command to contact OpenIG with the Access Token, which is when OpenIG (acting as a resource server), will contact OpenAM (acting as an authorization server) for validating the token. Once validated, OpenIG will apply additional filters to post the credentials to a HTTP Server and get the user profile in response to it. A one-liner definition for the mouthful of jargon I used above can be found here. The illustration below might make the long story said above slightly shorter.
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)
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
