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.

The Dirty Secret of Identity Management - Part 2

Yesterday, I wrote about an alternative implementation strategy for identity management projects that maximizes the likelihood of success by emphasizing access governance rather than provisioning. Today, I'd like to explore this concept in greater detail.

Consider the classic approach to a provisioning-centric identity management project. A first phase may involve standing up the foundational infrastructure and seeding users from an authoritative source such as an HR system. A second phase performs automated provisioning of these users into Active Directory. A third phase extends this same functionality to an enterprise directory, and so on, and so on.

This approach encourages the notion of vertical identity management silos, each of which has to be conquered independently of the others, as illustrated here.

Figure 1: Classic Provisioning Approach

Within each of these silos, several things need to happen before automated provisioning becomes possible. Prerequisites typically include account discovery and correlation, data analysis and cleansing, and business process architecture. Accordingly, it can take a large enterprise several months to implement user provisioning for even a single resource. When an organization has potentially hundreds of systems that need to be managed, it becomes obvious why the failure rate for provisioning projects is so high.

Intuitively, one might think that after user provisioning has been implemented for the first resource, subsequent phases should become easier. After all, by this point the internal team is more comfortable with the technology and has gained valuable experience. Unfortunately, the opposite tends to happen. The problem with the siloed approach is that it precludes a holistic view of identity. It is therefore common for IAM architects to make false assumptions in early phases about how identity data will be persisted throughout the organization, only to have those assumptions shattered later on when attempting to manage a resource that has unusual (and previously undocumented) requirements. This inevitably requires rework and regression testing of processes that have already been implemented. I have yet to see an identity project where this didn't happen.

In summary, the classic silo approach so common in user provisioning projects is a recipe for budget overruns, extended timelines, complex configurations, inconsistent business logic and worst of all, failure to extend identity management to all critical systems.

A Governance-Centric Approach


Given the relatively low ROI and the high failure rate for provisioning-centric IAM projects, it is clear that a different approach is necessary. This is not to say that automated provisioning is unnecessary or even undesirable, but it should be viewed as just one piece of the identity management puzzle.

A governance-centric implementation strategy takes a horizontal, and therefore a more holistic approach to identity management, as illustrated here:

Figure 2: Governance-Centric Identity Management

Compare this to the traditional approach illustrated in Figure 1, and it should all begin to make sense. Instead of aligning project phases to vertical identity silos, the governance-based approach introduces the various functions of an identity management solution in a horizontal manner.

Phase one is now focused on the seeding, discovery and correlation of accounts for all relevant systems. Obviously, there is still a requirement to stand up the base infrastructure and seed user identities from an authoritative source, but beyond that, the goal of phase one is to build an aggregate view of identity data, providing visibility into who has access to what. This is achieved by implementing read-only connectors that go out to each resource, discover accounts and correlate them to identities where possible. There is no end-user functionality, no provisioning and thus no risk to the integrity of existing processes or data.

With this approach, it should be possible in most cases to create an aggregate view of access privileges within days or weeks, depending on how many resources are being queried. The discovery and correlation process for each resource will immediately be able to identify any orphaned or rogue accounts, in addition to data inconsistencies. These can be flagged for remediation as part of the data clean-up exercise that is essential to the success of subsequent project phases.

Once the aggregate view has been created, it immediately becomes possible to centralize and automate access recertification requests and compliance reports, perform role mining and analytics, and even to start introducing detective policy enforcement at the enterprise level. By any standard, these are all significant benefits for a phase one release. Furthermore, a horizontal approach promotes a more holistic view of identity, which helps to prevent the proliferation of resource-specific policies, processes and configurations. From the beginning, policies are implemented globally.

By the end of phase one, connectors are live for all critical target resources and identity data has been validated and cleansed. It therefore becomes possible to approach subsequent phases with a much higher degree of confidence and certainty than it would with a "one resource at a time" approach.

Phase two involves layering repeatable, generic business processes on top of what has been built thus far. Such workflows will typically encapsulate identity lifecycle events (new hire, transfer, terminate, etc...) and access request/approval processes. Again, the goal here is to define processes that are generic and reusable enough that they can be implemented globally. Business process workflows should be specialized only by the metadata with which they are populated at runtime. For example, consider an access request/approval pattern. In any organization, there are normally no more than a tiny handful of "types" of approval pattern (i.e. Manager Only, Synchronous, Asyncronous, and so on...) While each resource may require the requester or approver to provide resource-specific data, even the forms used to collect that data can be dynamically created at runtime by passing arguments into a workflow.

Once business processes have been defined as workflows, end users, managers and designated approvers can begin to use the identity management system to initiate and approve access requests. On the back-end of each process, a ticket or email can be generated to the "provisioner", who simply has to grant the desired privilege. Keeping human provisioners engaged is a useful mechanism for heading off any operational issues that may result from the introduction of new business processes. Based on their feedback, processes can be further refined to satisfy business requirements without impacting the data on any resource.

By the end of phase two, we have seeded all our accounts, deployed connectors into all target systems, created a global reporting capability, defined a unified view of access privileges and introduced centralized/streamlined business processes. Again, the benefits from phase two are significant; for one thing, centralized business processes offer greater enhanced auditing capabilities, but just as important, it begins to establish identity management as part of the corporate culture.

Which brings us to phase three. Now that the data is clean and new business processes have been introduced, existing read-only connectors can simply be write-enabled in order to start provisioning. This should be done on a resource-by-resource basis. But without the overhead of reconciliation, correlation and data cleansing for each resource, that should be a relatively trivial exercise compared to the effort of deploying provisioning connectors using the classic project approach. If workflows have been designed correctly (naturally, this depends to some extent on the identity product being used), making the switch from manual to "last mile" user provisioning should involve little more than a configuration change.

So there you have it; a holistic, governance-based strategy for implementation of an Identity Management solution. As I noted in my previous comments on this topic, the governance-centric approach is not dependent on any particular brand of identity management tool, as all of the major commercial offerings have the ability to deploy read-only connectors, correlate and define loosely-coupled workflows. In fact, the only obstacle is the willingness of IAM practitioners to think differently.

The Evolution of IAM: From Gate Keeping to Corporate Governance

Back when I was a young ankle biter taking my first tentative steps into the world of Identity and Access Management, it didn't even have a name. Admittedly, that was less than 15 years ago, but given how much IAM has matured in that time, it seems like much longer.

In those days, core IAM services such as credential management, entitlements management, user provisioning, access certification and directory integration were viewed very much as low-level, highly tactical I.T. functions. Use cases were generally simple in nature ("I need an account on System A, so I'll call my friend Mary on the helpdesk to give me an ID and password that I'll never need to change"). Regulatory mandates were less stringent, identity theft was less widespread, and very few enterprise applications were web-enabled. In fact, one of my very first identity projects in the 1990s involved devising a Web SSO solution for legacy host applications that were in the process of being "webified" (believe me, you don't want to know how I got there, but let's just say that it involved some pretty creative CGI scripting).

The first generation of identity services (I'll broadly categorize them under the heading IAM 1.0) focused primarily on basic credential management that emphasized the need to prevent unauthorized users from accessing protected information assets but added very little business value. Typically, user accounts were provisioned by standing up a directory and writing some scripts to provide basic automation. It was not uncommon for organizations to stand up unique directories for every application. In those Wild West days, I.T. departments generally did whatever they wanted, with little regard for governance or operational efficiency. Predictably, this led to the proliferation of directories and passwords, not to mention rogue accounts. To compound matters, entitlements were assigned in a cumulative fashion; very few organizations had developed the processes or tools that allowed for revocation of entitlements upon a job change.

Several vendors released tools that aimed to help organizations deal with these challenges. IAM 1.0 products were largely pure-play offerings; for example, metadirectories such as Microsoft MIIS and IBM Tivoli Directory Integrator, and web single sign-on suites such as Netegrity SiteMinder and Oblix CoreID. Yet few if any vendors offered any coherent vision for IAM, since it was still viewed very much as a back office I.T. function rather than a business enabler. Best practices were virtually non-existent, and standards such as SAML, SPML and XACML were still several years from adoption. Hence, IAM 1.0 offerings tended to adopt a highly operational focus and didn't always play nicely with other tools in the enterprise.

We can date the birth of IAM 2.0 to about the mid-2000s. By that time, it had become apparent to many organizations that manual user provisioning processes were incurring significant costs in terms of operational overhead and lost productivity. Meanwhile, regulatory mandates were becoming increasingly stringent, placing additional burden on I.T. departments. This led to the emergence of complex identity suites such as Thor Xellerate (later Oracle Identity Manager) and Waveset Lighthouse (Sun Identity Manager) that emphasized user provisioning automation but were frequently expensive to implement, difficult to maintain, and often failed to deliver promised benefits due to the continued focus on IAM as an I.T. "tool" rather than as a corporate governance asset.

This almost singular focus on user provisioning, as I noted yesterday, resulted in IAM implementations that frequently ran over budget and were in many cases poorly conceived due to inadequate governance and the lack of widely accepted best practices. The TCO of these solutions was further inflated by the extensive training and highly specialized skills that were required to implement and maintain them. There was a widespread misconception—encouraged in no small part by product vendors themselves—that an identity management suite was a silver bullet that would solve world hunger; all you had to do was install it (if only that were true).

To this day, many organizations still bear the scars from IAM 2.0 projects that were expensive failures, so it isn't unsurprising that the notion of "identity management" is still treated with derision in some I.T. departments.

Nevertheless, we've come a long way in the past few years. The lessons learned from those early failures have informed a set of widely accepted best practices, and identity management offerings are beginning to reflect this maturation. Accordingly, the percentage of unsuccessful IAM projects has fallen dramatically in recent years.

Meanwhile, the notion of identity management itself has evolved out of the I.T. back office and into the boardroom. This is in no small part due to an explosion in the number of high profile and expensive breaches (like this one, and this one) resulting from inadequate controls. The enterprise also has to contend with the proliferation of cloud computing, mobile devices, the increasing use of external consultants, and remote workforces. All of these factors increase the urgency for organizations to embrace a holistic IAM strategy.

IAM 3.0 reflects both the maturation that comes with experience and the evolving demands of a technology landscape that has experienced radical change over the past several years. In fact, the term "identity management" is itself becoming somewhat anachronistic, as it no longer truly reflects the challenges with which organizations are faced. Identity governance is a far more appropriate term, and next generation IAM offerings such as SailPoint IdentityIQ increasingly reflect this paradigm shift. Such offerings place less emphasis on traditional IAM functions such as user provisioning and credential management, but focus more on GRC, reporting, identity analytics and centralized policy enforcement. From a technology perspective, customers are increasingly demanding streamlined, scalable solutions that emphasize ease of implementation, particularly in an era of constrained budgets. The days of vast, intrusive and complex identity suites are over.

Identity federation, directory virtualization, RBAC, ABAC, contextual authorization and next-generation entitlements management all form part of the IAM 3.0 picture. Automated user provisioning is still important, but is no longer the dominant consideration it once was. In order to become more business relevant and thus more achievable, provisioning needs to be considered in the context of a holistic identity lifecycle, which requires IAM practitioners to adopt a change of mindset.

Personally, I'm excited by the changes we're seeing in the IAM landscape right now. Many of them are long overdue, but change is always painful and I suspect that there will be many in the community who cling onto the old way of doing things. That is unfortunate, but an inevitable fact of life in this business.

The Dirty Secret of Identity Management

When engaging with a customer, I like to begin by asking them a simple question: What is the first thing you think of when you hear the term Identity Management? In nine out of ten cases, they will mention user provisioning. Yes, we all love the idea of automated user provisioning. Provisioning rocks. In fact, provisioning is arguably the most prominent driver for most identity management projects.

There is one small problem, and it is a problem that most IAM practitioners are often terrified to admit. Provisioning projects are rarely successful. By which I mean that they generally fail to deliver promised benefits. Based on my own experience and that of other IAM professionals with whom I've discussed this topic, it is extremely rare for an organization to implement automated provisioning for more than 20% of all systems, regardless of what identity management product they are using. This isn't because commercial identity suites are technically inadequate, or even because organizational bottlenecks prevent the introduction of automated provisioning processes. It is because ultimately, provisioning is only a relatively minor element of a comprehensive IAM strategy, and practitioners have a tendency to overstate its importance. I've seen numerous cases where IAM project leads have focused on universal provisioning like Captain Ahab pursuing a whale, and their refusal to acknowledge that identity management involves much more than the mere deployment of provisioning connectors and workflows can lead to catastrophic project failure.

In the abstract, the expected benefits of automated provisioning make perfect sense. Operational efficiencies, reduced labor costs and faster onboarding are all legitimate metrics for an identity management ROI. But as identity management has matured, it has become increasingly apparent that provisioning is perhaps not quite as important as many practitioners once thought, and there is a compelling case to be made that identity governance has emerged as a more critical factor in the success of IAM projects.

To demonstrate this, let's begin by decomposing the various phases of a typical identity provisioning lifecycle:

• Aggregation: Core identity data is seeded from an authoritative source such as an HR system or contractor database.
• Reconciliation/Correlation: Existing accounts on target systems are discovered and inspected, and identities are linked to accounts on target systems using correlation rules.
• Request: The user requests an entitlement on the target system. Alternatively, a request can be initiated by manual or birthright assignment of a role.
• Approval: A designated individual approves or rejects the request.
• Provision: The user is granted an entitlement on the target system.

When one considers identity lifecycle in these terms, it puts the importance of provisioning into stark perspective. Let's think about it another way. If we remove provisioning from the above lifecycle and just focused on the first four phases, would the ROI for identity management be significantly reduced? Think about how much easier it would be to deploy an identity management solution if provisioning were not a factor. I'll come back to this momentarily.

From a purely technical perspective, automated provisioning isn't terribly complex. Most commercial identity solutions ship with provisioning connectors for the vast majority of common enterprise systems and provide frameworks that enable the rapid development of connectors for custom applications. So why is automated provisioning so difficult to implement? The most common factor is poor data quality in target systems. This creates the risk of corrupting existing entitlements data when the provisioning system attempts to compensate for inconsistencies. Another reason is that system owners refuse to allow a provisioning system to touch their data. These two factors alone can create enormous bottlenecks for a provisioning-centric identity management project. Not to mention that some manual business processes, particularly in the Approval-Provision stage, can be extremely difficult to automate since they may require some discretionary judgment on the part of the provisioner. Such actions are not always possible to replace with automated logic, at least not in the short term.

It may sound like I'm contradicting my earlier statement that organizational bottlenecks are less significant than inadequate corporate governance in the failure of provisioning projects, but a robust governance framework—at the core of which is a holistic IAM strategy—is essential to avoid such bottlenecks from arising in the first place.

When considering the TCO of manual provisioning processes, labor costs tend to be relatively low, as there is usually minimal effort required of provisioners. Besides which, it is not uncommon to find that provisioners have developed their own automated techniques for assigning entitlements on the back end of the provisioning process. More significant labor costs are typically found in loss of productivity incurred by end users waiting for access requests to be approved, in addition to labor costs incurred by the need to perform manual access recertifications.

With all this in mind, let's return to my earlier question. If we take provisioning completely out of the mix, is there a significant impact on the ROI for identity management?

Consider the identity provisioning lifecycle I described earlier. If we raise it to a higher level of abstraction, we can describe it as follows:

1. Aggregation/Reconciliation/Correlation
2. Request/Approval
3. Provision

If you focus on delivering just the first component in the knowledge that there is absolutely no risk of corrupting existing entitlements data, then it becomes possible to build out a large number of connectors and produce a unified view of entitlements data across the enterprise within a very short timeframe. This also creates the opportunity to perform data cleansing, because the identity management system is aggregating and correlating accounts and flagging any inconsistencies.

In the meantime, you can begin to layer centralized request/approval workflows on top of your identity data, using generic, parameterized workflow templates. If designed properly, workflows can be configured to generate a ticket for the human provisioner once all requisite approvals have been completed. Once the entitlement has been provisioned, the provisioner is required to sign into the identity management system and certify the request as completed. This will be verified by the identity management system during the next periodic reconciliation. Delinquent requests, unmatched/orphaned accounts and unapproved entitlements are discovered and flagged for review as part of the reconciliation process.

Finally, once you have analyzed and cleansed your data and the organization has become comfortable with the notion of a centralized identity management platform, you can begin to selectively enable automated provisioning and take human provisioners out of the loop. It still may not be possible to do this for every system, but by this point, the benefits already delivered by the identity management project will have compensated for this. If the request/approval workflows have been designed correctly, then making the switch from manual to automated provisioning should merely involve a configuration change, regardless of what identity product is being used.

Adopting this approach allows you to achieve rapid benefits by providing a unified, enterprise view of who has access to what within a very short space of time, perhaps even within days or weeks. Once you have created this level of visibility into privileges across the enterprise, it is relatively trivial to centralize and automate access recertifications, enable advanced compliance reporting and even begin the process of role analytics.

To the best of my knowledge, SailPoint is currently the only IAM/IAG vendor to have embraced the methodology I just described. They refer to automation as "last mile provisioning", and the architecture of their flagship IdentityIQ product effectively promotes a loosely coupled relationship between provisioning connectors and the core identity governance engine. SailPoint has been enormously successful in proving the efficacy of this approach. Yet in theory, there is nothing to prevent any commercial identity management solution from being deployed in this manner, providing that connectors are configured in read-only mode.

The "last mile" methodology focuses on horizontal rather than vertical introduction of identity services to the enterprise. By reducing the emphasis on automated provisioning in favor of identity governance, it clearly maximizes the chances of a successful implementation without significant impact on ROI.