6:17 p.m.
Hi Jesse,
O'Reilly Media is working to build out a proper
multilateral
federation SP for our platform. We have deployed Shibboleth SP3 for
development but are finding that integrating our existing systems with
Shib to be inefficient and rather kludgy.
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.
SATOSA looks like a great
fit for our python-based AuthN/Z OIDC backend but I have only
identified a handful of deployments (E.G. GÉANT and possibly CERN).
We would use it as a SAML backend and OIDC frontend with InCommon's
MDQ feed and, initially, their discovery service as well.
For those who have deployed SATOSA in production, what has your
experience been in terms of reliability and maintainability, either
generally or as compared to Shib SP3?
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.
Also, can you share roughly how
much ongoing IT and development time has been needed to maintain a
high level of uptime?
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.
I welcome additional feedback and suggestions as well.
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