The biggest problem with SAML is probably XML-DSig. The spec is ridiculously complex, but unfortunately the implementations are no better. You're de facto either using libxmlsec1 or the Java stdlib. libxmlsec1 is (anecdotally) a terrifying mess of C that most SAML integration libraries desperately want you to run in-process with your server.
There's a totally palatable mini-SAML within SAML waiting to come out. It already exists informally: it's whatever GSuite and Okta's default metadata.xml will give you, and it summarizes to "one signature, on the outside, no encryption".
You kind of need to do SAML, though, unless you don't care about selling to companies at all. Smaller companies may or may not be able to do OIDC, but pretty much everyone can do SAML. You just want to have someone else be responsible for the SAML laundromat part (that is: ingesting gross SAML from the Internet and translating it to a friendly consistent format, which doesn't necessarily have to be SAML too). For all its flaws, Cognito fits that bill, as does Okta.
> The biggest problem with SAML is probably XML-DSig.
I hope that I live long enough to read the book-length historical treatment of the late 90s/early-2000s obsession with XML. My personal opinion is that it set the industry back by a decade. It just blows my mind the amount of effort (time & money) which was poured into such a flawed architecture.
Ditto Java, really. The early-2000s vision was one great mass of Java & XML. Why we didn't stick with Lisp & S-expressions I'll never know.
I'm a lisper and dislike XML as much as the next guy, but XML-DSig seems like a fundamental mistake and sexp-dsig would not have been a better spec. All of the problems you get from in-band signing and encryption are still there--case in point, our blog post on how not to sign a JSON object[0] would be a fine spike on a blog post about why XML-DSig is bananas.
(One counterexample I can think of: you probably wouldn't do CDATA and comments the same way as XML did, which led to Kelby Ludwig's fantastic SAML auth bypass--which also gets a review in that blog post.)
> I hope that I live long enough to read the book-length historical treatment of the late 90s/early-2000s obsession with XML.
The alternative was SGML. Would you have preferred that, because that was the 'only' over option at the time.
It would be like saying twenty years from now: "wow, I'd love to learn why people used fossil-fuelled cars instead of EVs: ICE cars are so inferior". Well, at the time nothing better had been developed and we did the best we can.
The problem with SAML et al is not Java or XML. The problem is the spec conflating transport protocol concerns with the content format concern.
If you can cleanly separate the transport component's cryptography (making sure the content is secure and private) from the formatting and processing of the actual content it makes things a lot clearer.
Everyone should test their SAML deployments for XML signature wrapping vulnerabilities. XML-DSig is ridiculously complex.
The basic idea is simple: Take a valid SAML assertion and embed it, signature and all, inside a forged SAML assertion. Test your ACS endpoint to make certain it is rejected by the service provider.
There's a bunch of things you need to test SAML implementations for, from comment handling to audience checking to SSRF. It's not an easy feature to get right and there's no one good source on all the issues.
My best advice for safely using SAML is: use a library that everyone uses and that is well tested. This is a place where I might stand up a separate service in a different language to get a popular SAML library rather than the shady one that is most convenient for your preferred platform.
I agree with all of this (no wonder since Thomas' opinions and mine largely come from the same place), but dark horses like Kelby Ludwig's canonicalization bug make me even happier if I can outsource that infrastructure to a vendor, perhaps exacerbated since I'm also an infrastructure-focused person.
I'm not all starry-eyed about Cognito, but I know the next libxmlsec1 0day isn't my problem. (Except of course that probably is because some clients don't have Cognito :-))
Who cares? Nobody is bottlenecked by the Python overhead in their SAML proxy. People are boned in the oddball SAML implementations they use to keep their stack pure.
The OpenSAML library has native versions available for both Java and C++. There is a native SAML implementation for Python, and a native SAML client implementation for Go.
There's a totally palatable mini-SAML within SAML waiting to come out. It already exists informally: it's whatever GSuite and Okta's default metadata.xml will give you, and it summarizes to "one signature, on the outside, no encryption".
You kind of need to do SAML, though, unless you don't care about selling to companies at all. Smaller companies may or may not be able to do OIDC, but pretty much everyone can do SAML. You just want to have someone else be responsible for the SAML laundromat part (that is: ingesting gross SAML from the Internet and translating it to a friendly consistent format, which doesn't necessarily have to be SAML too). For all its flaws, Cognito fits that bill, as does Okta.