API

OpenIG 3.1 is now available…

LudoLeave a comment

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 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.
  • IMG_4090The 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.

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.

 

API Protection with OpenIG: Controlling access by methods

Ludo1 Comment

OpenIGUsually, 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.