Jenkins and the mysterious Accept timed out error

Not so long ago I’ve been trying to set up a new Jenkins job on a freshly created Jenkins slave. Unfortunately for me the first attempt of running the Maven build resulted in a failure:

ERROR: Aborted Maven execution for InterruptedIOException
java.net.SocketTimeoutException: Accept timed out
 at java.net.PlainSocketImpl.socketAccept(Native Method)
 at java.net.AbstractPlainSocketImpl.accept(AbstractPlainSocketImpl.java:398)
 at java.net.ServerSocket.implAccept(ServerSocket.java:530)
 at java.net.ServerSocket.accept(ServerSocket.java:498)
 at hudson.maven.AbstractMavenProcessFactory$SocketHandler$AcceptorImpl.accept(AbstractMavenProcessFactory.java:211)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
 at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
 at java.lang.reflect.Method.invoke(Method.java:606)
 at hudson.remoting.RemoteInvocationHandler$RPCRequest.perform(RemoteInvocationHandler.java:309)
 at hudson.remoting.RemoteInvocationHandler$RPCRequest.call(RemoteInvocationHandler.java:290)
 at hudson.remoting.RemoteInvocationHandler$RPCRequest.call(RemoteInvocationHandler.java:249)
 at hudson.remoting.UserRequest.perform(UserRequest.java:118)
 at hudson.remoting.UserRequest.perform(UserRequest.java:48)
 at hudson.remoting.Request$2.run(Request.java:328)
 at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72)
 at java.util.concurrent.FutureTask.run(FutureTask.java:262)
 at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
 at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
 at java.lang.Thread.run(Thread.java:745)

Jenkins normally kicks off Maven builds by forking a Maven process on the system and then using Maven extensions to become part of the build process. So let’s have a look at an example command Jenkins runs for a Maven build:

[OpenAM] $ /jdk8/bin/java -cp /jenkins/maven31-agent.jar:/apache-maven-3.2.3/boot/plexus-classworlds-2.5.1.jar:/apache-maven-3.2.3/conf/logging jenkins.maven3.agent.Maven31Main /apache-maven-3.2.3 /jenkins/slave.jar /jenkins/maven31-interceptor.jar /jenkins/maven3-interceptor-commons.jar 57186

Here, that last parameter, 57186, looks quite suspiciously like a random port number. Could it be that Jenkins tries to connect to this local port and this connection fails resulting in the above stacktrace? Well, easy to test, let’s run the following iptables command on the box:

iptables -I INPUT -i lo -j ACCEPT

Try to rerun the build, and voilà, the build progresses further. Lesson learned. ;)

OpenIG’s improved configuration files

openig-logoIn the last couple of weeks, Guillaume and Violette have introduced more slick configuration improvements into the latest nightly builds of OpenIG. To me these are the coolest features since Guillaume added routing with support for runtime configuration changes in OpenIG 3.0.0. The changes are backwards compatible, too, so you don’t have to move right away if you just want to upgrade for other reasons.

In OpenIG 3.0.0 you have to declare all your objects in the heap, and then use the “name” wherever you reference the object. Also, you have to declare the “config” on an object, even if it is empty. (You leave “config” empty when all the fields are optional, and you want default settings for everything).

{
  "heap": {
    "objects": [
      {
        "name": "Chain",
        "type": "Chain",
        "config": {
          "filters": [
            "CaptureFilter"
          ],
          "handler": "Router"
        }
      },
      {
        "name": "CaptureFilter",
        "type": "CaptureFilter",
        "config": {
          "file": "/tmp/gateway.log"
        }
      },
      {
        "name": "Router",
        "type": "Router",
        "config": {}
      },
      {
        "name": "ClientHandler",
        "type": "ClientHandler",
        "comment": "HTTP client for routes",
        "config": {}
      }
    ]
  },
  "handler": "Chain"
}

That example is small, so it is still pretty easy to see what you are doing.

If the configuration file gets any longer, it can be tough to see the relationships.

What Guillaume did is allow you to add the configuration objects inline. (In the case where the object is only used in one place in the configuration, why not just declare it right there?) Violette then made empty “config” fields optional.

Now you can write it like this:

{
  "heap": {
    "objects": [
      {
        "name": "Chain",
        "type": "Chain",
        "config": {
          "filters": [
            {
              "type": "CaptureFilter",
              "config": {
                "file": "/tmp/gateway.log"
              }
            }
          ],
          "handler": {
            "type": "Router"
          }
        }
      },
      {
        "name": "ClientHandler",
        "type": "ClientHandler",
        "comment": "HTTP client for routes",
      }
    ]
  },
  "handler": "Chain"
}

Notice how easy it is to see what’s happening in the “Chain”.

The draft, in-progress docs and examples have all been updated to use the new, inline style. Check out what this does for some of the more complicated examples.

My favorite? If the file above is your main config.json, then your default route can be succinct indeed:

{
  "heap": {
    "objects": []
  },
  "handler": "ClientHandler"
}

Introduction to OpenIG (Part 1: Use cases)

Welcome

You've probably landed here because you want to know something about OpenIG. This is the right place to be :)

This post is the first one of a serie of OpenIG-related articles that would gives you hand-on samples with explanations.

Identity Gateway

OpenIG stands for Open Identity Gateway, it is an identity/security specialized reverse proxy. That means that it control the access to a set of internal services.

By controling the access, I mean that it intercepts all the requests coming to the protected service (be it a RESTful API or a web application) and process them before (and after) forwarding them to the server.

Different kind of processing can be handled:

  • Request authorization
  • Capture and password replay
  • Message logging
  • Transformation

Commons use cases

Ok, that was a bit of a generalist description (transformation is intentionally vague :) ). Having some real-life use cases will help to have a better feeling/understanding of what OpenIG is capable of.

SAML Application Federation

In this use case, OpenIG acts as a SAML-enabled facade to a somehow legacy application that cannot be adapted to support SAML federation. The Identity Provider (could be OpenAM) will consider OpenIG as a standard SAML Service Provider.

SAML CoT with OpenIG used as a facade to a legacy application

Application Authentication

Here, OpenIG acts as an OpenID Connect Relying Party (OIDC terminology for client) and requires the user to authenticate to an OpenID Connect Provider (the identity provider) before giving him/her access to the protected application.

Authenticated user's profile information (such as name, email, address, picture, ...) are available to enrich the user experience, or make further verifications.

OpenID Connect - OpenIG Relying Party

RESTful Services Protection

This simple case shows OpenIG verifying request to a proxified RESTful API: each request must contains a valid OAuth 2.0 Bearer Token to be allowed to reach the service API. In this case, OpenIG acts as an OAuth 2.0 Resource Server.

Very useful if you have an old-fashioned REST API that you cannot easily update to deal with OAuth 2.0 tokens.

OAuth 2.0 - OpenIG ResourceServer

Not enough ?

Well, we're done with the 'marketing' stuff. In the next post, we will start to play with OpenIG.

See you soon!

Join us for the 2014 European IRM Summit, Nov 3-5 2014…

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 !


Filed under: Identity Tagged: conference, Dublin, europe, ForgeRock, identity, Ireland, IRM, IRMSummit, IRMSummit2014, IRMSummitEurope, openam, opendj, openidm, openig, opensource

OpenDJ directory server & groups

OpenDJ Logo When you think about groups in general, you realize there are different ways to define groups.

You can define a group by:

  • Specifying attributes that all members have in common (“All the software developers in Grenoble”).
  • Listing the members (“Alice, Bob, Carol”).
  • Using a mix of both (all the software developers in Grenoble, plus Alice, Bob, and Carol).

Notice that when you define a group by attributes of its members, the size of the definition is not a function of the size of the group. “All the software developers in Grenoble” remains the same size, even if the number of software developers in Grenoble varies.

Also notice that when you define a group by listing its members, the size of the definition depends mainly on the size of the group. “Alice, Bob, Carol” is about half the size of “Alice, Bob, Carol, Dan, Elena, Francis.”

OpenDJ directory server has groups of each of these types.

  • OpenDJ represents groups as directory entries. The group entry’s objectClass tells you what type of group it is.
  • Dynamic groups work by specifying attributes that all members have in common. They identify members by LDAP URLs, as in memberUrl: ldap:///ou=Developers,ou=People,dc=example,dc=com??sub?l=Grenoble. This is like specifying members by LDAP search, as in ldapsearch --baseDN ou=Product Development,ou=People,dc=example,dc=com "(l=Grenoble)".
    Dynamic group entries have objectClass: groupOfUrls. Dynamic group entries generally remain small even when they have lots of members.
  • Static groups list each member. Static group entries can have several object classes in OpenDJ, including groupOfNames, groupOfUniqueNames, and groupOfEntries.
    For groups with objectClass: groupOfNames and objectClass: groupOfEntries the member attribute is member, as in

    member: uid=Alice,ou=People,dc=example,dc=com
    member: uid=Bob,ou=People,dc=example,dc=com
    member: uid=Carol,ou=People,dc=example,dc=com
    member: cn=Grenoble Developers,ou=Groups,dc=example,dc=com
    

    As you would expect, static group entries get larger as you add members.

    You can nest groups, too, by adding a group as a member of a group. (For instance, the last member in the example is the Grenoble Developers group.)

    When you delete an entry or rename an entry, you no longer want it referenced in static groups. OpenDJ has a referential integrity plugin to handle this.

  • When you look up a dynamic group in OpenDJ what you get is the memberUrl value. This is fine if you are ready to use the LDAP URL, but not so great if you just wanted a list of the member entries. OpenDJ therefore provides what are called virtual static groups. Virtual static groups have OpenDJ look up the members of a dynamic group, and then return the list when you read the entry.

Checking group membership

In general, avoid reading and writing whole static group entries, because static groups can be large. Why read an entire 1-million-member static group entry over the network when all you want is to do is check membership for one or two entries?

To make it easy to check group membership, OpenDJ provides a virtual attribute, isMemberOf. If you explicitly request isMemberOf with a search, the values OpenDJ returns are the DNs of groups the entry belongs to. Reading isMemberOf is the recommended way to look up group membership.

Updating static groups

You can update a large OpenDJ static group without reading the group, and without checking membership beforehand. Use the Permissive Modify control (--control 1.2.840.113556.1.4.1413).

If you have an application that needs notification of changes to groups, OpenDJ has you covered there as well. Instead of polling group entries, you can use the external change log mechanism. The external change log is related to directory replication.

Where to go from here

This discussion of OpenDJ groups only scratches the surface. To dig a bit deeper, have a look at these sections in the documentation:


Some OpenIG related articles…

OpenIGMy 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.


Filed under: Identity Gateway Tagged: ForgeRock, identity, identity gateway, openig, opensource

First round is mine!

Wow,

... this is my very first blog post for years !!!

I'm usually more a tech reader than a tech writer, but I feel that it is time to start sharing on technology.

The easier for me to start with is using the open source project I'm working on as a source of inspiration :)

I want to begin with some introduction on OpenIG: what is it, picturing some use cases and mostly focusing on tips and tricks.

I hope you'll appreciate.

Cheers!

New ForgeRock product available : 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.

OpenIGOpenIG 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:

  • Support for OAuth 2.0 and OpenID Connect standard protocol to ease authentication and authorized access from clients, browsers, mobile devices and things
  • Support for scripting using the Groovy language to quickly develop complex flows
  • Support for protecting multiple applications or APIs with a single instance and splitting configuration in multiple dynamically reloaded files

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.


Filed under: Identity, Identity Gateway Tagged: authentication, authorization, ForgeRock, gateway, identity, oauth2, openidconnect, openig, opensource, product, release, samlv2, security

4 years !

ForgeRock logoFour years ago, exactly I was free from all obligations with my previous employer and started to work for ForgeRock.

My first goal was to setup the French subsidiary and start thinking of building a team to take on development of what we named a coming later OpenDJ.

4 years later, I look at where we are with ForgeRock and I feel amazed and really proud of what we’ve built. vertical-logo_webForgeRock is now well established global business with several hundreds of customers across the globe, and plenty of opportunities for growth. The company has grown to more than 200 employees worldwide and still expanding. The ForgeRock Grenoble Engineering Center has moved to new offices end of May and counts 13, soon 14 employees and we’re still hiring.

Thanks to the ForgeRock founders for the opportunity and let’s keep rocking !!!
ForgeRock CEOForgeRock CTO and Founder


Filed under: General Tagged: ForgeRock, france, grenoble, identity, opendj, startup

New introduction to OpenIG

openig-logo Around the time OpenIG 3.0.0 released back in August, we decided that the introductory part of the main guide left much up to the reader. Indeed, it introduced all the concepts, but you had to play with OpenIG for a while until those concepts would sink in.

For those of you trying the nightly builds, notice that since then the aim has been to simplify the draft of the next Guide to OpenIG. Thanks to Christophe, Guillaume, Jean-Charles, Ludo, Matt, Simon, Violette, Warren, and all of you who have offered your suggestions and pointed out parts that needed attention.

Now the guide starts with a short chapter on Understanding OpenIG. That chapter covers the main concepts that help you get started: the Exchange that encapsulates the HTTP request and the response as well as state information, the configuration including routes, how Filters and Handlers are chained together and how the Exchange flows through a chain.

The rest of the guide aims to be hands-on & practical. From the Getting Started chapter that should have you protecting your first app in a few minutes, through Installation in Detail and a series of tutorial chapters and configuration templates, to scripting and troubleshooting, you pick up the ideas a few at a time while seeing OpenIG in action.

Once you feel pretty confident that you understand how OpenIG works, to get all the details or to find just the right tool for a particular job you can check out the draft Reference.

Please feel welcome to log issues against these and all of the docs that we are working on.