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”
Thanks to Chris Lee, the most recent technical writer at ForgeRock, there is now a new visual design for the snapshot documentation for our open source projects.
Check it out on the OpenDJ Administration Guide, the OpenDJ SDK Developer’s Guide, the OpenIDM Integrator’s Guide or the Guide to OpenIG…
It’s my great pleasure to announce the general availability of OpenIG 3.1, a minor update of the ForgeRock Open Identity Gateway product, following the press release of early December.
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 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.For the complete details of the changes in OpenIG 3.1, please check the release notes.
You can download the ForgeRock product here. It’s been heavily tested by our Quality Assurance team : functional tests on Windows, Mac and Linux, stress tests as proxy, with OAuth2 and OpenID Connect, non-regression tests… The documentation has been entirely reviewed and all examples tested. The source code is available in our code repository (https://svn.forgerock.org/openig).
We are interested in your feedback, so get it, play with it and give us your comments, either on the mailing list, the wiki, the OpenIG Forum or through blog posts.
OpenIG 3.1 is almost out the doors… Just a few days of testing and it will be generally available.
The new version introduces a general purpose auditing framework, and some basic monitoring capabilities. Mark wrote a blog post describing the details of the auditing framework and the monitoring endpoint. I’ve started playing with it for demonstration purposes and wanted to get more out of it.
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:
{"Users":{"in progress":0,"completed":6,"internal errors":0},
"main":{"in progress":1,"completed":1074,"internal errors":0},
"groups":{"in progress":0,"completed":4,"internal errors":0},
"Default":{"in progress":0,"completed":16,"internal errors":0},
"monitor":{"in progress":1,"completed":1048,"internal errors":0}
}
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.
00-console.json
{
"handler":{
"type": "StaticResponseHandler",
"config" : {
"status": 200,
"entity": "${read('/Users/ludo/.openig/config/routes/console.html')}"
}
},
"condition": "${exchange.request.method == 'GET'
and exchange.request.uri.path == '/openig/Console'}",
"audit" : "Console"
}
Note that if you are copying the 00-console.json file, you will need to edit the file location to match the absolute path of your console.html file.
Now the console.html file is actually a little bit long to display here. But you can download it here.
But it’s a basic html page, which loads Jquery and Bootstrap:
<!DOCTYPE html> <html lang="en"> <head> <link rel="stylesheet" href="//maxcdn.bootstrapcdn.com/bootstrap/3.3.0/css/bootstrap.min.css"> <!-- Optional theme --> <link rel="stylesheet" href="https://maxcdn.bootstrapcdn.com/bootstrap/3.3.1/css/bootstrap-theme.min.css"> <!-- Latest compiled and minified JavaScript --> <script src="//code.jquery.com/jquery-1.11.1.min.js"></script> ...
And at regular interval (default is 3 seconds), it gets the statistics from the monitoring endpoint, and displays them as a table:
...
<script>
$(document).ready(function () {
setInterval(function () {
$.get("/openig/monitor").success(writeRoutesStats);
}, 3000);
});
...
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.
Yesterday we’ve announced the new releases of 3 of ForgeRock products : OpenAM 12.0, OpenIDM 3.1 and OpenIG 3.1.
There are still a few days before we make OpenIG 3.1 generally available. We are currently stressing it out and reviewing the documentation. But all indicators are green for now :
I forgot to mention, but Guillaume, the lead developer for OpenIG, has also started a blog to discuss about Middleware, and share his experience and thoughts about OpenIG.
He has started a great series of posts introducing OpenIG, it’s use cases, some terminology…
I encourage you to take a look at it here : In Between – a Blog by Guillaume Sauthier
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 :
OpenIG’s improved configuration files (Part 1)
OpenIG: A quick look at decorators
OpenIG’s improve configuration files Part 2
Usually, one of the first thing you want to do when securing APIs is to only allow specifics calls to them. For example, you want to make sure that you can only read to specific URLs, or can call PUT but not POST to other ones.
OpenIG, the Open Identity Gateway, has a everything you need to do this by default using a DispatchHandler, in which you express the methods that you want to allow as a condition.
The configuration for the coming OpenIG 3.1 version, would look like this:
{
"name": "MethodFilterHandler",
"type": "DispatchHandler",
"config": {
"bindings": [
{
"handler": "ClientHandler",
"condition": "${exchange.request.method == 'GET' or exchange.request.method == 'HEAD'}",
"baseURI": "http://www.example.com:8089"
},
{
"handler": {
"type": "StaticResponseHandler",
"config": {
"status": 405,
"reason": "Method is not allowed",
"headers": {
"Allow": [ "GET", "HEAD" ]
}
}
}
}]
}
}
This is pretty straightforward, but if you want to allow another method, you need to update the both the condition and the rejection headers. And when you have multiple APIs with different methods that you want to allow or deny, you need to repeat this block of configuration or make a much complex condition expression.
But there is a simpler way, leveraging the scripting capabilities of OpenIG.
Create a file under your .openig/scripts/groovy named MethodFilter.groovy with the following content:
/**
* The contents of this file are subject to the terms of the Common Development and
* Distribution License 1.0 (the License). You may not use this file except in compliance with the
* License.
* Copyright 2014 ForgeRock AS.
* Author: Ludovic Poitou
*/
import org.forgerock.openig.http.Response
/*
* Filters requests that have the allowedmethods supplied using a
* configuration like the following:
*
* {
* "name": "MethodFilter",
* "type": "ScriptableFilter",
* "config": {
* "type": "application/x-groovy",
* "file": "MethodFilter.groovy",
* "args": {
* "allowedmethods": [ "GET", "HEAD" ]
* }
* }
* }
*/
if (allowedmethods.contains(exchange.request.method)) {
// Call the next handler. This returns when the request has been handled.
next.handle(exchange)
} else {
exchange.response = new Response()
exchange.response.status = 405
exchange.response.reason = "Method not allowed: (" + exchange.request.method +")"
exchange.response.headers.addAll("Allow", allowedmethods)
}
And now in all the places where you need to filter specific methods for an API, just add a filter to the Chain as below:
{
"heap": [
{
"name": "MethodFilterHandler",
"type": "Chain",
"config": {
"filters": [
{
"type": "ScriptableFilter",
"config": {
"type": "application/x-groovy",
"file": "MethodFilter.groovy",
"args": {
"allowedmethods": [ "GET", "HEAD" ]
}
}
}
],
"handler": "ClientHandler"
}
}
],
"handler": "MethodFilterHandler",
"baseURI": "http://www.example.com:8089"
}
This solution allows to filter different methods for different APIs with a simple configuration element, the “allowedmethods” field, for greater reusability.
Last week at the nice Powerscourt Estate, outside Dublin, Ireland, ForgeRock hosted the European Identity Relationship Management Summit, attended by over 200 partners, customers, prospects, users of ForgeRock technologies. What a great European IRMSummit it was !
If you haven’t been able to attend, here’s some highlights:
I heard many talks and discussions about Identity being the cornerstone in the digital transformation of enterprises and organizations. It shifting identity projects from a cost center to revenue generators.
There was lots of focus on consumer identity and access management, with some perspectives on current identity standards and what is going to be needed from the IRM solutions. We’ve also heard from security and analytics vendors, demonstrating how ForgeRock’s Open Identity Stack can be combined with the network security layer or with analytics tools to increase security and context awareness when controlling access.
User Managed Access is getting more and more real, as the specifications are getting close to be finalised and ForgeRock announced the OpenUMA initiative for foster ideas and code around it. See forgerock.org/openuma.
Many talks about Internet of Things and especially demonstration around defining the relationship between a Thing and a User, securing the access to the data produced by the Thing. We’ve seen a door lock being unlocked with a NFC enabled mobile phone, by provisioning over the air the appropriate credentials, a smart coffee machine able to identify the coffee type and the user, pushing the data to a web service, and asking the user for consent to share. There’s a common understanding that all the things will have identities and relations with other identities.
There were several interesting discussions and presentations about Digital Citizens, illustrated by reports from deployments in Norway, Switzerland, Nigeria, and the European Commission cross-border authentication initiatives STORK and eIDAS…
Half a day was dedicated to ForgeRock products, with introductory trainings, demonstrations of coming features in OpenAM, OpenDJ, OpenIDM and OpenIG. During the Wednesday afternoon, I did 2 presentations on OpenIG, demonstrating the ease of integration of OAuth2.0 and OpenID Connect to protect applications and APIs, and on OpenDJ, demonstrating the flexibility and power of the REST to LDAP interface.
All presentations and materials are available online as pdf and now as videos on the ForgeRock’s YouTube page. You can also find here a short summary of the Summit in a video produced by Markus.
The summit wouldn’t be such a great conference if there was no plan for social interactions and fun. This year we had a nice dinner in the Powerscourt house (aka the Castle) followed by live music in the pub. The band was great, but became even better when Joni and Eve joined them for a few songs, for the great pleasure of all the guests.
Of course, I have to admit that the best part of the IRM Summit in Ireland was the pints of Guinness !
To all attendees, thank you for your participation, the interesting discussions and the input to our products. I’m looking forward to see you again next year for the 2015 edition. Sláinte !
As usual, you can find the photos that I’ve taken at the Powerscourt Estate on Flickr. Feel free to copy for non commercial use, and if you do republish them, I would appreciate getting the credit for them.
[Updated on Nov 11] Added link to the highlight video produced by Markus
[Updated on Nov 13] Added link to the slideshare folder where all presentations have been published
[Updated on Nob 24] Added link to the all videos on ForgeRock’s YouTube page
Starting Monday next week, at the Powerscourt Estate near Dublin, the European IRM Summit is just a few days away.
I’m polishing the content and demos for the 2 sessions that I’m presenting, one for each product that I’m managing: OpenDJ and OpenIG. Both take place on the Wednesday afternoon in the Technology Overview track.
If you’re still contemplating whether you should attend the event, check the finalised agenda. And hurry up to the Registration site ! I’m told there are a few remaining seats available, but they might not last for long!
I looking forward to seeing everyone next week in Ireland.
There are conferences and there are Conferences. The Conferences are the ones that you remember, because they happened in unusual places, because they’ve had a different atmosphere, you’ve met lots of friendly and bright persons. They are the ones you leave with the satisfaction of having learned something, having received value, and you’re looking forward to come back next year.
The IRM Summit is one of these Conferences. The next European IRM Summit is taking place in November, 3 – 5, near Dublin, Ireland, at the Powerscourt Estate pictured here. It’s a 2 days event where you can learn and discuss about the Identity Relationship Management space, standards, platforms, solutions…There will be many presentations, demos, trainings, plenty of time for discussions and meetings, a free half day Kantara Initiative workshop around “Trusted IDentity Exchange (TIDX)”, and some fun. I can already hear the fiddle, the pipes, the harp and smell the Guinness ! And I hope the weather will let us enjoy the wonderful garden.
Check out the agenda and the list of speakers, and don’t wait until last minute to register. While there are hundreds of rooms available, they are still counted and limited. Last year’s summit was sold out !
I’m looking forward to see you in beautiful Ireland !
My coworkers have been better than me at writing blog articles about OpenIG (at least faster).
Here are a few links :
Simon Moffat describes the benefits of OAuth2.0 and OpenID Connect and how to start using those with OpenIG 3.0.
Warren Strange went a little bit further and with a short introduction to OpenIG, made available on GitHub sample configuration files for OpenIG 3.0 to start using OpenID Connect.
Mark, who run ForgeRock documentation team, describes the improvements done on the Introduction section of the OpenIG docs that we’re making based on received feedback since the release of OpenIG 3.0.
Since the beginning of the year, I’ve taken an additional responsibility at ForgeRock: Product Management for a new product finally named ForgeRock Open Identity Gateway (built from the OpenIG open source project).
OpenIG is not really a new project, as it’s been an optional module of OpenAM for the last 2 years. But with a new engineering team based in Grenoble, we’ve taken the project on a new trajectory and made a full product out of it.
OpenIG 3.0.0 was publicly released on August 11th and announced here and there. But as I was on holidays with the family, I had not written a blog post article about it.
So what is OpenIG and what’s new in the 3.0 release ?
OpenIG is a web and API access management solution that allows you to protect enterprise applications and APIs using open standards such as OAuth 2.0, OpenID Connect and SAMLv2.
Enhanced from the previous version are the Password Capture and Replay and SAMLv2 federation support features. But OpenIG 3.0 also brings several new features:
I’ve presented publicly the new product and features this week through a Webinar. The recording is now available, and so is the deck of slides that I’ve used.
You can download OpenIG 3.0 from ForgeRock.com, or if you would like to preview the enhancements that we’ve already started for the 3.1 release, get a nightly build from ForgeRock.org.
Play with it and let us know how it is working for you, either by email, using a blog post or writing an article on our wiki. I will be reviewing them, relaying and advertising your work. And I’m also preparing a surprise for the authors of the most outstanding use cases !
I’m looking forward to hear from you.
Ludo Sketches 