I had a great time at the recent Cloud Identity Summit - a fantastic venue (Vail, CO) with a wonderful lineup of speakers second only to our own European Identity and Cloud Conference (EIC) coming up next May in Munich. (Hurry, the call for speakers is already underway).

What I didn’t expect in Vail was a great deal of controversy, but there was. And right at the center of it all was my colleague, KuppingerCole’s Distinguished Analyst Craig Burton. Craig stood up at the podium and announced to the world: “SAML is dead.”

This was off the chart because, well, SAML (Security Assertion Markup Language) is at the heart of most of Ping Identity’s products. And Ping Identity was our host. Predictably, Ping employee tweets immediately sought to reassure their followers that SAML was alive and well. What they neglected to take into account, though, was context.

Context is important for Identity Services as I’ve said over and over again for at least 10 years (see “Identity and privacy: it's all about context”). But context is also important for understanding the spoken word.

Craig was speaking in a track I was moderating called “Analyst Perspectives,” and the title of his presentation was “The Future of Authentication.” Note that word “Future”.

Most of the other analysts agreed with Craig (as did many of the attendees, especially those who were in his audience.) Some pointed out that other, seemingly dead, authentication protocols (such as IBM’s RACF and Top-Secret) were still used by many as were programs written in COBOL.

But far from being an argument against Burton’s pronouncement these are actually supporting evidence for his claim that SAML is dead. Because RACF and COBOL are also “dead,” at least in the sense Craig meant.

Remember, he was speaking about the future of authentication, not the situation today. He was warning those just starting out on the road to replacing username/password combinations for login, to those looking to create tomorrow’s Simplified Signon (SSO) solution or those needing to plan for cloud-based services (including authentication) in the future that SAML should not be the primary conduit for their data.

As he qualified his remarks, Burton said: “SAML is the Windows XP of Identity. No funding. No innovation. People still use it. But it has no future.” And added, “There is no future for SAML. No one is putting money into SAML development. NO ONE is writing new SAML code. SAML is dead.”

And then he reiterated for the hard of understanding: “SAML is dead does not mean SAML is bad. SAML is dead does not mean SAML isn’t useful. SAML is dead means SAML is not the future.”

So what is the future for authentication?

In May, at EIC I presented an award: Best New Standard 2012 in the Category “Best Innovation/New Standard in Information Security” which went to OpenID Connect for “Providing the Consumerization of SAML. Driving the adoption of federation and making this much simpler.”

As we said at that time:

“OpenID Connect is a simple JSON/REST-based interoperable identity protocol built on top of the OAuth 2.0 family of specifications. Its design philosophy is “make simple things simple and make complicated things possible”.

While OAuth 2.0 is a generic access authorization delegation protocol, thus enabling the transfer of arbitrary data, it does not define ways to authenticate users or communicate information about them. OpenID Connect provides a secure, flexible, and interoperable identity layer on top of OAuth 2.0 so that digital identities can be easily used across sites and applications. While enabling a default set of common claims about the user (such as name, e-mail address, and a user identifier enabling SSO) to be easily employed, OpenID Connect also enables participants to exchange any claims relevant to their application using simple JSON-based data structures.

As it is based in OAuth 2.0, OpenID Connect reaches beyond the Web. OpenID Connect brings identity interactions to “apps” and “native applications” on both smart phones and traditional computing devices, in addition to Web sites.”

OpenID Connect is many things that SAML isn’t: simple to implement, easy to maintain, efficient for all parties but especially at scale. Long after a pure SAML environment becomes hopelessly inefficient because it’s an inherently point-to-point protocol, OpenID Connect continues to hum along.

Other issues we addressed include –

  • From a security perspective, OpenID Connect was built to be able to gracefully range from the low security levels typically employed for social networks to medium security levels needed for business applications to high security requirements needed for many government applications. OpenID Connect spans this wide range of applications by using JSON-based digital signature and encryption standards.
  • From a privacy perspective, OpenID Connect allows the selective sharing of attributes with user consent. It also enables the use of pairwise pseudonymous identifiers, thereby avoiding correlations as appropriate.
  • From a business perspective, OpenID Connect meets business needs for the use of claims from multiple Claims Providers in a single context (rather than a single Identity Provider being the source of all claims for any given interaction). It enables the use of Aggregated Claims, where signed claim values can be collected and passed on by OpenID Providers and the use of Distributed Claims, where claims are passed by reference, rather than by value, and dynamically retrieved by Relying Parties.
OpenID Connect is RESTful, SAML requires SOAP. OpenID Connect is represented in JSON, SAML is – of course – an XML subset.  Both of these mean that OpenID Connect is a leaner, more efficient protocol. But here’s the capper: OpenID Connect can be bound to SAML. The path to transition is very clear.

As I was writing this, the long-time lead author of Oauth, Eran Hammer-Lahav, posted to his blog that he was – effectively immediately – resigning that role. His reasons all really boil down to this: “At the core of the problem is the strong and unbridgeable conflict between the web and the enterprise worlds.” Like many designed-for-the-web (or “user centric” or “consumer centric”) identity protocols, Oauth 1.0 was very lean, very easy to implement – and very easy to get wrong. It did what the designers intended it to do, but – like OpenID 1.0, or SCIM 1.0 – it was far from robust, far from secure and far from satisfying the needs of Identity Management. I’ve no problem leaving Oauth 1.x and/or OpenID 1.x to be used for their initially intended purposes (SSO for low value web sites). But the needs of the enterprise are also important, and the improved versions of these protocols – OpenID Connect and Oauth 2.0 – are the future.

SAML was king, at least in the opening decade of the 21st century, but the king is dead. Long live the king!