This is the third episode from a four part video made on using SAML v2 Assertion attributes in an application protected by ForgeRock OpenAM. In the interest of continuity and also to get the context accurately, it may make sense to read/view the blog posts in the following order:
The diagram is a slightly modified version of the one that you would have seen in my earlier blog entry. It has one additional user in the Identity Provider (which of course seems like a world famous detective and that’s no coincidence), but no corresponding entry in the Service Provider. In the Identity Federation Configuration earlier, we saw how a user with an id ‘demo’ in the Identity Provider linked her account with her id in the Service Provider. But there can be situations, when we may want to use Federation with identities only at the IDP, still gaining access to the applications protected by the SP. That’s where Transient Federation comes into play. It maps the identities from IDP to an anonymous user in the SP (many to one mapping).
This is first of four blog entries that aims at demonstrating how to use SAML Assertion Attributes in an Application protected by ForgeRock OpenAM. For the convenience of viewing, a thirty five odd minutes screen-cast has been split into four sections, the first of which is embedded on this blog post. While each entry talks of an independent facility in ForgeRock OpenAM, it makes sense to read/view them in the following order:
As you can possibly make out from the illustration above, there are three Linux Containers being used in our demonstration, two of which runs an OpenAM instance each. A third Linux Container is used for installing a J2EE Application. The illustration captures the end state of this segment, where a J2EE Application is protected by an OpenAM J2EE Agent, making sure all client requests to it are intercepted by the Agent and redirected to the OpenAM for Authentication/Authorization.
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.
– 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:
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.
I’ve already posted an entry on ForgeRock OpenDJ Installation in a Linux Container. If interested, you can read/watch it here. If you are already familiar with OpenDJ installation as a stand alone Directory Server instance and would like to know the very simple steps involved in setting up data replication, the following video log might be useful for you. The screen-cast below uses two OpenDJ instances running on two different Linux Containers to set up data replication. A great deal of information required for performing this demo was fetched from Ludo’s Sketches. ForgeRock Documentation that talks of OpenDJ Data Replication can be found here.
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
This post picks up from an earlier one and maybe it makes sense to have look at that first before going through this one. So now that we have ForgeRock OpenIDM running inside a Linux Container, in the video log embedded below, we integrate it with ForgeRock OpenDJ. We’ll then use OpenIDM to provision users on to the OpenDJ. Here’s a summary of what you get to see in the video:
– A quick look at the existing installation of ForgeRock OpenIDM and ForgeRock OpenDJ
– Configuring OpenIDM with LDAP connector during startup using available sample files
– Reconciliation of identifies from ForgeRock OpenDJ to ForgeRock OpenIDM
– Provisioning users from ForgeRock OpenIDM to ForgeRock OpenDJ
Chronologically, this is my third blog update around ForgeRock software stack, the first two being Installation of OpenDJ in a Linux Container and ForgeRock OpenAM Installation in a LXC. While none of these entries have any dependency on each other whatsoever, it is recommended to watch it in order so as to get a fairly uncomplicated idea on the infrastructure being used for demonstrations. In the video logs embedded in all the blog posts as mentioned above, the ForgeRock products are being installed in Linux Containers in Ubuntu Linux flavour that in turn is running in a Virtual Box. Because I thought it maybe relatively effortless for you to sit back and enjoy watching a video rather than reading through a lengthy essay, I’m sticking to my idea of publishing my screen-cast on installation of ForgeRock OpenIDM in a Linux Container. In the screencast, you’ll find:
– Creating new linux container for installation of OpenIDM
– Installation of OpenIDM in a LXC
– Starting/stopping OpenIDM Services
– Accessing OpenIDM using REST calls
– Accessing OpenIDM using BUI
– Configuring OpenIDM as a run control script in Ubuntu Linux
With a hope that this screencast will give you a some understanding on getting started with ForgeRock OpenIDM, I here unto present it for you:
We will figure out how to use OpenIDM for Identity provisioning in a later segment, not too far in the future. In the mean time, if you would like to browse away the features of ForgeRock OpenIDM, its documentation can be found here.
In continuation to my earlier blog on Installing ForgeRock’s OpenDJ in a Linux Container, and to keep up with the promise of doing my bit to introduce ForgeRock’s software stack, I present here another set of video logs that takes you through the deployment of ForgeRock’s Access Management Solution:
– Installation of Apache Web Server in a Linux Container [Video 00]
– Installation of Apache Tomcat Application a Linux Container [Video 01]
– Deploying ForgeRock OpenAM in a Tomcat Application Server [Video 02]
– Protecting Apache Web Server using ForgeRock OpenAM [Video 03]
So after I bid farewell to over a decade long teaching profession, I’ve now joined the band @ ForgeRock. Feels at home, as I now find myself amongst some familiar folks, doing activities on popular open source products on Identity Management that has always been so dear to me.
Without any further ado, let me do my bit to introduce the ForgeRock products to you. To start with, I’ll help you setup ForgeRock’s directory service solution ‘OpenDJ’. Because I’ve a plan to show you the entire ForgeRock product portfolio over the next few weeks, I’ve setup the OpenDJ component in an OS virtualization solution. I’ve my own OS preferences, but for the sake of demonstration, I’ve decided to use the freely available Ubuntu OS. And in Ubuntu, we will create Linux Containers (a.k.a LXC), light weight OS virtualization solution. Over the next few weeks, we’ll have one container for each of the ForgeRock product.
Rather than writing a lengthy essay on the steps to create/configure Linux containers (LXC) and then install/configure ForgeRock’s OpenDJ, I’ve decided to publish my video logs here, which I think might turn out to be more convenient for you sit back and watch.
So here’s what I’ve done:
– Installed Ubuntu 14.04 LTS on a VirtualBox. [Video 00]
– Performed Package updates post installation.[Video 01]
– Installed the packages required for creating LXC.[Video 01]
– Installed the LXC Web Console package (to access LXC using BUI). [Video 01]
– Upgraded the host OS from 14.04 to 14.10 [not shown in the video]
– Cloned the LXC to create a new Linux Container for installing ForgeRock’s OpenDJ. [Video 02]
– Downloaded the OpenDJ software. [Video 02]
– Installed / Configured OpenDJ in a Linux Container [Video 02]
In case you are familiar with the Linux and Linux Container installation, feel free to skip the video 00 and video 01. Please also note that video recording was paused during the lengthy package installation procedure, which otherwise would have put you to sleep.
For a detailed introduction on OpenDJ, watch this video