Ludovic Poitou blog about Identity, Directory and others…

openig

A few years ago I had the pleasure to work with Rajesh Rajasekharan at Sun. He was an efficient trainer on Sun products and especially on Sun Directory Server. He recently joined ForgeRock and has started a series of blog posts and screen-casts on ForgeRock products and especially OpenDJ, but not only !

If you are getting started with the products or want to see demos of them, there’s no better place than to be on the “Learning Curve”

The Open Identity Gateway is a simple standard-based solution to secure access to web applications and APIs. It supports SAMLv2, OAuth 2.0, OpenID Connect and can capture and replay credentials, enabling SSO and Federation.

With a four months release cycle since the previous release, OpenIG 3.1 doesn’t contain many major new features, but it does bring several new enhancements to the product, including :

The support for encrypted JSON Web Token (JWT) cookies to store session information on the user-agent. The administrator can decide to keep the default container managed sessions, or use JWT cookies globally or for a specific route.

A simplification of OpenIG configuration, with the ability to inline objects, omit specific fields when empty or obvious. This simplification enables faster configuration as well as a better readability for long term maintenance of the service.

The introduction of “Decorator” for configuration objects, easily adding new behaviors to existing configured objects. OpenIG 3.1 provides 3 decorators out of the box: a CaptureDecorator that enables debugging and logging in a much easier and more dynamic way; a TimerDecorator that records times spent in the decorated objects; an AuditDecorator that allows to audit operations for any decorated objects.

The support for a sample monitoring handler that provides basic statistics about the exchanges and routes. The monitoring information can be used to provide an activity dashboard such as here on the right..

Some optimisations and performance improvements when using OpenID Connect and OAuth 2.0

For the complete details of the changes in OpenIG 3.1, please check the release notes.

If you want to expose the monitoring endpoint, you need to add the following 00-monitor.json file under .openig/config/routes/ and decorate a few handlers as Mark describes in his post. You might also want to extend this configuration to require authentication and avoid letting anyone have access to it.

The monitoring endpoint allows to display basic statistics about the different routes: the counts of in progress requests, completed requests and failures. So the output looks like this:

Each tag represents a route in OpenIG, including the “monitor” one, “main” representing the sum of all routes.

I was thinking about a better way to visualise the statistics and came up with the idea of a monitoring console. A few lines of Javascript, using JQuery and Bootstrap, an additional configuration file for OpenIG and here’s the result:

As you can see, this adds a new endpoint with its own audit: /openig/Console. The endpoint can be protected like any other route using OAuth2.0, OpenID Connect, SAML or basic authentication.

Let’s look at what I’ve done.

I’ve added a new route under ~/.openig/config/routes: 00-console.json with a single StaticResponseHandler. Instead of adding the whole content in the json file, I’ve decided to let the handler load the whole content from a file (named console.html). This allows me to separate the logic from the content.

The whole Console fits within 60 lines of html and javascript, including some logic to use different colours when internal errors occur on a route.

Finally, the nice thing about the Console, being based on BootStrap, it also has responsive design and allows me to monitor my OpenIG instance from anywhere, including my phone:

If you do install the Console on your instance of OpenIG 3.1 (or one of the latest nightly builds), please send me a screenshot. And if you do customize the javascript for an even nicer look and feel, don’t hesitate to send a pull request.

Like this:

In the article that I’ve posted yesterday, I’ve outline portions of configuration files for OpenIG. The configuration is actually only working with the latest OpenIG nightly builds, as it leverages some of the newest updates to the code.

One of the feedback that we got after we released was that configuring OpenIG was still too complex and verbose. So, we’ve made changes to the model, simplifying it, removing intermediate objects… The result is much smaller and easier to understand configuration files, but more importantly, easier to read back and understand the flow they represents.

My colleague Mark has done a great job of describing and illustrating those changes in a few articles :