Bringing Identity Back to the Center of IAM

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. Who will get swept away and who will discover new lands? Here’s  what’s happening in IAM these days and why 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.

Look at the choppy waters we’re all sailing in these days.

Map of Ye Olde Identity Infrastructure

When we look at current trends in IAM, the strongest wave is coming from the federation corner. Will the SAML 2.0 or Open-ID connect/Oauth 2.0 protocols win the Federation Cup?  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 specific details of protocols, the blueprint of federation is spreading across the IT landscape, and it will become dominant over the next three to five years. The federation pattern divides the task of authenticating/authorizing between two main roles for the participating organization: a service provider (with the relying party in a supporting role) and an identity Provider (IdP). This division of work was originally designed for a traditional federation, a group or consortium of companies pooling services and resources while delegating onboarding, registration, and Single Sign-On (SSO) to selected members. But thanks to the existence of the standards 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. 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…

From a SaaS application, or external application that is based on the federation pattern, your organization is in charge of managing and authenticating 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

When 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. 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 and 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) Authenticating the user against your own identity store.

2) Remapping the information to the format expected by each service provider (which speak their own local dialect of SAML).

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 of identity stores. All this heterogeneity means that fulfilling the role of the IdP can become a monumental deployment hassle for every application you try to service.

As noted 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.

Our Federated Identity Service in Action

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.