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:
– Setting up SSL in MySQL database
– Configuring OpenIDM to use SSLto the MySQL database (its internal repository)
Like several other videos that I’ve already published on this blog space around ForgeRock products, this one also makes use of Ubuntu 14.10 host 0S. A Linux Container running Ubuntu 14.04.2 LTS is where we’ve our ForgeRock OpenIDM and MySQL database running. The illustration below might help you get a quick picture about the infrastructure used for the screen-cast:
This post is a demo version of the ForgeRock Documentation on Setting Up OpenAM with HTTPS on Tomcat. I had earlier published a screen-cast on the ForgeRock OpenAM deployment and Configuration on a Apache Tomcat Container running in a LXC. If you haven’t watched it yet, and would like to have a look at it, it’s right here. Below you’ll find the steps that I run in my Ubuntu Linux Container to secure our OpenAM deployment:
– Create a Certificate & store it in keystore in a Linux Container
– Modify the Tomcat Server Configuration file (server.xml) to enable SSL (on port 8443)
– Deploy ForgeRock OpenAM
– Access OpenAM from the host OS and complete the configuration
If it’s hard for your visualize how the infrastructure looks like, here’s an illustration to make life easy.
This is a sequel to my earlier blog update on ForgeRock OpenDJ Replication and is largely inspired by a question raised in the ForgeRock Community Website. So if you are not very familiar with the steps involved in configuring OpenDJ Replication, I suggest you read/watch it before watching the embedded video below:
One-liner about the infrastructure used: two Linux Containers, each running an instance of ForgeRock OpenDJ is already replicating the OpenDJ data, but the replication traffic is not secure. In the video demonstration that follows, we’ll tighten the security a bit by encrypting the replication traffic as well as monitor the same using wireshark running on the host OS. Well, the diagram below indicates the end state of our screen-cast: