Once upon a time there was a computer company that loved open source software but they forgot to make money. Another big successful company came and bought the other. The big company did not like open source but they know how to make money. Since they already had similar closed-source software products, they decided to put the open source in second place. Quite understandable – remember they don’t like open source but they know how to make …
It is now more than 3 years when Sun was taken over by Oracle. Sooner or later customers who invested a lot of work and money to implement and maintain their OpenSSO infrastructure must decide on how to go forward with the product.
Oracle decided to put OpenSSO in maintenance mode. What does this mean? In the last two years a few updates/patches to the product were released but no major release and no new features. There is no roadmap. For web policy agents it is even worse. Almost no patch releases, no support for newer operating system versions. It does not mean that there is no support if you run into problems. But you have first to run into already known problems to file bugs and get a patch. Even for real critical bugs. That’s tedious …
Customers are safe and get support from Oracle, if they don’t need new features, but at one point in time OpenSSO customers have to make up their mind and develop a migration strategy. The first software that comes into consideration will be Forgerock’s OpenAM, a fork of OpenSSO. So the migration promises to be quite straightforward. The second thought would be to look at Oracle’s Access Manager (OAM). Oracle might have had reasons to abandon OpenSSO in favor of OAM. Oracle normally does not leave its customer alone and offers tools for a smooth migration.
A decision in favor of OpenAM or OAM might be the result of different aspects. Technical guys will primarily look at features and architecture. For business and strategical thinking people a close look on the companies behind the products might be important as well. On the one hand there is Forgerock, a small but ambitious startup company and on the other hand Oracle, the software giant, that promises more stability and investment protection.
Forgerock started in 2010 when it became obvious that OpenSSO will not survive. Sun used to release Express versions of OpenSSO. Right before Express 9 should be released, Oracle stopped Express roll-outs. OpenSSO Enterprise 8.0 was at that time equivalent to Express 6 (today it is still this version with bug fixes and some minor feature enhancements mainly in the web service security space). This was the time when Forgerock stepped in, forked Express 9 and released their own version. In the beginning many people were skeptical whether Forgerock will be able to execute. But after 2 years, backed with a 7 million funding from Accel Partners, they not only proved to be able to run the business, they also expanded the portfolio with OpenDJ (a fork of OpenDS, Sun’s JAVA based directory server) and OpenIDM (a self written provisioning software).
There is not much to say about Oracle as a company. Let’s look at their Access Management software Oracle Access Manager. The roots of OAM are going back to Oblix, a company and a software product which was acquired by Oracle in 2005. If you have a closer look on OAM up to version 10g you will notice that the software architecture is quite different from what we were used from OpenSSO. OAM had separate server processes written in C++ and did not have a central server side user session. Session information was stored in the cookie. In addition to OAM, you need to deploy Oracle Identity Federation (OIF), if you are using federation protocols like SAML 2.0 in your OpenSSO deployment. With OAM 11g things changed. The software is now implemented in JAVA (either written from scratch or ported). With that in mind and if you take into consideration that the development from 11g to 11g R2 is really very dynamically catching up with features, you can argue that OAM 11g is a 1.0 version and not very mature. The latest OAM release also has now SAML 2.0 federation capabilities built in. So you might not need to deploy OIF anymore. At least if you are only running a service provider and not an identity provider.
What are your thoughts, plans or experience for the migration? We are happy to take your input as comment to the blog or through our contact form as we are preparing a deeper look into the topic.