- Different approaches to providing SAML support to FOLIO in the future. Some thoughts on the pros/cons of the current approach vs other approaches have been collected.
- Intention, coming from a security angle, is that there were some security issues around SSO and SAML module that took a while to resolve, and there are still many open feature requests (e.g. federation, interoperability, et al)
- past research: separate this from FOLIO into an external module, i.e. less effort to implement these things in the module itself by transferring that load to an external, third-party module.
- Julian Ladisch's notes: it's maybe not that simple, and there are tradeoffs: it adds dependencies to the project.
- pac4j offers different auth-n methods in the future, which is a key reason to stick with it
- if we support SAML only, then it becomes more valuable consider migration to a third-party service
- original dev team of mod-login-saml is departed
- federation interoperability is not currently supported in mod-login-saml and may take significant dev effort
- what's on the table here?
- mod-login leverages pac4j and consolidate different protocol-specific login modules into a single module
- do we commit to handling authn within FOLIO, or push that layer out to deployment/ops to that external layer? w/i FOLIO gives granular control but requires effort. w/o removes that effort but makes us dependent on another service at runtime.
- Craig McNally is there anything that prevents both options? What would the interaction with an external system look like (i.e. WRT token generation, user ID verification, etc; would need to create a receiving module within FOLIO to handle this matching and auth-z)
- Axel Dörrer auth-z is a separate issue
- Jakub Skoczen: in part, this becomes a convo about resources: current module was passed to a new team but that team lacks capacity for enhancements beyond security fixes. There is work no matter which solution we opt for, and this effort should be raised to the PC.
- we have some features like federation support been raised as UXPROD features that have been ranked by institutions, but it hasn't been covered comprehensively.
- Marc Johnson: 1. does the community value the work? 2. how do we want it done?
- can we answer 2 before 1? note that no related features are pointed for 2021-R3 at present, i.e. if we ask the PC, lead time is 1-2 releases minimum
- VBar we need more clarity about the features before approaching the PC
- Axel Dörrer so maybe we need a POC first?
- VBar maybe not a POC, but need to spec out more details
- the flip side is that we leak impl details into FOLIO
- Jakub Skoczen this has some similarities to edge-modules; there are some architectural ways to make this work with either way. (Tod Olson but maybe this is too resource intensive? would it be better to say "we're taking auth-n into the project" or "we're supporting external auth-n via A and B"?)
- Jakub Skoczen A and B will be too limited, no matter what we think, so we need to consider that some amount of flexibility is necessary
- could the mapping of attributes between an external system and FOLIO be handled totally separately/generically?
--- meeting ends, but conversation continues ---
- conversation between FOLIO and an external service means that effectively we are talking about an edge-module
- a coherent way to implement SAML would be our edge-module paradigm and this would likely be good enough for many/most orgs
- note: there is complexity here that is not immediately apparent. it would be really helpful to have, and document a coherent strategy WRT auth-n for FOLIO
- there are multiple protocols, so what are the options to support them? (the implementors group is probably the right group to answer this)