ForgeRock OpenIDM, very simply put, manages the identity, not necessarily of users all the time. In a short video demonstration that follows, I’ve taken efforts to show you a very simple user provisioning workflow in OpenIDM. When an employee in an organization initiates an onboard contract, the workflow is launched and the request reaches a manager, who then pickups the request and approves (or reject) it. Consequently, the new user’s identity is provisioned on a resource.
What’s in the video is a simple exercise and I strongly encourage anyone interested in ForgeRock’s Identity Management solution to try it and see. Well, if you say you aren’t familiar with the OpenIDM installation, that isn’t difficult either, you can watch it here.
In my earlier blog post titled Extending the ForgeRock OpenDJ Schema there was an embedded screen-cast that demonstrated how a new attribute could be added to the user profile in OpenDJ. We take one step further in this section to modify at Service in ForgeRock OpenAM to display that attribute in OpenAM Console. So if you’ve watched or if you know how to extend the OpenDJ schema to add a new user attribute, the following video log will tell you what you need to do on OpenAM to display it in the console.
I had made a promise in my earlier post. This one is intended to fulfill it. One of the common requirements of any Directory Services solution is to extend the attributes that it supports. In the following video log that has a running time of just over a dozen minutes, you’ll see how to add a new attribute to the OpenDJ instance.
You will find an entry on my blogs that talked about the installation of Linux Container and further demonstrated ForgeRock OpenDJ installation and configuration in it. In the last several days, though I posted some contents on OpenDJ, I never introduced my kind readers to the Administration GUI that the OpenDJ product comes with. That was mainly because I was struggling to get the GUI from a Linux Container. This morning I was determined more than ever before to get over this roadblock, and, boy, did manage to figure out, perhaps, one among the many ways of doing it. In the following screen-cast, you’ll see me installing VNC Server on my Linux Container (Ubuntu 14.04.2 LTS) that has OpenDJ in it and then use a VNC client from the Host OS (Ubuntu 14.10) to access the OpenDJ Control Panel, a very convenient tool to browse the OpenDJ Directory data. Very soon, you’ll see me using OpenDJ control panel for a serious reason. Thank you for your patience.
It’s a weekend, so I don’t seem to have the mental bandwidth for a heavy duty demonstration on ForgeRock products. I’ve a very short video log that has a running time of just over a minute and half to show you how, if required, you can switch from ForgeRock OpenAM 12 XUI (default interface) to OpenAM Legacy UI.
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:
– 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:
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 ‘firstname.lastname@example.org’ 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)
The following video log is a very light one, partly because I haven’t done a video on REST interface around OpenIDM, but have done similiar ones for both OpenDJ and OpenAM, and partly because I’m feeling too sleepy to do a screen-cast on tougher topics. Talking of REST, in case if you haven’t seen my earlier reference to a neat and curt introduction to ForgeRock Common REST API, read it here.
Again, for those who are not familiar with REST calls to OpenIDM, the embedded video below might just give an idea of how to create a user and fetch a user profile in OpenIDM using REST.
That the ForgeRock OpenAM audit logs are extremely important is an understatement. By default, OpenAM uses flat files as log output format, but there does exist an option to configure OpenAM to generate audit logs onto a database. And when a friend today raised a question around it, I thought I should make a screen-cast on it, which is what you would find embedded below.
A bit about the system used for the screen-cast. I’m running two Linux Containers (Ubuntu 14.04.2 LTS), one of which has OpenAM installed & configured and the other container running an instance of MySQL database. Rest of the story should be straightforward in the video.
A video demonstration on ForgeRock OpenAM deployment as a standalone instance in a Tomcat Server was posted earlier on my blog. For a production ready environment, it is important to have multiple instances of OpenAM running in a site. In the video that’s embedded below, you’ll get to see:
– An existing deployment of ForgeRock OpenAM in a Linux Container
– Installation & Configuration of a new instance of ForgeRock OpenAM in a separate Linux Container joining an existing OpenAM deployment
– Configuration of a OpenAM site that includes two OpenAM instances as mentioned above
– Installation and Configuration of HA Proxy in a separate Linux Container
– Demonstration of load balancing by HA Proxy to the back end OpenAM Servers
A great deal of information required for doing a demonstration on OpenAM HA environment and in turn the rules to be used by the HA Proxy was picked up from Mark Craig’s blog.
The illustration below might give an idea on the infrastructure used in the video demonstration. There are three Linux Containers in a Ubuntu 14.10 host, one of which has the first instance of OpenAM, the second one has another instance of OpenAM and the third one running HA Proxy to load balance the requests to two instances of OpenAM. The client requests go to the Linux Container running HA Proxy, from where the HA Proxy redirects the requests to either one of the OpenAM instances running in two different Linux Containers.
If you’ve got some some bit of idea looking at the illustration above, I can assure you, it’ll be clearer watching the demonstration below. A word of caution though: the infrastructure used here is only for demonstration purpose, for a very serious highly available environment, you may have to consider other virtualization technologies.
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:
On this site, I’ve written another couple of posts around ForgeRock OpenIDM. If you’re not familiar with OpenIDM, I’d recommend reading/watching those (mentioned below), before viewing the video log embedded at the end of this post.
Video logs on the links above are quite detailed, but if you’ve not much time to spare to watch all of it, not to worry, the installation of OpenIDM and configuration of MySQL as its internal repository is quickly covered in the following screen-cast as well.
The below illustration might give you a rough idea about the infrastructure that I used to perform the demonstration on OpenIDM Cluster Configuration. I’ve a Host Operating System of Ubuntu 14.10 in which there are many Linux Containers. Two of LXCs named ‘my-openidm’ & ‘my-openidm2’ are used to install two separate instances of ForgeRock OpenIDM (say ‘node1’ & ‘node2’). A directory named ‘/software’ on the Host OS that has all required binaries is shared as ‘/source’ inside the Linux Containers. For brevity, I’ve included only the relevant LXCs in the illustration as follows:
Please use the embedded video for a quick reference. For a detailed study on how the OpenIDM works in a cluster, please refer to the ForgeRock documentation.
In an earlier blog update we saw how we could interact with ForgeRock OpenAM using REST. In this episode, we’ll look at the RESTful Operations on ForgeRock’s Directory Services solution OpenDJ. If you’re like me, you would have probably used commands like ‘ldapsearch’, ‘ldapmodify’ to operate on the Directory Server data, but may not have tried alternate ways of interacting with the product. In the screen-cast below, let’s explore how REST calls can be made instead of LDAP on to an OpenDJ instance to perform some of basic Directory Services operation. For a detailed study on the topic, I’d always recommend ForgeRock documentation on the topic.
ForgeRock OpenAM supports a number of Authentication Modules that can be used to verify the identity of a user attempting to login to the applications protected by OpenAM. One of the biggest strengths of OpenAM is the flexibility that it gives to plug in a Custom Authentication Module in the event the Out of The Box modules do not meet the requirements. Some details around the same can be found here.
In the following video that has a running time of approximately nine minutes, you’ll see an OpenAM instance being configured to contact Google for identifying a user by using OAuth2. Google’s literature about their support for OAuth2 is here in case if you are interested to read.
In an earlier post we saw how to create a new realm in ForgeRock OpenAM. But for that we used the Browser User Interface of OpenAM. Well it’s likely that the ForgeRock customers might not be interested in ForgeRock’s implementation of User Interface, but would like to have their own custom way of interacting with the product. For this very purpose, all components of ForgeRock Identity Platform offers easy-to-use RESTful Web API. A neat introduction about it is here. For a detailed look on the RESTful Web Services, I’d recommend ForgeRock documentation.
So in the following screen-cast, we’ll see how we can use a popular command line tool to make REST calls to the OpenAM first for performing authenticaiton and then for creating a realm.