Sun Identity Manager from a developer's perspective

With Oracle’s announcement of the demise of Sun IDM I have been wondering whether or not the transition from an in-house identity management solution to a third party solution was worth the investment in time and effort?  Did we gain anything with Sun IDM that wasn’t already there with our legacy applications?

To answer that question I have to look at what we had in the past.  Prior to implementing SIM our identity management strategy comprised of a lot of custom software.  Everything worked well but was very rigid.  Unless you were the developer familiar with the source code, adding new features or changing business policies was not a trivial thing to do.  But it worked and it was reasonably quick.

Sun Identity Manager was supposed to allow us to continue to have that tight integration with our business policies and practices while remaining flexible to change.  After all, it had a workflow engine, a rules engine, resource adapters and a customizable web interface.  It sounded like a perfect solution.  So, several years and many hundreds of thousands of dollars later did Sun Identity Manager amount to any cost savings?  Was there any gain in flexibility?

Implementing our legacy software business rules and  policies in the IDM workflows was relatively easy.  Kudos to whatever design team made them.  The IDM workflow engine is pretty robust.  The rules engine is relatively weak but it does the job.  (It’s hardly more than a standard Java method call but at least you can update it on fly.)

As easy as customizing the workflows were, using the IDM forms proved to a huge pain in the ass.  At first it looks relatively simple.  Forms allow you to do two main things: data manipulation and HTML generation. But as soon as you try to do anything complex the forms simply become convoluted contorted messes of code.  Variables within IDM forms don’t seem to know the word “scope”.  And then there’s defining HTML within the same IDM form.  Sure you can customize the look and feel.  But be prepared for some serious pain when doing so.  I hate forms in Sun IDM.  I spent so much time just making plain old  HTML look “normal” that it pains me to think of the total number of hours wasted when I could have just accomplished the same task using a regular JSP/Freemarker/Velocity template in a tenth the time.

The interaction between forms and workflows was never fully documented.  For example, why is it the enable user form isn’t part of a workflow until the user is already enabled?  What if I wanted to do something before the form is displayed?  The workflow is initiated after the form is submitted and there’s no changing that.  There are just some things that you can’t do in Sun IDM so in some respects it’s not nearly as flexible as advertised.

However, adding new resources was a breeze.  We made huge gains in simple attribute synchronization.  Need another LDAP server?  Sure no problem; a few code tweaks there; some attribute definitions here and done.  ActiveSync was nice too.  When used with an ActiveSync workflow it just worked.  New data was just passed to the activesync workflow.  The rest was up to me.  Simple.

Given those points I’d say that using Sun Identity Manager was worth it, but just barely.  That’s partially because we never were fully able to complete our transition away from the legacy system.  We were stuck in a half completed state.  If we’d been able to fully transition our legacy system into Sun IDM I might feel differently.  It’s also related to the product itself.  The IDM forms bought us no gains.  In fact, they were a step back from our legacy system.  However, those steps back were countered by gains made in the ability to encode our business policies as workflows and rules as well as the ability to on-board new resources easily.  So, again, it breaks even.

With the experience I’ve gained with Sun IDM over the last 3 and a half years, I certainly know what I’m looking for in a replacement.