SAML the Undead
In September 2012, a lively discussion erupted when Craig Burton and Pamela Dingle at Kupperingcole launched the view that SAML was dead Now, in 2014, the exact opposite appears to have happened: SAML has become mainstream. Were they wrong?
The war cry ‘SAML is Dead’ was triggered by the emergence the mobile app, with its’ REST/API authentication issues, and the birth of OAuth. This illustrates the inability of SAML to work outside the browser. For readers not much into acronym soup: organizations today have to deploy at least two solutions side-by-side or in a mixed mode, one for human users with a browser and another for mobile apps and other system-to-system interfaces, as in smart devices. This mixture is generally quite complex and (security) error prone, as it mixes two conceptually very different approaches – trusted people versus trusted systems. Trusting people has to do with user authentication, human verification and organizational processes, while ‘trusted systems’ boil down to cryptographic theory and device identity. The first concept has mostly landed, but the second is still in its infancy, both technologically and conceptually. This point is well made by very weak implementations based on PKI certificates installed on mobile devices as a proof of identity. A certificate on an insecure device is little more than a cookie with a three year Time To Live.
This rising complexity certainly kills the elegance of simplicity SAML once enjoyed. And as we all know SAML hasn’t moved to a 3.0, so the issues noted in 2012 must still be there. They just mostly go unnoticed as the majority of the world is still coming to grips with the very basic notions of trust zones and access tokens, and the new complexity is largely unnoticed.
Yet what is happening below the surface in vendor space is proving Craig Burtons every point; the post-2012 generation of federation tools has abandoned the basic SAML concept. Most products are becoming very complex – with Microsoft’s Active Directory Federation Services (ADFS) as a noted exception, which has effectively become a mere portal to Azure in an unwise act of self-mutilation. But for the grand majority later developments than OAuth add to the melee, turning the once very basic Identity Provider (IdP) into a 42-piece authentication Swiss knife. Selecting ‘an IdP’ with the option to replace it at will since it was a ‘loosely coupled’ architecture is long gone. Visionary products such as the open source access management tool OpenAM have already opted for the system-to-system side, with a focus on the Internet of Things. As fascinating and apt this decision may be, for most organizations such developments are way beyond the horizon.
Another major change to the Authorization Swiss Knife is the addition of OATH ( OATH and OAuth are different standards aiming at different goals, easily mixed by their similarity. OATH is about strong user authentication, while OAuth is about sharing authentication tokens over services)-compliant multi-factor authentication. The Multi Factor Authentication (MFA) and IdP product lines are rapidly converging, with most Multifactor Authentication vendors adding an IdP function to their products, as a very long overdue replacement of RADIUS. The security logic is very straightforward: Single Sign On actually brings less security, a downside that must be overcome with better means of authentication. And MFA is adding the necessary extra security, but with the pricing models of most MFA vendors still exhuming Enterprise IT, adoption is slower than necessary. Fueled by some interesting open source initiatives, OATH-based MFA has become a very serious option for most organizations.
The final critical piece of change is JWT, the JSON Web Token - pronounced ‘Jot’. SAML - a product from the beginning of this century - is defined in cookies. Cookies suffer from an often ignored set of limitations, many in security but particularly in transporting claims – attributes used for authorization and personalization by many Identity Providers. The JWT is taking over this role from the traditional cookie, with as yet a mostly unclear end result.
The result of these changes is a set of security tooling that may very well be counterproductive: the unexpected complexity brings nasty surprises, both in implementation projects as in actual use. The end result is very likely to be much less security than expected. The urgent advice to all is getting the RFC’s and the books on the table and study, for this ‘beast’ is here to stay. For, on the upside, once tamed, it is a beautiful beast.
Peter Rietveld is Senior Security Consultant at Traxion