SAML: A fractal of bad design(blog.trailofbits.com) |
SAML: A fractal of bad design(blog.trailofbits.com) |
OIDC will eventually displace SAML, but if you're selling to enterprises you should really support both. Both will pale compared to the amount of time you spend dealing with SCIM inconsistencies between IdPs anyway.
I don't believe it's plausible for any non-specialist firm to implement SAML without grave vulnerabilities. I'm not sure I've ever seen it done well. It's been a minute since I've looked (I haven't consulted in several years, but, more importantly: most firms avoid SAML now), but I'm guessing that assertion still holds.
- check it against an hmac using a password specified in the attacker controlled document.
- check the signature using web pki (so the attacker could sign the saml document with their TLS key for their own personal domain and it would always be considered valid)
I honestly dont know how sites with saml arent getting hacked all the time. The only thing worse than the absolute terrible standards are the absolute terrible implementations.
The article rightly connects this to XML, which was indeed the hammer to everything’s nail at the time
I think we aren’t done with this problem yet, though. OIDC makes a lot of assumptions in service to Google and others. And tailscale as mentioned, despite “holding the line,” already reveals the cracks when things like GitHub accounts have to be treated differently from others.
What we are missing is a provider-independent way to do this. I should be able to create an account and log in just about anywhere using a backend I control. It can be done, but not with what we have today
I mean … how else would you check a signature? You have to have the data to validate the signature.
You would be shocked (or, if you’re in the security space at all, not even remotely shocked) to learn that a comical number of SAML implementations verified the signature and then just treated the whole doc as if it was trusted, even if the signed part had nothing to do with the document as a whole.
In SAML you sign a (potentially attacker controlled) subset after normalization. So a lot of saml bugs come down to the attacker adding things that aren't covered by the signature. Sometimes this means appending or prepending stuff, but my favourite is adding comments which can alter the interpretation of the xml document (as it splits text nodes) but doesn't alter the signature.
So it is possible to have an XML signature that points to an element that does not include some important piece of data.
I suppose you are more a fan of the histrionic tone of the criticism than anything? In which case, I'm with you there. It's equal to the most unhinged but technically correct rants of Zed Shaw for me.
1. For OIDC/OAuth2 the request has to originate from Service provider, most Enterprise IDP's rely on SAML for Single Sign on cause of its ability to do IDP initiated flows
2. The security for SAML is baked into the payload itself, provides safety against MITM attacks, even though the HTTPS provides similar guarantees in theory, the reality is that your SSL offloading happens elsewhere, not on your application server
The OP provided a list of vulnerabilities discovered in SAML, IMO this kind of comparison if flawed if you do not present the same for OIDC/OAuth2.
At the end of the day, these are tools and effectiveness of a tool is a lot dependent on ones skillset to understand and use the tool.
Anyone who has used Wireguard and OpenVPN will spot the difference. OpenVPN is the design-by-committee, Wireguard is the focused opinionated design by someone with a vision. OpenVPN does more things, but if your use case is one that suits Wireguard, Wireguard does it much better.
You also see it with OSI stack versus IP. OSI invented all these layers for proving identity, establishing circuits, sessions, different billing models, collect calls, quality of service, all that stuff. IP looked at that and said: fuck that noise - we send packets, if they don't arrive we send them again, job done. Nobody uses the OSI stack, even though IP fits the OSI model loosely enough that they still teach it, and X.509 got reused as boilerplate for WebPKI certificates.
XML vs JSON is another one. Granted marked-up text, which XML was actually designed for, is very ugly in JSON, but even in that use case, XML has way too much complexity.
If the IP, Wireguard or JSON people designed an SSO system you'd telnet or HTTP into the authenticating party, perform its login steps, get a token you could copy-paste into the relying party and it would check back with the authenticating party to see if the token is valid and the username of the person who signed in - done. And then someone would make a browser extension to automate the copy-paste part. Or maybe they'd embed it in an iframe. Instead we got whatever the hell this is.
Protocol complexity is where bugs hide, including vulnerabilities. It also creates incompatibility wherever two implementations implement it differently - and that's intentional in many cases. It's just bad. You have to be opinionated about what you design or you designed nothing at all. If it doesn't fit all use cases you can design something else to cover the rest.
The XSW part of the article was new to me though and kinda shocking
OAuth/OIDC is a problem if you're trying to shove a bot-shaped peg into a browser-shaped hole, but we don't need a new protocol to solve that.
If my security system is showing friction when there's a wave of agentic slop, I'd say that's a win.
I'm almost convinced already, but I have the professional duty to at least read why
>SAML is an XML-based
Ok, I'm convinced
Oauth2 is utter utter shite as well.
1. It's not an authentication protocol, but it was abused as one for until OpenID Connect came along
2. OpenID Connect is the compatible authN protocol, and it actually has a spec unlike OAuth2
Both of those are annoying because they are over-complicated for simple use cases and for a long time there were very few simple open-source providers that weren't hiding all the important stuff behind their enterprise/cloud versions.
Open source options like Zitadel are improving this space somewhat, though they are still sort of painfully complicated if you want to deploy something small and simple that you can understand. In order to be big business they have to support tons of 3rd-party provider plugins with all their out-of-spec wrinkles.
It would be nice to have something like Zitadel that is signficantly less concerned about all those third parties - like let me very easily just host username/password and passkey auth in a small package.
(Or to be more clear, it is mostly unacceptable for an enterprise product to have opinionated decisions about what authentication it works with. You either work with what we use or you are not viable as a product for our need. It's kinda simple. I would expect someone whose authentication was OIDC-based to be similarly dismissive if you told them you only would do SAML.)
It’s three entire specs bundled as one. One for the XML components, another for the documents you build from them, and another for the authentication flows built on top.
Signed assertions. Signed messages. Encrypted messages. Encrypted assertions. Sign after normalization. Sign before normalization. Encrypt then sign. Sign then encrypt.
There’s too many ways to do too many things.
It's an absolute dumpster fire.
Smaller tech companies don't want federated login to happen. They are, as a rule, far to happy to rely on the SSO tax to up-sell enterprise customers. The major authentication companies don't want federated login to happy because it invites more competitors and threatens their absurd margins.
Until someone manages to solve the business side, no amount of improved technology will change a thing. I'm pretty sure the few small interoperability gaps OpenID Connect has could be corrected in a matter of months if the stakeholders actually cared.
From vague memory, the other stuff in OpenID Connect was layered over the original OpenID identity verification part.
If you needed a serialized representation of structured data, I think it made engineering sense to use XML even if it was more featureful than you needed. The alternatives were ASN.1 or rolling your own format from scratch. It's not at all obvious that those are better.
(You could argue in favor of rolling your own format on the grounds that it wouldn't be vulnerable to XML-specific security problems, but I don't think those problems were fully appreciated at the time. If they had been, probably people would have come up with some kind of quasi-standardizable secure XML variant that just disables the specific features that cause those problems.)
I agree that XML (even without the security-relevant misfeatures) is worse than JSON or other non-markup-language serialization formats for the majority of use cases that don't need a markup language, but this is not a big problem, it's basically just syntax.
The DSIG problems are wildly worse than syntax! There's a document object model to contend with, along with invariably-fatal parser differential bugs, and that's before you confront the one global C implementation that almost every DSIG implementation ends up relying on.
IndieAuth exists, it's just not widely supported.
"Host your own identity"
It’s like “using JSON” but actually encoding objects indirectly through your own made up object notation… that is structured.
If anyone could attest to who they are at any time we could just have user/pass without email and call it a day.
We should remember that we learn by failing.
Edit: When I first read the comment, XML part was not there, but I don’t agree with the XML part of the comment, because JSON to XML is Python to C. While both can carry data, XML is designed to handle more than that. Especially validation and transformation parts. If you don’t need these, it’s an overkill, but if you use them, it’s a perfectly fine format. It’s even elegant and batteries included.
Also, you can parse it in an instant. I have designed XML based file formats which would fall apart in JSON and YAML.
The XML debates sounds to me like calling a space shuttle complex because one only needs to go to the mall downtown.
Pretty much everything supports SAML. If you decide not to support one of the standard protocols for SSO, you'll lose out on customers. Your tool has to bring in a lot of benefit (and have no competition) to warrant upending a company's entire auth system for.
Makes sense for GP locally, I guess, but globally we’re all worse off when nobody is motivated to break free from the path of least resistance.
1. "You either work with what we use" - so whatever organization you represent isn't capable of evaluating and shifting to more secure technologies?
2. "it is mostly unacceptable for an enterprise product to have opinionated decisions about what authentication it works with" - you think companies that care about security should not care about integrating with flawed protocols?
A potential customer making bad choices does not obligate a business to make bad choices for their business.
As a SaaS vendor, interacting with our customers about SAML usually involves:
a) them knowing what they want because they already have SAML-based SSO and it works for them; and
b) our contact on their side being some unfortunate support dude who got given SAML as their subject area for whatever reason, and who knows very little about it, and who is 4 levels in the org away from anyone empowered to make decisions as significant as moving away from SAML.
Indeed it does not. If you feel that strongly that you are willing to lose out on that customer, that's your right. But that does not mean the foregone customer is unreasonable for expecting you to work with their constraints in order to get their business.
If you are a vendor, you should have SAML support unless you are early (and can only support 1 standard), or you are highly opinionated.
If you are a consumer instead, you will only be using one standard, so you HAVE to chose 1 and not the others.
Saml is just not reasonable in our modern security environment.
https://www.war.gov/News/News-Stories/Article/Article/428899... (Microsoft has solely discontinued this practice for the DoD tier. Commercial, GCC, and GCC High are still impacted because foreign labor is cheaper than the risk to your security.)
1. Finding out a company wants several grand to flip the "allow SAML" switch on the tenant config, and a few thousand a year in additional licensing to leave it on. (I had a vendor both tell me it "takes five minutes" to get it set up, and then quote me $4,800 to "implement" it.)
2. Having to yell at the SaaS vendor for routing the identity connection between two or three other identity providers in different various clouds because, you know "modern stuff". (A vendor I am working with has not less than five different accounts to access various parts of their infrastructure, none of which are connected at all. I assume people there listened to "switch to OIDC" nonsense, completed half the job, and now have OIDC sites and SAML sites forever.)
3. Discovering the SaaS vendor knows how Entra works, how Okta works, and how Google auth works, and having no idea how SAML works. Or OIDC or anything else for that matter.
4. Eventually finding an engineer far enough from the sales and implementation teams who can answer how the product actually works. :D This point is reached after a lot of yelling.
If I’m paying for at least one Senior to build and support this awful enterprise authentication pattern, I’m looking at around 200k per year in total cost - you damn well bet I’m billing you for it!