The Hidden Requirement for Federation: Syncing and Provisioning to the Cloud

In comparing notes on Identity and Access Management (IAM) use cases and best practices with Nick Nikols of Gartner, I recently 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) 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, I was 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 me of something the second coming of the meta-directory, back from the (near) dead (or at least a similarly centralized structure that drives cloud provisioning and access efforts). 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.

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

Federation doesn’t eliminate the need for identity management on the part of the service provider or relying party. 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. A whole lot of remapping and conversion (and even at the level of authentication) we notice 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

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 a 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. Avoiding redundancies is just good engineering design. But the truth is that 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. Here’s an example:

– 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 (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. Provisioning has never been easy, so why should it be easier now, reaching into the cloud? 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 Logic, 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.

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.