Gartner 2011 Magic Quadrant for IAG: Tight Competition in a Maturing Industry

Gartner has just released its first ever Magic Quadrant for Identity and Access Governance (IAG), and SailPoint appears to have emerged as a narrow victor. Unlike the Forrester Wave for IAG published earlier this year, which showed SailPoint and Aveksa leading the competition by a mile, Gartner has 4 of the 7 evaluated offerings in the top quadrant, with CA on the borderline.

Admittedly, I'm more familiar with SailPoint IdentityIQ and Oracle Identity Analytics than any of the other products featured here. Both are extremely mature, versatile offerings that are simple to deploy and provide a full range of access governance capabilities, including role analytics, detective/preventative policy enforcement and certification/remediation. From a pure governance perspective, there isn't much to choose between them.

SailPoint's acquisition of BMC's identity management offering and their incorporation of BMC's provisioning engine into IdentityIQ means that they are no longer a pure play IAG vendor, and can compete on equal terms in the IAM space with the likes of IBM, Oracle, CA and Microsoft. In recent months, SailPoint has also been adding provisioning capabilities to their extensive range of native governance connectors, which ship with the product. Of course, OIA also offers provisioning capabilities, but only when integrated with OIM or another supported provisioning product.

As I've noted before, the maturation of identity management is driving a trend away from bottom-up identity administration tools, towards more holistic, governance-based solutions. Visionaries such as SailPoint have long anticipated this evolution and are ideally positioned to take advantage of it as organizations become more sophisticated in how they approach identity governance.

The decision by both Forrester and Gartner to begin publishing IAG market analytics in 2011 acknowledges the increasing maturity of IAG. The explosive growth being experienced by Aveksa and SailPoint offers further validation, if any were needed, of this trend.

The question is, what does this mean for identity management practitioners?

Well, as one might expect, there is good news and bad news. The bad news is that it is no longer sufficient to be a technical whizz who can develop advanced customizations, custom connectors and sophisticated workflows in their product of choice. As IAM/IAG offerings become easier to deploy, offer richer, more business-friendly functionality, and adopt a less I.T.-centric approach, I expect the demand for advanced technical customizations to diminish. The good news is that the increasing maturity of these offerings will allow identity management professionals to spend less time focusing on arcane technical integrations and more time devising robust, governance-centric solutions for customers.

I'm not saying that the market for identity administration tools will go away. Of course it won't; there will always be a demand for automated provisioning. But identity administration is becoming more commoditized, and over time I expect it to be increasingly viewed as just one component of a more holistic IAG framework. Just because the tools are becoming more sophisticated doesn't mean that the operational challenges that create a need for streamlined identity administration are going away.

The real implication is that IAM/IAG solutions are evolving from mere I.T. tools into corporate governance suites, which in turn suggests that the target audience for such offerings is increasingly likely to be a CTO, CISO or CIO than the Manager of Enterprise Applications. For identity management professionals, this means that the ability to articulate business value to a non-technical audience, deliver policy-driven solutions and demonstrate a sophisticated awareness of the regulatory landscape will become just as important as the ability to create a kick-ass workflow. Individuals with that balance of soft and hard skills are difficult to find, and will therefore remain in extremely high demand.

Which, in my opinion, is exactly how it should be.

Is SPML Really Dead?

Over the past year or two, there has been an intense debate in the IAM community about the future viability of SPML. This began with a blog post by Burton Group's Mark Diodati in February 2010, in which he offered a bearish perspective on the poorly adopted provisioning standard.

I agree with many of the points Mark raised. Yes, SPML is too complex in its current incarnation. In trying to offer a broad range of functionality and account for every conceivable provisioning scenario, it often ends up accomplishing quite the opposite. Accordingly, SPML implementations tend to be extremely product specific, which defeats the entire purpose of a common standard in the first place. He is also correct that SPML implementations often cause performance issues due to the burden they place on connectors, although I would argue that this is less attributable to the standard itself than to how SPML has been implemented by provisioning vendors. And I completely agree with his assertion that enhancing the standard with a common inetorgperson-like user schema such as "SPMLPerson" would not only promote greater convergence with SAML, but would lead to increased adoption in the enterprise.

With that said, SPML works extremely well when implementations avoid connector-heavy and product-specific customizations (I'll come back to that shortly). In my opinion, the lack of SPML adoption isn't just because the standard itself is deficient, but because nobody has quite figured out the best way to implement SPML interfaces.

The most common use case I've encountered for SPML is when a customer wants to integrate their own proprietary UI with a commercial provisioning system. For instance, one of my customers has a sophisticated, AJAX-enabled access request portal built in .NET. It provides all the workflow functionality that one would expect to find in a commercial provisioning system, but was designed simply to manage requests and approvals rather than to automate provisioning. The customer had acquired Sun Identity Manager for provisioning automation, but didn't want to replace their elaborate, business friendly .NET interface with SIM's antiquated UI (and who can blame them?) In this particular instance, SPML was the obvious solution. The .NET application was modified to simply fire off SPML requests to SIM on the backend, thus automating provisioning actions while protecting end users from any visible impact.

In scenarios such as this, where a homegrown access request portal needs to integrate with a provisioning system, SPML works like a charm. But let's face it, this scenario doesn't require SPML specifically. In the use case I just described, Sun Identity Manager could have exposed any old SOAP or REST interface, and the integration would have been exactly the same, providing that the interface exposed the requisite methods.

The true value of a standard such as SPML is realized when providing interoperability with enterprise or cloud applications, and this is where SPML has unequivocally failed to deliver.

Which brings us back to the problem with SPML implementations. Because the standard is so broad and, unlike SAML, fails to define even a minimal schema for user profiles---much less offer a reference implementation---identity vendors have tended to implement variations of SPML that are product specific and are tightly coupled with the connector layer and underlying data stores. The result is that most SPML implementations are ugly and XML-heavy, which in turn can lead to performance issues when performing large numbers of provisioning transactions.

I have yet to see an SaaS application that supports inbound SPML messages in a way that could be called "standard". Likewise, I have yet to see a user provisioning solution that supports SPML in a non-proprietary fashion. As a result, provisioning solutions for cloud applications still depend heavily on individual connectors that all implement different product APIs, which is to say that SaaS applications are currently treated no differently from any other kind of application.

So the question remains, is SPML really dead? Well, in its current incarnation, it's hard to argue that it was ever really alive to begin with. SPML 2.0 is now five years old, and the OASIS Provisioning Services Technical Committee hasn't convened since 2008. But the critical need for interoperable provisioning is now greater than ever, particularly considering the explosive adoption of cloud applications in recent years. The fact that most identity management RFPs include a requirement for SPML confirms that standards-based integration remains a critical priority for organizations. Even as IAM maturation drives us away from traditional user-centric IAM towards more business-centric models, identity management projects still spend far too much time focusing on provisioning, and specifically on the nuances of proprietary connector architectures; this is another argument for a widely adopted provisioning standard that abstracts the complexity of underlying systems and data stores.

If SPML is to survive, then it will have to be reincarnated without any consideration to backwards compatibility. For that to happen, a major player in the identity space (I'm talking about the likes of Oracle, CA or IBM here) needs to step up, take leadership and create some momentum for a new standard.

In the meantime, there are several proposals out there to compensate for the lack of momentum surrounding SPML and the critical needs that it was intended to address. Jim McGovern, never a shrinking violet, has a wish list for what he would expect to see from SPML 3.0, if it ever happens. In 2009, the visionary Nishant Kaushik proposed using OAuth to support federated provisioning needs. The SimpleCloud (SCIM) initiative----which enjoys participation from various cloud providers such as Google, Salesforce as well as identity vendors such as UnboundID and SailPoint----appears to have embraced this concept and taken it to another level. For my money, SCIM is the most promising candidate for a new provisioning standard. Seemingly inspired by the LDAP standard, SCIM also leverages SAML, OAuth 2.0 bearer tokens, OpenID and JWT, while favoring a REST API over less efficient SOAP.

In summary, I tend to agree with Mark Diodati that SPML in its current form is obsolete, but the need for an interoperability standard is now greater than ever. Two lingering questions remain. Will SCIM be the standard we've been waiting for, and what is the value proposition that will compel vendors to embrace it?

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

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.