| > what is the issue with XMLDSig? There's a wealth of issues, some generic and some specific to the (not so well thought out...) choices made by the SAML spec. For starters, the XML signature spec requires canonicalization of the message (which is XML). But the message itself need not be the canonicalized message. So the SAML implementer, if they follow the spec, must process the untrusted input and canonicalize it prior to verifying the signature. Add in that you can override just about every aspect of the signature algorithm, canonicalization details, and even what parts of the message are actually signed, and you get huge number of places where things can either go wrong or may be overlooked. Then throw in "XML Encryption" (again with canonicalization) which could be done on the whole message or just the assertions. Then throw in that you can sign the encrypted portion, or the unencrypted portion, or just the assertions, or encrypt the signatures, or ... So in short, there's too many ways to do too many thing. Which leads to a massive surface area of code if you actually follow the spec. Which leads to libraries that either do not follow the spec (e.g., ignoring encryption and just checking signatures in a known location), or think that they follow the spec but will happily ignore missing assertions or out of date certificates. SAML sucks. But hey, it's still better than having your own passwords! |