Decomposing Identity Management Approval Workflows

One of the hallmarks of a poorly conceived identity management solution is a large number of workflows, particularly approval workflows. In one extreme case with which I'm familiar, a large financial services company has a Sun Identity Manager implementation that contains hundreds of individual approval workflows—one workflow for every entitlement, application or role that a user can request. They have a team of IDM engineers whose function is to build new workflows every time a new application needs to be integrated with the identity system. In most cases, this task involves cutting and pasting the XML from other similar workflows and then hardwiring them with application-specific metadata that is provided by a business analyst. Needless to say, this company eventually reached a point where the identity management system began to experience crippling performance issues.

When designing self-service request/approval workflows, it is important not to think in terms of individual applications but in terms of assets and generic approval patterns. An asset can be anything that might be requested; an application, entitlement, role or even an out-of-band asset such as a laptop or cellphone. Each asset, in turn, is logically mapped to an approval pattern. Even in the largest, most complex organizations, the number of approval patterns tends to be extremely small; in most cases no more than five to ten. In fact, one tends to find that most approval patterns are variations of the following:

• Manager-Only Approval
• Asynchronous Multi-Level Approval (all approvers must complete in order)
• Synchronous Partial Approval ('x' of 'y' approvers must complete)
• Synchronous Full Approval (all approvers must complete in any order)

When one decomposes the major functionality of any approval workflow into its constituent parts, it becomes much easier to visualize:

Figure 1: Decomposition of an IDM Approval Workflow (Click for full-size version)

Let's examine the three major processes illustrated above.

Request Process: This handles an asset request from an end user or an approved designate. Optionally, this process may include generation of a request form, which collects additional, asset-specific information from the requester that is required to support the request (for example, a business case for requesting the asset). 

Approval Process: Once the request has been submitted, an approval workflow is invoked. An asset-to-pattern mapping determines the particular approval pattern to invoke. Optionally, approvers may be required to complete an approval form, in which they will enter additional information that is necessary to provision the asset. 

Execution Process: After all requisite approvals have been completed, the asset needs to be provisioned. This can be done automatically using a provisioning connector, or by generating a ticket to a human provisioner.

All three processes require metadata about the asset. Depending on the capabilities of the identity management system, metadata can be stored in the system itself, or even externalized in an RDBMS system or LDAP directory. Among other elements, metadata may include the fields to render on asset-specific request/approval forms, email templates, escalation settings, delinquency timeouts, instructions for the execution process on what to do when all approvals have been completed, and of course the type of approval workflow pattern to invoke.

This approach allows for the design of highly generic, dynamic and reusable workflow templates, which in turn facilitates the rapid integration of new assets for self-service access requests. The loosely-coupled nature of a pattern-based workflow architecture is also consistent with the governance-based implementation strategy I've described in previous posts, which is based on decoupling automated provisioning from account discovery and asset definition. Using metadata to drive execution of a provisioning action should in most cases allow administrators to "flick a switch" simply by updating the metadata itself once they are ready to turn on automated provisioning for a particular asset.

Of course, the obvious question is what does it take from a technical perspective to build an asset integration framework like this. Obviously, the specific implementation depends very much on your unique business requirements and the capabilities of the identity management system you are using, which is why I've attempted to keep this overview product-agnostic. With that said, this approach is certainly compatible with solutions such as OIM, SIM/Oracle Waveset, Novell IdM, SailPoint IdentityIQ and Quest One Identity Manager.

All of which also raises another advantage of pattern-based workflows. If at any point in the future, you plan to migrate to another identity solution, it is much easier to migrate a tiny handful of workflows than it is to migrate several thousand.

Reflections on Sun Identity Man.... I mean, Oracle Waveset

It doesn't seem like two and a half years since Oracle shocked the technology world by announcing its $7 billion acquisition of Sun Microsystems, although a tremendous amount has happened in that time. For the most part, it has to be said that Oracle has done an outstanding job of assimilating Sun's technologies into their product portfolio. But in the IAM space, where it is not unusual for product migrations to take several years, there is still a great deal of work to be done.

Sun Identity Manager, which has been rebranded as Oracle Waveset and will reach end of life in 2014, continues to have an enormous footprint in the enterprise. Even a year and a half after Oracle announced EOL for the product, we still see customers continuing to develop and evolve their SIM/OW implementations, and in many cases express little appetite for migrating to OIM or any other identity suite, at least in the short term.

Some of us in the IAM community were more than a little surprised at Oracle's decision to select OIM over OW as its strategic provisioning solution, considering OW's extensive deploy base and maturity. But in retrospect, it was probably the right decision given the significant investment Oracle had already made in enhancing their existing IAM stack, of which OIM is a core component. With the release of OIM 11gR2, it is hard to deny that OIM is a superior product to OW in almost every respect.

The great thing about OW was that you could literally customize the tool to do anything you wanted. Its biggest flaw was that you could literally customize the tool to do anything you wanted. The open nature of OW was an engineer's dream. If a customer requirement wasn't met by out-of-the-box functionality, it could easily be provided by customizing the product using Java APIs and/or XPRESS scripts. Hell, I've even seen interfaces for OW built in .NET. Even after all this time, I'm still astounded by the creativity of some of the OW implementations out there, although I'm just as often left shaking my head in dismay, wondering how customers have allowed themselves to get into trouble with such poorly conceived customizations.

Typically, OW customers have made an enormous investment in developing sophisticated implementations and the specialized skillsets that are required to maintain them, so it is unreasonable to expect them to turn on a dime. Many implementations involve custom resource adapters, heavily customized rules and workflows, and sophisticated user interfaces. This makes it nearly impossible to automate the migration of OW to OIM or any other product, since no two OW deployments are identical.

Oracle has made a valiant attempt to smooth the migration path to OIM by releasing the OW2OIM migration tool. This tool performs a functional mapping between discovered OW configurations and their OIM equivalents, and can even automate the migration of certain objects (although not more sophisticated objects such as user forms, rule libraries and task definitions). At Qubera, we have developed our own upgrade assessment tool, which performs a deep dive analysis of an OW implementation and produces both an impact assessment and an LOE estimate. We are also planning to release a white paper, describing some architectural best practices and implementation strategies for migration.

Tools and assets such as these are intended to ease the pain of migration, rather than facilitate the migration itself. There is no simple and definitive upgrade path for OW customers, and it is misleading to suggest otherwise.

From a technical perspective, most OW functions now have functional equivalents in OIM, even if the nomenclature isn't always the same. There are notable differences, of course, such as in OIM's role capabilities; the advanced role features available to OW customers are now effectively divided between OIM and OIA. OIM's BPEL workflow engine will be alien to OW engineers, although it is far superior. Active Sync, which is one of OW's most commonly used features, does not have a direct equivalent in OIM, and of course all of those XPRESS forms and rule libraries will have to be completely rewritten. Furthermore, OW engineers making the shift to OIM will have to familiarize themselves with terms such as Generic Technology Connector, Adapter Factory, Trusted Source/Trusted Target Reconciliation, Lookup Definition and User Defined Field. Make no mistake, OW and OIM are fundamentally different products, even though they offer similar capabilities.

Skills learned in the OW world are not easily transferrable to OIM, implying a steep learning curve for OW engineers, who will have to forget many of the concepts they have long taken for granted. But change is inherent to the nature of I.T., and any technology professional worth their salt should be salivating at the opportunity to evolve their skills.

So where does all this leave customers, especially in an era of increasingly constrained budgets? In some cases, they have chosen to stay the course with OW and merely run down the clock (perhaps hoping that Oracle will have a change of heart and either provide indefinite support or decide to release OW to the open source community). Some customers have decided that the effort required of an OIM upgrade warrants a reevaluation of their IdM product strategy. And of course, some customers are biting the bullet and preparing to upgrade. Every organization is faced with different challenges; budgetary considerations, infrastructure demands, resource constraints, vendor relationships, compliance mandates and political in-fighting. Thus upgrading from OW to OIM is not always a no-brainer for IAM technology owners, especially given the vast differences between the two products. As somebody who spent more than a decade as an IAM customer and led numerous RFPs, I completely understand how these decisions are made, and the arcane considerations that frequently inform them.

On a strictly personal note, I am sad to see the end of OW. It was, and still is, an outstanding product and I have many great memories (and more than a few not-so-great ones) of implementing it. The sense of triumph from building my first custom adapter, the initial frustration and eventual mastery of my very first approval workflow, the sleepless nights wrestling with the mysteries of XPRESS form handlers, the patient experimentation with undocumented APIs, and the sense of relief following the success of my very first production deployment. But those days are behind us now, and let's face it, we all have a tendency to view the past through rose-tinted glasses (which is probably why my iPod is crammed with 80s music that I tend to remember being much better than it actually was).

I have no idea whether Oracle will have a change of heart on OW support, although given the scale and complexity of many OW deployments, I have a hard time believing that all OW customers will have migrated by the end of 2014 (hell, there are still production deployments of Sun Identity Manager 5.0 out there). But for a frame of reference, consider how long it has taken organizations to migrate away from JD Edwards. It is nearly ten years since PeopleSoft acquired JDE, and six years since Oracle's acquisition of PeopleSoft, yet JDE continues to thrive under the Oracle umbrella and will be supported indefinitely.

Something tells me we haven't seen the last of Sun Identity Man.... I mean, Oracle Waveset.... by a very long shot.