SAML: A fractal of bad design

ocdtrekkie

Eh, if you don't have SAML support, I can find a product that does. Not a problem. \o/ (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.)

cratermoon

The requirement for connected network topology is a non-starter for many SaaS products. I don't want my systems to be open to some backchannel communication from the SaaS providers service.

stuaxo

Implementing all the main authentication mechanisms is hell. Oauth2 is utter utter shite as well.

arpinum

SAML is even worse than the article describes, problems like needing to check what the signature actually signs. But I'm optimistic about the future, instead of relying on libraries that do a lot, such as general xml parsing, we can support a subset of SAML and only the dialects of the top ~10 providers. Extreme niche providers can be added ad-hoc and only if the deal size makes it worthwhile.

miguelspizza

SAML is bad, but OAuth and OIDC are showing major cracks with identity and agents. Go to any major company right now and ask them how they are dealing with authenticating agents/what an agent identity even is. The XSW part of the article was new to me though and kinda shocking

pocksuppet

It's called design by committee. It's when you get everyone in a room and nobody can make a tradeoff because it would hurt someone else's pet use case, so you don't actually design anything at all, just build a framework within which a design can exist. 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.

jmbwell

It’s such a product of “Ooh! Markup languages! What can we use a markup language to solve!” When authentication is just not a document or data stream that needs marked-up. 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

TZubiri

>It’s time to deprecate it and move on to modern alternatives like OpenID Connect (OIDC) 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

sandeepkd

May be I am in a minority here, but there are areas where SAML sort of shines 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.

xyst

Waiting for the "OIDC: Time for Authentication to Take a Xanny" article

bawolff

My favourite SAML horror story, is that it used to be, that by default the main c implementation of xmlsig would not just check the sig with the public key specified but would also: - 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.

bigquama

I have to know. Is this a play on the ever-so-popular https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/

cameronh90

SAML sucks, but it still has a bunch of features for its specific narrow enterprise SSO use-case that OIDC lacks - most notably IdP-initiated flow. OIDC is a constellation of specs with inconsistent support across products, whereas the commonly-implemented subset of SAML is more-or-less stable in its mediocrity. 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.

tehnoslow

A fair criticism of the article is that it lists SAML's vulnerabilities but doesn't do the same comparison for OIDC. OIDC has its own problems too: JWT algorithm confusion, none algorithm attacks, missing audience checks, and bugs in JOSE libraries

Hizonner

My shitty overcomplicated design is better than your shitty overcomplicated design!

fire7000

“ Further, a committee of subcommittees having meetings is a recipe for “kitchen-sink” protocol design (e.g., waterfall methodology, big design up front, etc.).” - personally, I like having a kitchen sink

paulddraper

ODIC cannot operate with a private-network IdP. SAML can. In general, SAML is complicated because (1) auth is complicated (2) XML is complicated (3) canonicalization/signatures are complicated. Some of those are unforced errors, some are historical facts.

DonHopkins

Right, so is there a PHP SAML module that perfectly fits like a fractal hand in a fractal glove? https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/

cryptonector

Re: canonicalization: design things to not need it, so don't bother with it. Relying parties need to received the blob of whatever (XML, JSON, DER, PB -- don't care or decode till the signature is validated), validate the signature over the exact blob you've received, then decode. This means you need the signing key's algorithm to be identifiable from its issuer and key ID metadata / URI. The header you'll need should only have the information you need to find (dereference) the issuer's signing public key. You'll never need to canonicalize anything this way. Ideally you should use encrypted tokens so you're forced to do authenticated decryption before getting to the claims portion, but no one has bothered to build that in a way that scales. I did build something like this for Kerberos in Heimdal ( https://github.com/heimdal/heimdal ), but we need it for encrypted JWTs too: derive symmetric encryption keys from {current epoch, base key, audience/relying party name}, and let the relying party download those keys (by authenticating) much the way they do for signed JWTs. But switching from signed JWTs to encrypted ones is a pain as it requires that the issuer know if the relying party can handle it.

dudeinjapan

The issue is not that SAML is XML per se, but rather: (1) auth happens over public internet rather than server-to-server, allowing the user to MITM the message flow and (2) the various XML parsing libs in various languages do not have consistent behavior when it comes to looking up a node by name (i.e. if there are dupes) or finding a child node. MITM can exploit these divergences for auth bypasses, etc. A SAML lib needs an extreme amount of XML sanitization, while still handling all the various “in-the-wild” XML format funkiness