Welcome back—let’s continue where we left off in my last post, looking at bringing identity back to IAM. I was comparing notes on use cases and best practices with Nick Nikols of Gartner recently and came to some conclusions that might appear quite paradoxical—heretical, even!

1. Although federation divides the work between an identity provider (IdP) and a service provider/relying party (SP/RP), this decoupling has not eliminated the need for some form of identity syncing and remapping between the two. While it sounds counter-intuitive, the act of externalizing identity from applications to reduce dependencies still requires some form of coordination and identity management between an identity provider and its relying parties. To really deploy federation, you have to do some identity syncing and provisioning.
2. Then, because this operation has to happen for each identity source and target, medium-to-large organizations acting as IdPs—or hosting their IdP functions as a service—are rediscovering a practical requirement: you need a complete identity hub to simplify the identity orchestration required by the different cloud services (including authentication and authorization, along with provisioning).

Beyond connectors and syncing capabilities, Nick and I were struck by the idea that this requirement for a common hub, this staging engine for identities, whether hosted on premise or in the cloud, reminded us of something…what could it be? You guessed it—it’s the second coming of the meta-directory, back from the (near) dead, or at least a similarly centralized structure that drives your cloud provisioning and access efforts. Now wait, before my wife, my mom, and my dog stops reading this blog, let me assure you: I have not been visited by the ghost of Elvis, even though Halloween was just last week. Before you call me crazy, take a look at this cloud apps slide from the gurus in Redmond, depicting a required architecture for the deployment of Microsoft Office 365.

See, it’s not just the nuts in Novato who see the need… 🙂

Federation Provisioning: Seed the Infrastructure, Keep it in Sync, and Remap on the Fly

Now, there’s a lot here to discuss, but let’s analyze each paradox in its turn, so these posts don’t become War and Peace (or its even longer sequel). For today’s post, we’ll take a look at the idea that federation doesn’t eliminate the need for identity management on the part of the service provider or relying party.

Basically, the IdP converts an internal identity representation into a token, then the SP converts that token and checks it against the internal identity representation. What we’re seeing in the authentication operation is the creation of a token through a remapping/conversion operation on the sender’s side and the finalizing of the authentication through a remapping /conversion operation on the receiver’s end. So a whole lot of remapping and conversion here, and even at the level of authentication, we start to see that the system only works if enough parts of the infrastructure have been seeded with some form of identity list, along with a way to look up identities and map them to the proper format.

Shadow IDs: Why the SP Needs a Corresponding Image of Identity

Of course, when the IdP is authenticating a user against some internal store, the user must first exist in such a store. This seems like a reasonable requirement for the “identity provider.” Perhaps less obvious is why an SP should also have some form of corresponding image of this identity. What’s the point of dividing the work if the information is replicated? After all, you divide the work between an IdP and SP in order to keep the concerns separated, and avoiding redundancies is just good engineering design. But the truth is, you cannot avoid it! Even if the IdP is the initiator and owner of the identity information, the SP still needs to replicate part of this info for its own internal management. To identify a user of its service, at a minimum the SP needs some kind of identifier or “handle” for a given user that matches or correlates with the name it’s receiving from the IdP. (We don’t have to go back to OOP101 to remember that any object requires at least an identity, and in a distributed system, you need a way to remap between internal and external ”namespaces”—right? 🙂 )

Here’s an example—see if you can guess who I was for Halloween this year:

• IdP: internal identifier: JB007 token format: James Bond
• SP: token format: James Bond internal identifier: X2011

In this example, the SP has to know that James Bond = X2011, and the IdP has to know that JB007 = James Bond—because that’s what goes through SAML. So we see that in order to deploy these federation roles, you must seed both the IdP (if it’s not already done) and the SP with some form of identity list and a mechanism for mapping/lookup.

In order for the operation to start, you must first provision the SP with the list of the identities that will access the services. One bulk upload of those identifiers for a given service might be fine in rare cases, but we also know that identities are never static—they go through a lifecycle. What happens when a new user is added, deleted, or changes some relevant info? Whoops—your federation began at access management and now it’s forced to rediscover the wonderful world of identity synchronization and provisioning!

Such services are not described within the federation standards, but make no mistake: they’re essential for securing access for all those SaaS apps you use. Some companies in the federation space would argue that it’s enough to do a poor man’s version—what they’d call “just-in-time” provisioning. But the reality and requirements of your system are more complex than any ad-hoc, piecemeal solution can accommodate.

Think About How Well Provisioning Went Within Your Perimeter…

Then imagine repeating this operation for every underlying identity source in your infrastructure and for each of the cloud apps you’re targeting and you can begin to see the challenge. We all know it’s true: provisioning has never been easy—and why should it be easier now, reaching into the cloud? As I mentioned above, Nick and I would argue that such complexity calls for the establishment of some sort of logical center—a hub where identities can be federated, rationalized, and transformed according to the unique requirements of each SP. At Radiant, we call this a “federated identity system” because it’s the next essential step in developing your federation. Once you’ve federated your security layer, it’s time to federate your identities, as well—only then can you orchestrate those identities within your infrastructure, across the cloud, and even onto the many mobile devices of your stakeholders.

We’ll take a closer look at this idea of the hub in my next post, including ways you can get all the benefits of the metadirectory without the huge expense and hassle—so be sure to check back and stay tuned!