If you work on a system that needs to authenticate against an external identity provider (IdP), SAML is almost certainly a fact of life. Working on an actual Identity Provider, sometimes the concern is flipped and you need to ensure Service Providers (SPs) can authenticate against your IdP.

I inherited the somewhat clunky django-saml2-idp along with other developers in my team, and we’ve been maintaining it to add new features. If we were doing this today, we’d probably integrate the very complete OneLogin SAML library instead.

Developing with and for our somewhat homegrown SAML library is made easier by a set of developer tools. For example, OneLogin provides a toolbox to slice and dice SAML assertions; you can verify your assertions, extract attributes, see some examples, play with zipping and encoding, all in one place.

Once you have your IdP mostly working, it’s great to have a test SP to connect to it. For this, I’ve used the RSA SAML test Service Provider. You give some details about your IdP, and it will give you a URL that forwards you to the IdP for authentication, then back to the SP, which verifies authentication worked as expected and even shows you the attribute and auth payload received from the SP.

Once you get things mostly working but need to fine-tune or tweak something (I can never tell between issuer, ACS_URL and audience), the Firefox SAML Tracer extension is absolutely essential. It shows you all requests and responses, which ones contain SAML payloads, and lets you see the actual, decoded and formatted XML payload which makes it a breeze to troubleshoot.

There is an equivalent SAML tracer extension for Chrome but 1) Chrome is crap and 2) the Chrome SAML extension is crap. Use Firefox instead.