Welcome back to part three in my latest blog series about bringing identity back to IAM. And when I say bringing identity back, I do not mean just to the periphery—at Radiant, we believe identity should be right at the center of your organization. That’s right, it’s time for the hub discussion. Now, we’ve had this talk a time or two (or ten), looking at the idea that the complexity in today’s infrastructures demands a sort of logical center, a place where identities can be federated, rationalized, and transformed according to the unique requirements of each service provider or application.

If you remember my last post, we looked at metadirectories as our last attempt to centralize identities—and we know how well that went. (It was the same story for the older ”enterprise directory,” as well.) But what if we could keep the idea of a central identity, while achieving this “logical” centralization in a more flexible way—one that respects the role of the silos as masters of their domain? A way that evokes the “meta” part of “metadirectory,” while providing a more agile “directory” part?

And that’s where virtualization comes in.

The Radiant Mantra: Manage Globally, Act Locally

Virtualization is the logical part of “logical center” I mentioned above, and it’s how we can create a smart hub that’s based on the cooperation of the periphery. This idea evokes the exact sense of the word “federation”—federate the work, giving each actor its own role to play.

At the center of such a system is a virtualization engine, busy pulling information from your heterogeneous backends and making that data ready to meet the needs of your applications or service providers, whether they’re in-house, on the web, or in the cloud.

The first step in this “active summarization” is to create a reference table of all identifiers, the “golden list” of all your identities out of many disparate data representations. Once the list is complete, your federated identity hub can produce the new—and many times different—views of identity that your applications need. That’s the “manage globally” part of the mantra.

Now when a request comes from any service provider—to check a user’s credentials at login, for instance—that task can also be delegated back to the correct authoritative local store, thanks to this global reference table. After all, we may complain about identity silos, but they’re not just silos, they’re application specialists, designed to do exactly what they do very well. So their “views” are essential to user authentication and need to be preserved—just think about the role of Active Directory in this food chain. This is the “act locally” part of the equation, and taken together, these actions give you an identity infrastructure that’s truly designed for federation.

But let’s take a closer look at how we got to this idea of “manage globally, act locally.”

The Rosetta Stone of ID: Global Integration Backed by Local Ownership

I’ve made a bold claim: that we need to respect both the global and local views, that it’s not enough to merely pull things into the center like the metadirectory, or to simply delegate and proxy back to the different stores like the most commonly sold form of the “classical” virtual directory. We really need a way to do both. We need to synthesize all user data into a reconciled global list of users but built on top of what already exists, and will continue to exist, because it covers some very specific aspects of identity that we need.

If we can agree on this, then the requirement for a dictionary of identifiers—a “Rosetta Stone” that maps a global identity into its specific application representation and makes it easy to look things up—becomes clear. Of course, life would be easier if we were all operating according to a set of predefined “generic” global identifiers, defined at the start of all processes. But the reality is that we’re dealing with different applications adopted at different times from different vendors—each speaking a different language and checking credentials in a different way. They don’t even agree on the basic building block of identity, the identifier!

But don’t feel bad, we’re all in the same boat—even Pyongyang probably has tons of diversity and duplication in its monolithic identity system, with no common global identifiers. So if you cannot impose a common identifier upon each application, then you have to establish this correlation after the fact. That’s what we call a “federated identity system.” And yes, we believe that the accelerated deployment of federation will require such a change at the level of the identity structure. If any sizeable enterprise wants to manage their users and access the cloud, then the structure of an IdP will require a federated identity system (whether it’s hosted in-house or on the cloud only matters in terms of your particular deployment). I believe that such a federated identity system, acting as a consolidated view of your identity, is the exact technical characterization of the function than eluded the so-called “meta”directory.

The Hook-Up on Look-Ups: Remapping Identifiers Inside the Hub

By mapping each identifier, each “global” identity in the Federated ID system has its corresponding translation in a specific silo. So when you look up that individual, you’re able to use the correct identifier of a user for each given application. So my global identifier might be “Michel,” but I am also known as:

Michel = Mike in A = Michael in B = MPrompt in C

That’s the first function of the hub, establishing that there’s an individual called “Michel” who’s common across systems, but also known by other names.

A Global List from Multiple Systems

A Global List from Multiple Systems

This correlation table is the start of being able to link all the information about a given individual—and it’s no mean feat to pull all this together. Even assuming you have no data quality issues in your system (and if so, I’d like to hire your data entry team!), what happens when you have name collision?

Why You Need Identity Correlation

Why You Need Identity Correlation

Using the social security number or something similar only works if the application supports an additional attribute for identification based on SSN. The only thing you know for certain is that each application will create a unique identifier for each person—or reject it during registration. But unicity in one app does not mean that it’s the same identifier we used across apps. Generally, this is fine because most applications are closed worlds for most functions, except for people (and a few objects like products), whose scope and activity span more than one application. Remember: Identity is the center of your activity because people are always at the center.

Building a Global Virtual Identifier to Enable a Global Virtual Registry

Building a Global Virtual Identifier to Enable a Global Virtual Registry

Thanks for reading and I’ll see you back here for Part 4! Have a great Thanksgiving next week for all my US readers…

A postscript on provisioning: Be sure to check out Paul Moore’s excellent post on the Centrify Express Community blog, Clarifying Cloud Identity. It’s called “Why is User Provisioning So Hard? Doesn’t SCIM Fix It?” and makes some great points about the difficulty of provisioning to many of the big players in the SaaS and cloud realm. He’s right—administrators want everything to happen automatically, but those of us with our hands in the code understand how much effort it takes to make the magic happen.