While there are a thousand reasons to hate SAML, your concerns are not accurate.
1. I guess "relatively new" is a vague term, but SAML v2.0 (the current version) was standardised in March 2005 - it's now 12.5 years old, I don't call that new.
2. SAML is very widely used in certain segments. Every SSO product supports SAML, including cloud vendors like Azure, Google and now AWS, and also specialist vendors like Okta and OneLogin. Within the dreaded "enterprise" space, SAML is absolutely the #1 SSO technology in play.
3. The golden SAML attack is a load of crap. It basically says "If you can get the private keys of an identity provider, then you can impersonate that identity provider". Yes, SAML relies on the confidentiality of the signing keys. That "attack" is the equivalent of saying Linux security is broken because if you have the root password you can modify any file.
> I guess "relatively new" is a vague term, but SAML v2.0 (the current version) was standardised in March 2005 - it's now 12.5 years old, I don't call that new.
True, but it's still relatively new to most people, similar to how IPv6 has been around for a few decades but is still "new" to many.
> SAML is very widely used in certain segments.
Perhaps but it's only been in the last few years that I've been hearing about it, mostly WRT the cloud vendors (AWS, specifically).
> The golden SAML attack is a load of crap.
Yeah, I think I mentioned it isn't very practical. To me, though, this seems like just the unexpected kind of thing that, some day down the road, is going to come back and bite you in the ass. That is, some major issue in some piece of infrastructure that is overlooked, forgotten about, or taken for granted (e.g. heartbleed or similar), that suddenly causes everybody to drop everything and react immediately to fix it.
It’s new if you’re not informed about identity as a technology area. Some people in that space consider SAML2 to be outdated!
The beauty of a federated identity system is that you keep your credentials away from business partners. If you were a corporate customer of Dropbox relying on them to host your identity, you were kind of fucked when they had an account breach. If you used federated identity, Dropbox never had access to your account credentials.
Federated identity also lets you control posture and control access better. Perhaps your email system requires multi-factor auth, but your time card system does not, unless you are approving expenses. You can build that “step up” to multi factor auth on your servers, and use a single MFA credential to do so.
It's outdated enough that even the Enterprise vendors are starting to look at OpenID Connect to replace it.
The draw with SAML was definitely for enterprise requirements -- the main one, as I understand it, was the requirement of sharing metadata out-of-band between the IdP and SP to establish trust. While that sounded like a good idea at the time, it turns out that if your organization ends up needing to trust and exchange metadata with more than a few other entities, managing all those certificates and properly validating them is enough of a pain that metadata aggregators have sprung up to handle them.
> Perhaps but it's only been in the last few years that I've been hearing about it, mostly WRT the cloud vendors (AWS, specifically).
As business have become more willing to move core services to cloud platforms, they've demanded that those platforms provide a single sign on solution that integrates with their corporate directory.
So, the popularity of SAML has certainly risen with the popularity of cloud / SaaS, but it's perfectly normal for a technology to become more popular with time (until it eventually goes into decline), and that increase in popularity means that it becomes more widely known, and some people who have never had to deal with it before, now come into contact with it.
I've been involved in SAML implementations at fairly conservative technology organisations (banks, pharma) for more than 6 years (and for most of that time it wasn't my core role).
It's old tech, that's in wide usage, it just isn't something that most people need to deal with because it's boring identity management infrastructure that most application developers don't get involved in.
We build non-technical SaaS software targeted at anywhere from pre-IPO to Fortune 25 companies. I'd say SSO is a hard requirement for at least half of our new customers (which to them means SAML 2.0 - ADFS, Azure AD, Okta, OneLogin, etc). And this number has been rapidly growing in the last 2 years as companies become comfortable with using cloud-hosted SaaS solutions rather than on-prem.
While it may not be the prettiest protocol, today it is the only broadly supported SSO option that does not expose your credentials to a third party. LDAP was the way to go at one point, but this only makes sense for on-prem software where you can trust your credentials to flow through.
Also, I am pleasantly surprised by the number of orgs that are introducing regular key-rotation into their SAML iDPs.
1. I guess "relatively new" is a vague term, but SAML v2.0 (the current version) was standardised in March 2005 - it's now 12.5 years old, I don't call that new.
2. SAML is very widely used in certain segments. Every SSO product supports SAML, including cloud vendors like Azure, Google and now AWS, and also specialist vendors like Okta and OneLogin. Within the dreaded "enterprise" space, SAML is absolutely the #1 SSO technology in play.
3. The golden SAML attack is a load of crap. It basically says "If you can get the private keys of an identity provider, then you can impersonate that identity provider". Yes, SAML relies on the confidentiality of the signing keys. That "attack" is the equivalent of saying Linux security is broken because if you have the root password you can modify any file.