Page Comparison

VBar

• check in with TC WRT whether we have resources for the system/tenant level users champion
• spoke with Mikhail Fokanov who will dig into this and carry it forward. CC: Jakub Skoczen and the core-platform team

Zak Burke, Julian Ladisch

• present conclusions of last week's meeting, namely: backend should handle localization given a locale indicator in a request. it's tradeoffs all the way down; this was seen as the lowest-effort option.
• Question: can new implementations of existing interfaces reuse translations somehow?
  • (this gets at interface/implementation separation)
  • An implication of this decision is that translations are implementation  specific, not interface specific. This is a bit of a can of worms, but it deserves some thought. Permissions, similarly, straddle this divide.
  • In practice, does interface/impl separation matter that much?
  • Would revisiting the RFC process help us here? Would that help us evaluate and make deliberate decisions about the long-term knock-on effects here?
• Does this change our position WRT interface/impl separation? i.e. is it better/worse/same? (thinking it's the same)
• Marc Johnson: this effectively implies that all back-end work that produces an API response needs to include localization as well. Should this be added to the Definition of Done? 
  • do this in one module, then use it as an example for others
  • consistency is crucial here; there must be a single, standard implementation

Axel Dörrer

• 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)
• Tentative proposal: small group to chart out an approach, treat this as an edge module. Idea would be some sort of plug-in architecture that handles basic receipt of AuthN (yes|no) and may map from external attributes to FOLIO attributes. Would then implement plug-in for SAML, with the idea that plug-ins for other AuthN scheme (e.g. LDAP) could be implemented as-needed.
  • Important to have people familiar with authentication systems, Identity Management  and such issues as the team.