Hacking OpenAM, Level: Nightmare

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:

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/)