Creating space & sandcastles

Boxed in

ForgeRock is hiring lots of people these days. Great for the company, and a fantastic opportunity for those who we bring on. In the process of hunting for future ForgeRock talent however, I have been struck by how many candidates are boxed in at their current companies. By boxed in I mean that they get put into a particular role and position with little room for development until more senior staff step aside, or the team is disbanded.

If life is a journey then this compares to standing patiently in a queue, waiting for the day it is your turn. Food for a patient soul, rather than an adventurous one.

Opening the box

It is natural for teams and organizations to have a structure; anarchy is seldom fun for long. In the engineering team at ForgeRock we manage that structure by creating personal roles and creating room for personal development. Typically in a software team you will find team leads, architects, senior developers, etc – fairly fixed roles (although I have never heard the same definition of an architect role twice!). By hiring to the team with the expectation that everyone will partake in these activities we open up new possibilities where individuals can explore and grow without the pressure of a binary decision. Sure, it takes a special kind of team to make this work, but that is what we are all about – building a company of great people.

Creating space

But how to provide an opportunity for the developer who would like to get more involved in design questions, or have a more customer-facing role? The problem with being boxed in is that there is no-where to go, no space to move into. That space is filled by other people already doing the job (engineers are not known for elbowing their way forward) – and that is what this boils down to: making sure that the big personalities and roles don’t do the jobs that others could grow into. Like a sandy beach, you may want the water to fill the moat around your sandcastle but instead of waiting for the tide, you remove some sand to make room for the water to fill.

I’ll conclude this thought for the day with Jimi Hendrix’s Castles made of Sand:

Subject to change – JAAS to JASPI

The move from JAAS to JASPI subtly changes how we interact with identities. In the world of JAAS we deal with Subjects who are the entities making a request, typically a user, whilst Java EE deals with Principals, the representation of that entity such as a username. The difference may not seem great, but a Subject may have several Principals and this has caused some headaches when using JAAS, leaving determination of the relevant Principal to the implementation.

The days of JAAS have long been numbered however, and JSR-196 (also known as JASPI or JASPIC) is emerging at last; inclusion in JEE6 has definitely helped to push JASPI beyond just Glassfish support.

One of the changes is using the CallerPrincipalCallback to present to the container which Principal is applicable; and which is then available in the ServletRequest using getUserPrincipal(…).

Some background music for mulling over Subjects and Principals: Subject’s theme from Aldo Nova

Gathering no moss

The ForgeRock is a rolling stone at the moment and gathering no moss. Here are some of the things we have been up to recently:

As it happens, our Rock is at the top of a big hill and we are still picking up speed :-)

What’s in a name?

Names come in all forms and sizes; official and informal, first middle and last, identifiers and labels. And here is a new type of the name: the ForgeRock name.

As Joe Brockmeier discussed in a blog entry last year, Open Source does not normally say anything about the trademarks that may apply to the software. The current situation in Sun-Oracle may leave a number of Open Source projects out in the cold – and when crunch time comes (is it here already?) then this may be a hot issue.

As Oracle recently removed all open downloads from, ForgeRock are the new home of binary downloads for the OpenSSO community, providing essentially the same compiled code as before. Except for the name.

So – OpenAM is the new OpenSSO. Remember the name next time you need a build :-)

The start of all things

Everything starts somewhere, and this blog is starting for a reason. We at ForgeRock have recently launched our business and have a lot to say – this blog is one of those ways :-)

So I can start off by saying that the purchase of Sun by Oracle took a long time but was finally completed on January 27th. As you will see from, ForgeRock has it’s roots in the software side of Sun, with almost all our employees having a background from Sun. Naturally we have been interested to see how the takeover would play out, especially with regards to Sun’s open source strategy. Oracle has made several statements about the direction they will be taking including these webcasts.

One of open source products we are particularly involved in is OpenSSO – a fully-featured, enterprise-class product for authentication, authorization, federation and much more. Oracle has said that OpenSSO will continue as an open source project but that Oracle Access Manager will be their strategic product for web single sign-on, and Oracle Federated Identity Manager for federated single sign-on.

What does the “strategic” product choice mean in practice? Nishant Kaushik (architect for Identity Management products at Oracle) in his blog answers like this:

“Strategic” means that this is the product that we will be innovating and developing new features for.

So according to this Oracle will not be innovating and developing new features for OpenSSO, but still hosting the open source project. This can also be seen on the employee side of Oracle where key players from the OpenSSO team are apparently either no longer working there or have been transferred to other teams.

What is the next step for OpenSSO then?