Hacking OpenAM, Level: Nightmare

27 Feb 2015

I'm dealing with the OpenAM and its predecessors for a very long time. I remember Sun Directory Server Access Management Edition (DSAME) in early 2000s. After many years and (at least) three rebrandings the product was finally released as OpenSSO. That's where Oracle struck and killed the product. ForgeRock picked it up. And that's where the story starts to be interesting. But we will get to that later.

I was working with DSAME/SunAM/OpenSSO/OpenAM on and off during all that time that it existed. A year ago one of our best partners called and asked for help with OpenAM. They need to do some customizations. OpenAM is no longer my focus, but you cannot refuse a good partner, can you? So I have agreed. The start was easy. Just some custom authentication modules. But then it got a bit complicated. We figured out that the only way forward is to modify OpenAM source code. So we did that. Several times.

That was perhaps the first time in all that long history that I needed to have a close look at OpenAM source code. And I must honestly say that what have I seen scared me:

• OpenAM is formally Java 6. Which is a problem in itself. Java 6 does not have any public updates for almost two years. But what is worse is that bulk of the OpenAM code is still efficiently Java 1.4 or even older. E.g. the generics are almost not used at all! Vast majority of OpenAM code looks like it was written before 2004.
• OpenAM is huge. It consists of approx. 2 million lines of source code. It is also quite complicated. There is some component structure. But it does not make much sense on the first sight. OpenAM also does not have any documents describing the system architecture from a developers point of view. The only link that I was able to find still points to Sun OpenSSO document. And it is 5 years since ForgeRock took over the development!
• OpenAM is in fact (at least) two somehow separate products. There is "AM" part and "FM" part. And these two were not integrated in the cleanest way. The divide is still very obvious. And it gets into the way whenever you want to do something with "federation". E.g. SAML assertion is available in the "FM" part, but not in the authentication modules. The session is central concept in "AM" part, but it is not available in the code that is processing assertion. So, if you need to do some custom code with the assertion that affects the session you are out of luck (no, the custom attribute mapper will not help either). And the most bizarre thing is that OpenAM sometimes obviously creates two or even three sessions for the same user. The it discards the extra sessions. But whatever you do in the authentication modules is discarded with them. This is a mess.
• OpenAM debugging is a pain. It is almost uncontrollable, it floods log files with useless data and the little pieces of useful information are lost in it. And to understand most of the diagnostic output you just have to look into the source code. This is a 20th century technology. Java logging API was available in Java 1.4 (February 2002). But OpenAM is not using that. This suggests that the OpenAM core may be even older than what I've previously thought.
• OpenAM is still using obsolete technologies such as JAX-RPC. JAX-RPC is a really bad API. It was a big mistake. Even the Sun engineers obviously knew that and they have deprecated the API in December 2006. That was more than 8 years ago. But OpenAM is still using it. Unbelievable. But worse than that: this efficiently ruins any attempt to use modern web services. E.g. if you need your authentication handler to invoke a SOAP service which uses WS-Security with SAML token retrieved from STS then you are in trouble. This is pretty much standard thing today. E.g. with recent versions of Apache CXF it takes only a handful of lines of code to do. But not in OpenAM.

Using some software archeology techniques I estimate that the core of current OpenAM originated between 1998 and 2002 (it has collections, but not logging and no generics). And the better part of the code is stuck in that time as well. So, now we have this huge pile of badly structured, poorly documented and obsolete code that was designed at the time when people believed in Y2K. Would you deploy that into your environment?

I guess that most of these problems were caused by the original Sun team. E.g. the JAX-RPC was already deprecated when Sun released OpenSSO, but it was not replaced. Logging API was already available for many years, but they haven't migrated to it. Anyway, that is what one would expect from a closed-source software company such as Sun. But when ForgeRock took over I have expected that they will do more than just take the product, re-brand it and keep it barely alive on a life support. ForgeRock should have invested in a substantial refactoring of OpenAM. But it obviously haven't. ForgeRock is the maintainer of OpenAM for 5 years. It is a lot of time to do what had to be done. But the product is technologically still stuck in early 2000s.

I also guess that the support fees for OpenAM are likely to be very high. Maintaining 2M lines of obsolete code is not an easy task. It looks like it takes approx. 40 engineers to do it (plus other support staff). ForgeRock also has a mandatory code review process for every code modification. I have experienced that process first-hand when we were cooperating on OpenICF. This process heavily impacts efficiency and that was one of the reasons why we have separated from OpenICF project. All of this is likely to be reflected in support pricing. My another guess is that the maintenance effort is very likely to increase. I think that all the chances to efficiently re-engineer OpenAM core are gone now. Therefore I believe that OpenAM is a development dead end.

I quite liked the OpenSSO and its predecessors in early 2000s. At that time the product was slightly better than the competition. The problem is that OpenAM is mostly the same as it was ten years ago. But the world has moved on. And OpenAM haven't. I have been recommending the DSAME, Sun Identity Server, Sun Java System Access Manager, OpenSSO and also OpenAM to our customers. But I will not do it any more. And looking back I have to publicly apologize to all the customers that I have ever recommended OpenAM to them.

Everything in this post are just my personal opinions. They are based on more than a decade long experience with DSAME/SunAM/OpenSSO/OpenAM. But these are still just opinions, not facts. Your mileage may vary. You do not need to believe me. OpenAM is open source. Go and check it out yourself.

UPDATE: There is follow-up: Comparing Disasters

(Reposted from https://www.evolveum.com/hacking-openam-level-nightmare/)