« February »
Locations of visitors to this page

Powered by blojsom

Radovan Semančík's Weblog

Friday, 27 February 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/)

Technorati Tags:

Posted by rsemancik at 10:58 AM in Identity
Tuesday, 17 February 2015

The Evolveum team is great. I cannot put it in any other way. It is the best team that I have ever worked with. I have a long history of projects that I worked on: big projects, small projects, corporate projects, academic projects, consulting projects, deployment projects, development projects ... and some of these were extremely exciting and they had really good people on board. But none of the project teams was anything like the Evolveum team. Not even close.

What makes our team this great? I suppose it is a combination of several factors. First of all we have the best people. Each team member has a slightly different personality. Each of us has their own little quirks. But all the team members support the common goal. We work together, not against each other. And it is perhaps this precious combination of human characters and the atmosphere of cooperation that makes our team mostly self-organized. The team does not have any strong central coordination. Oh yes, I'm formally "The Architect". But I do not give orders. I do not distribute the work in the team. Nobody does. Team members are doing the work because they want to. Also the amount of coordination that I do is close to zero. It mostly amounts to answering questions and discussing ideas. Everybody somehow naturally knows what to do.

If anyone told me five years ago that this self-organization is a real thing, I would not believe that. But it is real. And it is unbelievably efficient. MidPoint project formally started later than its competitors. But our development pace is significantly faster. MidPoint is now the biggest and the most comprehensive open source identity management system. We have left our competitors behind. Thanks to our excellent team.

Our team does not work together in one office. We are distributed in space and sometimes it looks like we are also distributed in time. We are used to cooperate remotely. Therefore it is quite a rare occasion when the team meets in the flesh. Like this one:

Evolveum team ... and part of the families

Chene Slovaque

We met for a chat and a glass (well, glasses, actually) of local wine. There are several excellent winemakers on the slopes of Carpathia montains. And we have comandeered a cellar that belongs to one of them ...

Unfortunatelly, not all the team members were able to come there. But most of them did. And I had something to say. I had to say how thankful I am to be part of all of this. And I would like to repeat that. I thank every member of our team. Every single one: I thank you to be with us. There were hard times and you stayed with us. You did your best. So thank you all. And thank you to your families and friends that support you. You are the best team that I was ever part of. And that means something.

(Reposted from https://www.evolveum.com/evolveum-winter-2015/)

Technorati Tags:

Posted by rsemancik at 4:09 PM in Identity
Tuesday, 10 February 2015

MidPoint 3.1 was released few days ago. This midPoint version is code-named "Sinan" in honor of Koca Mimar Sinan, Turkish architect and civil engineer. Sinan was undoubtedly one of the best and most efficient builder of civic structures that the world has ever seen. And that's exactly how we want midPoint to be: efficient, elegant and useful. And I think that we have reached this goal with midPoint 3.1.

Perhaps the most important improvement in midPoint 3.1 is the resource wizard. Complete resource configuration can now be set up by using midPoint user interface. MidPoint is very powerful and there are literally hundreds of configuration options, therefore creating "the wizard" was a major feat. But now it is done and ready for use. There are also plenty of help texts and tooltips. It looks like this:

midPoint Resource Wizard

There is also a lot of smaller user interface improvements. They all together make midPoint UI much easier to use. Many of these improvements are based on feedback from midPoint user community - and we are very grateful for this. We always try to make the user experience as smooth as possible therfore do not hesitate and give us any suggestions that you might have. MidPoint 3.1 also has significant performance and scalability improvements, stability improvements and bugfixes.

Although midPoint 3.1 might be a bit less rich when it comes to the new major features. But the combination of numerous small improvements make the "Sinan" release a major leap forward. MidPoint is now undoubtedly the biggest and most comprehensive open source identity management system available. It is stable, mature and efficient. Therefore do not hesitate and give it a try.

(Reposted from https://www.evolveum.com/midpoint-3-1/)

Technorati Tags:

Posted by rsemancik at 8:12 PM in Identity