Identity at the Center: Why You Need a Federated Identity Hub

When I talk about bringing identity back to IAM, I do not mean just to the periphery. At Radiant Logic, we believe identity should be right at the center of your organization. That’s right…It’s time for the hub discussion. 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.

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. We should 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 and evokes the “meta” part of metadirectory, while providing a more agile “directory”. That’s where virtualization comes in.

The Radiant Logic 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. The 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.

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.

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 simply delegate and proxy back to the different stores like the most commonly sold form of the classical virtual directory. We 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”. We believe 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). 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. 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:

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

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 (if so, I’d like to hire your data entry team!), what happens when you have name collision?

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 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

Michel Prompt

Founder and CEO, Radiant Logic

Michel is a world-renowned developer, researcher, and entrepreneur. Prior to founding Radiant Logic in 1995, Prompt served as Senior Vice President of Client/Server Technology at Knowledgeware, now known as Sterling Software. In 1986, Prompt founded Matesys SA in France, a company dedicated to providing services and database support. Matesys introduced the first “file-manager,” duplicating the “Apple Macintosh finder” under Windows 2.1 and sold 500,000 copies to IBM for academic bundles. Prompt founded Matesys Corp., in the U.S., in 1991, becoming one of the pioneer companies in client/server technology. Matesys introduced one of the first visual programming tools under Windows 3.0 for the client/server market (Object View). Prompt successfully sold the company to Knowledgeware in 1993.

Prior to Matesys, Prompt was a core developer in the database group of the GCOS 7.0 Operating System for Bull Systems. He also served as a consultant to Cap Sogeti Gemini, one of the largest IT service companies in Europe.  Prompt received his diploma from Institut Politiques de Paris (Political Sciences Institute of Paris). He holds a Masters degree in applied mathematics from Paris Dauphine University and received a diploma of advanced studies in computer science from Paris Dauphine University.