And the HTTP artifact resolution binding (a complete, start-to-finish, description of what you need to do to log in a user to SAML and get attributes about them) is in here: https://www.oasis-open.org/committees/download.php/56779/sst...

Those come from here: https://wiki.oasis-open.org/security/FrontPage

Frankly, though... you're usually not supposed to be implementing this stuff yourself. Put Shibboleth's mod_shib_24.so in Apache in front of your login endpoint, and it behaves as a SAML service provider for you with consistent configuration and lots of help available for when it breaks. It provides you with HTTP headers for all the attributes provided about the user. If you're not using Apache for most of your app, you could just use it for a login script which shoves everything into a cookie.

Of course, if you're developing ASP.Net for Windows, you get your sysadmin to throw up an ADFS instance which deals with the federation, then use the built-in libraries to auth against ADFS, and it all works like magic.

It will help you a bit. Then you will only have two majors issues.

1) The protocol is a really complex beast of giant XML messages, with many variants of workflows.

2) It's very modular to allow to interface with lots of stuff with custom authentication, custom attributes, custom systems. So there is only 50% of a protocol which is clearly "standardized", the other 50% are left as a specific use case details with limited practical example.

I'm a believer that one doesn't do or understand SAML. It's more like, you get two specific products that needs to authenticate together for the business. You read the integration documentation for both and try to find whatever micro-subset of protocol they both talk and make it interface.