It's significantly less useful for external authentication - where you want to your apps to auth against other people's user databases. SAML 2.0 is usually the standard for that, but as you say, it has to be configured properly on both ends.
SAML = Security & Authentication Mega cLusterfuck. It does get the job done, but it is the hell of a beast to understand and use.
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.
My experience with SAML was that, not only was it a bear to get set up, the second client who wanted to use it was using a different SAML implementation and found things weren't as standardized as we had assumed. Both implementations supplied a principal, only one supplied an email address by default. I think it got sorted out after I left.
I don't love CAS a lot, but it is a lot more turnkey than SAML.
We're investigating JWT now, but I have a feeling it will turn out to be an implementation detail within a larger solution that we haven't even begun to conceive.
I've also implemented shitty poor-man's federation on top of CAS. My recommendation there would be: don't do it. If you need federation CAS really can't help you, don't hack on it.
The other thing I've learned is that none of these things is going to help you with authentication at all, and that tends to be something that isn't well thought-out before implementation time comes.