As Oracle effectively is putting the nails in the coffin and forever burying Sun Identity Manager (known now as Oracle Waveset) six feet under, it is time to react. The replacement decision customers will make will have a huge impact on the strategy around Identity Management going forward. Some customers will be bashed with the application centric, vendor locked-in message from Oracle, to migrate to Oracle Identity Manager or persuaded by traditional large vendors to pick their offering instead.
Fortunately there are alternatives that does not put you in the corner, allows you to be in control and establish a strategy that fits your needs at a cost that is reasonable; one of them being ForgeRock OpenIDM.
Lets look at four the typical use-cases a typical Sun IdM customer have deployed and discuss how OpenIDM matches up.
1.) Orphan account detection
2.) Authoratative Source driven provisioning
Sun IdM provides the mechanism of ActiveSync, where certain connectors or resource adapters are extended with the capability of reacting to near real-time (via scheduled polling). The ActiveSync process then discovers CREATE, UPDATE or DELETE situations on resource accounts and three different workflows parses a set of forms (typically referred to as ActiveSync forms) to manage the attribute transformations and identity data flow.
OpenIDM offers a similar capability and also leverages the same set of connectors as Sun IdM. In the world of OpenIDM this capability is referred to as LiveSync. The LiveSync process is typically a scheduled process running as a background process and instead of UserForms and XPRESS to define the transformations, these are specified in mappings describing the flow from one system to another. The LiveSync life-cycle offers a number of hooks that allows you to specify actions such as running custom scripts or invoking workflow offering the same flexibility and capabilites as Sun IdM.
3.) Password Management
A typical quick-win and low hanging fruit with Sun IdM was that once resource adapters or connectors were configured, the password management aspect came with the setup. Sun IdM allows you to specify governing password policy according to company requirements and enforce them during password resets. Sun IdM also allowed to intercept passwords on Active Directory by deploying a special plugin on the AD domain controllers. Self Service capabilties to reset passwords was by default managed using challenge/response questions that could either be specified by administrator or self-defined, or a combination of the two.
4.) Self Service requests
Sun IdM allows you to quickly and easily expose custom workflows that can interact with the virtual identity and the underlying integrated resources to do attribute updates or to provision new accounts etc. OpenIDM exposes the same capability but instead of using a proprietary workflow definition language, leverage the industry standard BPMN 2.0 to specify workflows.
OpenIDM has been designed with flexibility, modularity, scalability and developer-friendlyness in mind. That means it is a perfect fit for the same reasons Sun IdM was probably selected in the first place, but without any proprietary technologies being used required specific training. Time to make a decision; stuck in the corner or making a move that gives you options in the future?