←back to thread

312 points campuscodi | 2 comments | | HN request time: 0s | source
Show context
Diggsey ◴[] No.43375000[source]
I recently had to implement SAML and this headline does not surprise me in the slightest.

The SAML spec itself is fairly reasonable, but is built upon XML signatures (and in turn, XML canonicalization) which are truly insane standards, if they can even be called such.

Only a committee could produce such a twisted and depraved specification, no single mind would be capable of holding and combining such contradictory ideas.

It would be so simple to just transmit signatures out-of-band and SAML would be a pleasure to implement.

replies(3): >>43375038 #>>43375229 #>>43375725 #
1. jiggawatts ◴[] No.43375038[source]
It’s much worse than you’re making it sound: XML is literally an eXtensible Markup Language, so… of course the SAML standardisation committee invented their own extension mechanism language on top of it.

Coming up with your own protocol on top of a protocol for a tiny amount of data amounting to not much more than what’s in an authentication cookie is the special kind of stupid that only the largest and most bureaucratic committees can produce.

replies(1): >>43380791 #
2. whizzter ◴[] No.43380791[source]
The SAML people aren't the most crazy ones though, the entire XML signature stuff is the insane part (You find it in other places such as xADES,SOAP,etc as well). In some misguided effort to avoid a inner-platform effect they made the decision to embed the signature in the structure itself being signed and thus enable these scenarios (needing canonical XML to verify things).

For any hate JWT gets, JSON-inside-JSON,etc, at least it architecturally avoids these kinds of security issues since you verify once and only read data from what has been verified and nothing else, instead of having to re-create data and hope that the loose structure doesn't mess things up.