Welcome to the sixth post of my series in response to Ian Glazer’s video on killing IAM in order to save it (AKA my Russian novel on identity, security, and context). We’ve looked at a lot of the issues surrounding identity today, and if you’ve been following along, my perspective on how to solve these issues is probably pretty clear by now. We at Radiant feel strongly that you need to federate your identity layer, just as we’ve all been busy federating access. But what does that look like? Here’s how the VDS, our RadiantOne virtualization engine, implements a federated identity service—we’ll be focusing on the highlighted part of this diagram today:

The common abstraction, data modeling, and mapping serve as the “backplane” for the whole system. As we see in the leftmost section of the diagram above, the system starts with the existing identity sources and transforms this identity data through three higher-level services built on top of the VDS virtualization layer.

First, the “aggregation” service regroups the different identity sources side by side. In directory talk, this is like “mounting” each different identity source into its own separated branch. Here, we don’t try to merge the different identities, we regroup them under a common virtual root, while keeping each namespace separated. Metaphorically, it’s like people putting different objects (identity sources) into a common bag (the “virtual directory”). The main advantage of this structure is that it allows you to send a global search, from the root to the top of the tree, to find an identity that can be defined in one (or more) aggregated identity sources.

Then, the “correlation” service determines if there are any commonalities across those different identity sources. Beyond the local/specific identifier for a given identity, the service discovers any correlation based on attributes and rules that can disambiguate an entity—a person or object—from across the different identity sources and representations. From a logical point of view, the correlation service is used to create a union of the different identity sources. The end result is a new identification scheme, where each entity in the system is uniquely—and uniformly—identified by a “global identifier” from across all identity silos. This global identifier does not exist in isolation; it’s also tethered back to each specific local identifier, so we always know where every piece of information lives. After the correlation stage, the entire set of existing identity sources is regrouped into a global namespace, where each identity is totally disambiguated.

Finally, the “integration” service links identities with their attributes for a complete global profile. For any given entity that exists in more than one data source (which we determined via the union operation described above), we can now take advantage of the common link—or global identifier—to “join” different attributes that are specific to each source. Through this join operation, we obtain a global profile out of each local description.

Virtualization + Transformations: The Foundation of SSO and Your Bridge to the Cloud

Not every situation requires all three of these advanced services, but at least one is usually required to ensure that your federated identity contains all the information you need for your specific use case. Once you’ve gone through some or all of these stages, you end up with a “rational” federated image of your heterogeneous system.

And if your main target is to authenticate users and deliver single sign-on, this is where you can call it a day. Such an image of your system makes it easy to identify and check credentials for any given user. All you do is a simple search, followed by an authentication request against the federated system, and you’ve got everything you need: you know if a user is defined in one or more of your identity sources, how to check his or her credentials, and which protocols to use. Once the user found, the virtual layer automatically conducts whatever specific authentication operation is required.

Beyond Credential Checking: Adding Extra Assurance to Authentication

Using our federated identity hub to solve this authentication challenge is a huge win, in and of itself. But for many industries, today’s world demands new layers of assurance—a form of extended authentication, like that second photo ID you have to produce when extra security is required. As service offerings grow more complex and demand greater security, you need different levels of identity assurance, unless you want to fall victim to what Anil John so brilliantly characterized as a “Maginot line of authentication.” His blogpost on identity assurance explained these issues perfectly and I encourage you to read it. For my purposes here, I’m borrowing one of his diagrams.

Here we have the “state” flow for a banking user, along with the requirements in terms of security. Once the credentials have been verified on the left, the other red diamonds indicate decision points where a user wants to access different levels of regulated service—and best security practices call for escalating identity verification. Those additional security challenges provide the right “level of assurance” needed to grant access to increasingly sophisticated services.

As we progress across this activity flow, each step requires more and more information from a user—and this is information that needs to be collected, either at identification/authentication time or as the user goes. So we can see that the authentication process in itself is beginning to demand a richer profile, a set of information that can be progressively disclosed based on a user’s activity. And here’s where the lines between authentication and authorization begin to blur, and where a federated —and context-aware—identity becomes increasingly imperative.

As the need for enhanced security grows, authentication and authorization will form a continuum where information needs to be disclosed and accessed based on context. And now we’ve come to my very favorite topic. Although RadiantOne does a great many important things, the system is at its best when it’s discovering context from across disparate sources to drive deeper security decisions—and build richer relationships with customers. My next blogpost will dive deep into how context works in a federated identity system, then we’ll finish up the series with a closer look at the other half of the security puzzle: authorization and provisioning.

Thanks again for reading, and stay tuned for Michel’s primer on context.