Having recently been apart of a new SAML implementation, avoid it if you can. The technology behind it feels solid (passing signed/encrypted messages around) a

Having recently been apart of a new SAML implementation, avoid it if you can. The technology behind it feels solid (passing signed/encrypted messages around) and using an Identity Provider like Active Directory is an easy choice but after that is where things get difficult. The client support, at least in Python, is terrible and the resources to understand SAML are sparse. Everyone does something just a little bit different and there isn't much choice. We have some Django applications that needed to be SAML aware. While I was able to finally able to make it work after two weeks (yikes!!) most of my problems resulted in bugs within the client. SAML requests can have more than one signing/encryption certificate defined so when one certificate gets close to expiring you can add a second (or third...), let the first one expire then well behaved clients would automatically use the second one. Except when your client always grabs the first one and if the signing fails because the Idp signed the message with the other certificate and it doesn't try the second one =( Then debugging errors is cumbersome. Always pasting XML snippets and x509 certificates into tools to view the actual messages. Google'ing the error messages with little to nothing out there. Perhaps it's just a bad experience with a specific python module but given the complexity of SAML, little knowledge out there, I'd stick with CAS if given the choice. It might help the technology if whoever is behind it would maintain clients that adhere to the spec.