On top of this, I have inside knowledge that some extremely common libraries that implement SAML were built not by reading and understanding the spec, but simply by looking at sample XML documents in the wild and writing code that handled it.
Multiple exceedingly obvious vulnerabilities have been the result. One fun one was: looking at an XML signature in the document, verifying it, then ignoring the assertion it was claiming to sign and just trusting the assertion at the document root.
I tried to write a standards-based implementation and gave up. The standard is enormous, and consists of three parts:
1. The definitions of what each XML tag means in a vacuum
2. Patterns on how to assemble those XML tags into a document that means something useful
3. Protocols that exchange these documents back and forth to accomplish some authentication objective
Half the problem comes from the fact that it's meant to do anything and everything, and so you can theoretically just mix and match all the above parts to get what you want. But that also means that it's exceedingly simple to mix and match stuff in ways that are subtly (or not so subtly) insecure. The other half comes from the fact that the standard is so damned complicaed in order to handle everything under the sun that it's damn near impossible to wrap your head around it all. So people just glance at the spec occasionally and just write something that handles documents they see in the wild and hope for the best, with predictable outcomes.
The whole thing is a tire fire.
Note, I last worked with it about a decade ago so I may have gotten some of the characterizations wrong.
Multiple exceedingly obvious vulnerabilities have been the result. One fun one was: looking at an XML signature in the document, verifying it, then ignoring the assertion it was claiming to sign and just trusting the assertion at the document root.
I tried to write a standards-based implementation and gave up. The standard is enormous, and consists of three parts:
Half the problem comes from the fact that it's meant to do anything and everything, and so you can theoretically just mix and match all the above parts to get what you want. But that also means that it's exceedingly simple to mix and match stuff in ways that are subtly (or not so subtly) insecure. The other half comes from the fact that the standard is so damned complicaed in order to handle everything under the sun that it's damn near impossible to wrap your head around it all. So people just glance at the spec occasionally and just write something that handles documents they see in the wild and hope for the best, with predictable outcomes.The whole thing is a tire fire.
Note, I last worked with it about a decade ago so I may have gotten some of the characterizations wrong.