In my last few blogposts (here, here, and here), we’ve been talking about the best—and easiest!—way to upgrade to ABAC (attribute-based access control), using more flexible group definitions to create smarter authorization policies. And I told you that it’s possible to build these richer groups by leveraging more attributes. So that leaves one essential question—how do we round up all those attributes to build better groups that can drive finer-grained policies? (You will not be surprised to learn that it has to do with federating identities from across diverse sources—but read on, and I’ll explain how all this works…).

As we know, in most organizations, our definition of an identity is stored in some sort of directory infrastructure. And sure, that’s fine if all you’re doing is authenticating users. But authorization is where it gets a little trickier. You’ve heard me say it before: there’s a ton of information about each identity that isn’t part of that basic record. Even if the directory contains the core set of identity attributes for each user, many specific aspects of an identity will be handled by more specialized applications—HR, production, marketing, sales automation, and the like. And getting to all the nuggets that are siloed across these specialized applications is a real identity integration challenge (and that’s our favorite kind of challenge here at Radiant…).

Beyond the Meta/Virtual Paradigm: A Federated Identity Service to Gather Attributes from Disparate Sources

We believe that the solution is not (yet another) centralized uber-directory. The answer is a common coordination effort that’s based around a virtualization layer that creates a federated view of identity out of multiple applications and identity silos. This smart layer normalizes all that disparate data for “curated” views of identity that can be customized for each consuming application. Now, this solution goes way beyond what the market calls a “virtual directory,” although it grew out of that technology. And it’s not a traditional metadirectory, although it centralizes and synchronizes the data in a logical way.

Such a service derives its flexibility from metadata consolidation and remapping, making it easier to manage and deploy. It provides is a consolidated view of your identity, while also adding the ability to delegate security back to the authoritative stores. Basically, it’s the identity counterpart to the federated access made possible by SAML and, we bet in the near future, OpenID Connect and OAuth 2.0. In, short it is the identity infrastructure that enterprises need to access the cloud through those protocols.

So how is this layer implemented? I’m sure some attentive readers are wondering how this works within the realm of directories, metadirectories, and virtual directories. In fact, there is an interesting conversation on this topic going on right now at LinkedIn with Dave Kearns and others, and Radiant will also be hosting a webinar about this soon with Gartner Nick Nikols (although that discussion will center around why you need such a federated identity structure for cloud access and Office 365—be sure to sign up!).

To keep today’s story short (and visual!), we believe that the architecture needed to gather those attributes looks something like the following picture:

RadiantOne - Federated Identity Service Architecture

Of course, an architecture diagram always looks clean and simple. The devil is always in the implementation details.

Why do you need to federate your identity in order to pull and join your attributes? Well, for the simple reason that even if you have only one identity, most of the time you are known by different identifiers in each application or identity silo. So first, before you can extract those attributes, you need one global, normalized view of your identity. (And that isn’t just a baseline requirement for groups or access policies—this ”smart global view” is becoming mandatory for pretty much any security initiative coming down the pike, along with data management, business intelligence, personalized services, and any other buzzword you want to throw onto the list.)

Again, a picture is worth a thousand lines of text—here’s how we help you create a complete list of identities with a union set:

Complete List of Identities

Once you have one global, logical, virtual identity, along with the right integration tools based on virtualization, getting to the groups you want is a whole lot easier. Here are just some of the ways our federated identity systems adds flexibility and helps you solve this equation: more attributes = richer groups = smarter access policies.

You can access complete user profiles and manage groups globally:

Flexibility with Groups

You can define groups based on attributes through our sophisticated join capabilities:

Flexibility in Defining Groups by attributes

You can remap existing groups:

Leveraging/Re-Mapping Existing Groups

And you can define group memberships that change along with your users:

Groups memberships that change with your Users

Want to learn more about how all this works for access control? Check out our recent webinar and get all the details from our tech goddess Lisa Grady. To learn more about why you need a federated identity system, check out this series of blogposts from last fall (see—I am consistent in my madness!), where we explored bringing identity back to IAM, the hidden requirement for federation, and why you need an identity hub.

Thanks for reading!