Hi Jesse, In my experience the Shibboleth SP is the most full featured, compliant, and robust SAML SP software available today. That being said, integrating it with an existing HA application architecture that itself cannot be easily or quickly evolved can be challenging since the Shib SP is not simply a library/module that can be bolted onto existing code. I support production SATOSA deployments for a couple of different projects: - collaboration infrastructure for the National Institute of Allergy and Infectious Diseases (NIAID) at the National Institutes of Health (NIH). - collaboration infrastructure for the Murchison Widefield Array (MWA) Telescope Project, a radio telescope project. - collaboration infrastructure for gw-astronomy.org, a site used for cross-discipline astronomy research involving gravitational wave data. SATOSA reliability is good. We run the services using standard Python deployment and HA approaches and it "just works". That being said, you should understand that those infrastructures deal with at most 100s of SAML flows per day. SATOSA maintainability is much more work. The project, along with pysaml2, are still relatively immature and only in the last 1-2 years have they really begun to go in a direction that will lead to long term sustainability IMHO. Right now both projects are evolving quickly, adding new features, and refactoring much code. As such I have had to stay on top of things and pay close attention. I chose SATOSA because the community behind it is "my" community (higher education and research) and I have the opportunity to contribute and influence its evolution. If your team has someone that already knows SAML/OIDC and Python pretty well and that can invest time in the community and closely follow development, I think SATOSA could work well for you. If your team is not so strong with SAML/OIDC or Python and is looking for something more turn key, than I expect SATOSA may not be right for you. For the deployments I noted above, once the code is in production and satisfies a set of requirements, then the ongoing IT and development time is minimal to keep that set of code running. The issue for me is that those deployments want to support more sophisticated use cases and so we are continuing to contribute to the development and evolution of both SATOSA and pysaml2, so we can get the additional features we need. The SATOSA (really pysaml2) MDQ support has some issues. The last time I checked it still caches information for too long (though that might have changed--I don't recall off the top of my head). It is a known issue and I think will be addressed relatively soon, but you should do your own testing and make sure you understand the behavior. HTH, Scott K