I ran into Ian Glazer at last week’s Gartner IAM conference. It was an excellent event, and the weather was so cold in London (or perhaps that’s just my inner Californian talking) that the crowd was even more attentive than usual. Although he had places to go and people to see, Ian gave me some quick but very valuable feedback about this blog series in response to his video about killing IAM to save it. His big takeaway was that “it’s not about the storage.”

And I’ve had lots of flight time since then to think about what he said. I’m a “coder” at heart (and you know the old adage: “program first, think later”), so I jumped quickly to the hardcore story about SQL, graph, and LDAP, with lots of good justification for that focus—and you can follow along here, here, and here. But I agree that the drivers, the pain points that are forcing us to re-think identity management as we know it, are the fast adoption of the cloud and its multiple SaaS applications on one side and the unstoppable growth and demand for access through all kinds of mobile devices on the other.

And here I believe is where the analysis from Ian is at its best.

Let’s look at the two main players (beyond the dreaded form-based, name/password authentication) when it comes to federated access to an application that’s delivered on the cloud (or even on the internet). Our best candidates here would be SAML 2.0-based federation and Open-ID Connect/Oauth 2.0. You would find SAML 2.0 in use with most SaaS vendors. And more and more, your web applications, Facebook, Google +, Windows Azure, and others can act as a “trusted identity provider” to allow external users to sign to your application.

I will illustrate the issue by looking at SAML 2.0, but the need for mapping “external identity” to your own internal representation will still exist, even when you trust Facebook.

Federating Access and Federating Identity

One of the main values of a “federation” layer is to funnel authentication requests to an “identity provider” or IdP. In the case of SaaS applications, this redirection points to your company—basically, your enterprise is the IdP.

Once the IDP receives the authentication request, it must:

1. Authenticate the user against some “internal authentication sources,” such as AD, LDAP, or databases.
2. Map the internal identity representation to the external format the SaaS application requires.
3. Encode the authentication token based on the mapping result.
4. Send it back to the SaaS application.

The process is illustrated here:

What Could Go Wrong? The Care and Feeding of Your IdP

This process raises a couple of major challenges. The first challenge is the need for internal authentication and remapping. The first three operations—authentication, mapping, and token creation—need to be done by you, the identity provider. All the SAML layer does is move the token around; all the rest is up to you. So what does this mean for the enterprise-as-identity-provider? In a typical scenario, you would have to map InetOrgperson attributes to a SAML2.0 attribute or a JSON structure. And that can get very complex very quickly.

The second challenge is that there are as many remappings as there are applications. The translation and mapping is based on a given list of token attributes for each application. So the mapping for Google apps has nothing to do with the mapping for SaleForce, etc. Basically, every SaaS application speaks a different “dialect” of SAML—and expects to get that exact language back from the IdP.

The bottom line is that without an authentication hub and application-specific mapping to act as a bridge between your internal and external systems, you still have what I call “Star Wars” syndrome when it comes to authentication—and that’s not the fun part with light sabers or ewoks.

This diagram shows the Star Wars effect happening in today’s identity environments (I sense a disturbance in the infrastructure, Luke):

Now that we’ve established what’s ailing IdM these days, I’ll spend some time on the cure in my next blogpost. Be sure to check back for a look at how a federated identity service solves the “Star Wars” syndrome and lets you leverage your current infrastructure to do some very cool new things (think context-aware applications).