I’ve been blogging on Gartner analyst Ian Glazer’s recent video on whether we need to kill IdM in order to save it. It seems appropriate to begin these with words of Martin Kuppinger, in response to the Glazer video and my first post on this topic:

…. I believe in approaches that build on existing investments. IAM has to change, no doubt about that. But there will still be a lot of “old school” IAM together with the “new school” parts. Time and time again it has been proven that change without a migration path is an invitation to disaster. Embrace and extend is the classical migration methodology for classical technical transformative strategies.

Anyone who’s been following along understands that Martin echoes my perspective here—I am all about taking what still works and making it work better. So before we dive into the global picture about what is dysfunctional with current IdM deployments amid the clamor for access (SSO and cloud), access rights (authorization), and governance, I want to share some final thoughts on identity representation and storage.

SQL and LDAP: Strengths and Weaknesses

As I mentioned in my most recent post, if we’re focusing only on finding the most flexible, non-redundant, easy-to-maintain system to represent and record identity (and information in general), it’s tough to beat the relational model. And as a result, the majority of our applications are based on SQL, which means the largest chunk of key identity information is also managed by SQL.

While it’s one thing to accurately capture information, however, querying and retrieving this data is another story. Fast lookups—especially those involving some form of contextual navigation and link-hopping—require a lot of “joins.” And joins are a very slow and expensive operation with SQL, because each join means a “multiplication of links” between objects. So after two or three hops, you have exponential growth of your database operations—and even on the fastest computer in the world, an open and potentially infinite number of operations will take forever.

The key problem with navigating hierarchies or graphs in SQL is that the paths are generated on the fly—and this is precisely where hierarchical or a graph database is strongest. In such tools, the links are hard coded and stored. Because the paths are pre-defined through indexation, you can always pick your starting point and navigate quickly, thanks to these pre-established paths.

And here we have the dilemma: on one hand, we have a system that reflects reality in a faithful, non-redundant way, not only capturing the information about a given object, but also reflecting the relationships around that object. And it can also generate all the paths to and from that object, whether in a graph or a tree. But if there are a lot of relationships—a lot of context surrounding that object—those queries will be slow and, in some cases, with a response time that’s difficult to determine. And that doesn’t work in a world where users expect immediate access to resources.

Or you have a system that’s easy to navigate, once you get the data in—but far from optimal when it comes to write and update. Redundancy is one big challenge, and being able to flexibly modify the structure—deleting or updating a link—is another.

What If: Imagining a World without LDAP

I know LDAP is no longer fashionable: Ian is leading the charge on that, and on many points he is right. LDAP is a kind of lost art; for the younger web 2.0 generation—the JSON/REST crowd—anything that is not based on a browser and HTTP is like Cobol (aka, the dinosaurs). Of course, you have to be careful with fashion and trends, because there’s always a next generation. For instance, the Apps/APIs IOS/Android crowd looks at HTTP and HTML 5.0 as “designed by committee,“ and uncool, to boot.

Let’s imagine for a second, though, that we killed all those LDAP servers and their derivatives. First, many of our portals would stop authenticating and authorizing, and that’s only considering the external users—the “Sun” side of the market. If we ended Active Directory, as well, many of our SharePoint portals would stop in their tracks. I cannot even imagine the state of our internal networks, our enterprise intranets.

And finally there is a lowly function that we cannot just ignore: the email address. Yes, those weird conglomerations that often act as a proxy to your unique identification, your “login.” Most email servers are using LDAP or some form of LDAP for email address lookup. To some extent, the problems with LDAP are a bit like the problems we have with DNS (yet another tricky naming service…). We hate them, but we cannot just kill them—or not that easily. As Steve Jobs used to say, you only know the value of something once you lose it.

Embrace and Extend: The Identity Bridge to Somewhere

As Martin says above, I believe it’s better to embrace and extend, to evolve. So let’s look at how we can use two of the mainstays of our identity infrastructure—SQL and LDAP—and give them new life by bridging them through virtualization and federation. Let SQL record and capture identity and information as it does behind our multiple applications and then “publish” that data in a specialized identity look-up and attribute-oriented store, such as our old friend LDAP. (By the way, this virtualization layer approach would also work going from SQL to graph, if graph databases suddenly replaced LDAP.)

Such a system offers the best of both worlds. Identity management, or the identity representation and storage side, at least, would be reconciled with the rest of the infrastructure: “a part of” and not just “apart,” as Ian said. Before we dive into the analysis of how such a SQL-to-LDAP bridge could be built, I would like to reiterate that this approach— what we call “model-driven virtualization”—is not applicable only to the pair SQL/LDAP. It also works going from “N variation of LDAP” to “canonic LDAP” (such as AD-to-LDAP or Novell-to-LDAP), as well as from application APIs or web services mapped to LDAP (WS-to-LDAP or API-to-LDAP).

So think about the approach I am describing as a typical building block. The idea is to find a systematic approach to building identity bridges, so that we stop building a bridge to nowhere, as in this diagram of a typical fragmented identity infrastructure:

And end up with a rational federated view of identity acting as a hub, as illustrated by this diagram:

This is what we at Radiant call a “federated identity service based on virtualization,” and I look forward to diving into what this means and how it works in my next post…stay tuned!