That’s right—we’re bringing identity back… 😉

There is no doubt that IT in general and IAM in particular are facing a sea of change. The disruption of the cloud, along with the emergence and explosion of new devices and form factors, is creating the kind of turbulent environment where major opportunities can be exploited—and major blunders can sink the best organizations. So who will get swept away and who will discover new lands? I’d like to take my next few posts to look at what’s happening in IAM these days and why we believe that federating the identity layer—not just the access layer—is essential for empowering today’s fragmented IAM infrastructures and driving business in a cloud and mobile world. And for a look at the choppy waters we’re all sailing in these days, don’t miss our map of Ye Olde Identity Infrastructure—just click to enlarge:

As the Chinese curse says, we are living through interesting times. When we look at current trends in IAM, the strongest wave is coming from the federation corner. Now, we can discuss at length which protocols will win the Federation Cup—will it be SAML 2.0 or Open-ID connect/Oauth 2.0? My guess is both—and, as usual, the answer will depend on the problem at hand. Are you focused on access for employees, contractors, and other “internal” users, or is your course set for customer and prospects? But there is common consensus that organizations will have to access services—likely in the cloud—as well as expose their own services to other organizations.

The Rise of Federation: Putting New Demands on Your IAM Infrastructure

Beyond the specifics details of protocols, the blueprint of federation is spreading across the whole IT landscape, and will become dominant over the next 3 to 5 years. The federation pattern divides the task of authenticating/authorizing between two main roles for the participating organization: a Service Provider (SP) (with the Relying Party (RP) in a supporting role) and an identity Provider or “IdP.” This division of work was originally designed for a traditional federation, a group or consortium of companies pooling together services/resources while delegating onboarding, registration, and single sign-on to selected members.

But thanks to the existence of the standards I mentioned above, this same framework is becoming the de-facto access method for SaaS or “cloud” applications. Acting as a Service Provider, the SaaS vendor can dedicate its best minds to delivering and supporting a high value, specialized service to its tenants. And when those tenants are themselves medium-to large-enterprises with thousands of employees or members, the only practical approach is delegating user management—in particular the authentication function—back to those same organizations. In short, turning them into IdPs.

Federation Only Routes Access to an IdP…

Let’s see what this process implies. From a SAAS application, or any external application that is based on the federation pattern, your organization is in charge of managing and authenticating your users. This is a smart way to do things: instead of having n applications trying to manage  n users in n different ways, the protocols “federate” their request for authentication, delegating it to an agreed-upon “identity provider.”

Identity Provider

So if we analyze a protocol like SAML 2.0, we see that it gives all the details about how the authentication request and response will be made, and we also see that in the agreement between the service provider and the identity provider, the content of the token—the set of attributes that establishes the identity of a given user—can vary widely. No problem there, because different applications or services can require different level of identity insurance and so the protocols support that.

But at a minimum, this means that each of these external applications will require a set of specific attributes to be returned by the identity provider as a proof of authentication, along with additional attributes for authorization, personalization, and other initiatives. It’s like having a single user who needs to present a new boarding pass for every flight on their way to a destination. So as an IdP, you must identify and authenticate a user—we’ll take a closer look at that process in my next blogpost—and then remap the identity information you manage, translating it into the different specific token formats required by each application. This diagram shows how the process works:

The Challenge of IdP Implementation: Managing Different Security Domains

But here we are just looking at the external aspect, the contract to be fulfilled by the service provider and the identity provider. According to this contract, the authentication request will be handed off to the IdP, which identifies the user, and then returns the proof of this authentication with the required attributes in the format of SAML2. Repeat for each application that talks to your IdP and you have the complete picture.

It Won’t Unify Your Identity for You…

Now this all sounds good, but what gets left out of the story is how you would implement your role as IdP on the backend:

1. First, authenticating the user against your own identity store.
2. Then remapping the information to the format expected by each service provider (they all speak their own local dialect of SAML).

And here, the devil is in the details. What we’ve learned over many years of diving deep into the wilds of the identity stack is that your infrastructure is most likely messy, with users and attributes scattered across a diverse array for identity stores. And all this heterogeneity means that fulfilling the role of the IdP can become a monumental deployment hassle for every application you’re trying to service.

As we’ve seen above, fulfilling the responsibilities an IdP can be complicated—and costly. But there’s a way to cut that complexity, delivering exactly the identity that each service provider requires. You’ve already federated your access layer, now you need to federate your identity layer, for a completely federated solution. You may have guessed by now that I have a way to do just that, and in my next post, we’ll take a close look at how our RadiantOne federated identity service is a complete system for virtualizing, rationalizing, and even storing your identity—no matter how messy.

Our Federated Identity Service in Action

So be sure to check back to learn more about how you can make your identity work for your federation—and your business.