Page Comparison

Enter questions here:

Big picture

• What is the concrete motivation for any of this? What problems does it solve? Why can they not be solved within the existing architecture?
• Is the main driver a rework of authentication/authorization? Do we have benefits in this rework?

Authorization

• How do existing permissions defined by modules work with Eureka architecture (Kong, keycloak, sidecars etc) e.g. what checks that a client can make a request to a module? (MJ)
• Many universities and libraries use SAML/Shibboleth, advanced (!) LDAP, and/or OpenID Connect (OIDC) for authentication. The respective Kong plugins are not OSS but require a monthly payment: https://docs.konghq.com/hub/?category=authentication What effort is needed to support these authentication methods without these plugins but with OSS software? (JC/ML/JL/Sysops)
• Mutual TLS (mTLS) is a state-of-the-art authentication method available for more than 20 years that at least some universities/libraries need to use to protect their systems against attacks in the next years, for example for machine-to-machine communication. However, Kong's mTLS plugin is not OSS: https://docs.konghq.com/hub/kong-inc/mtls-auth/ How can a FOLIO system that uses Kong can support mTLS without paying for that plugin, what effort is needed? (JL)
• The permissions set up in Eureka seems really different from the permissions set up in current FOLIO, will modules be able to handle both without changes? (JC)

Development

• Do module to module requests go direct (using sidecars, rather than via okapi) when Eureka architecture is used? (MJ)
• How do applications work with Okapi (instead of Eureka architecture)? (MJ)
• What fulfils the role of the Okapi APIs e.g. to install / upgrade modules in Eureka (when okapi is no longer present) (MJ)
• Will it be possible to document for all dev teams (including current teams not involved in Eureka and future teams) ways to include any environmental switches needed to have their app run in both a Eureka platform and non-Eureka platform? (JC)
• Is there anything that needs to change in modules to be able to run on both okapi and Eureka that can't be handled by environmental variables? Every place where it says Okapi in the code can you just point that at Kong instead without changing the module? (JC)
• Will everything on a Eureka platform need to be an application? If a team develops primarily for a non-Eureka audience, will those on a Eureka platform be able to figure out how to write an application descriptor for those modules without help from the team? Should the community provide either descriptors or guidance for doing this? (JC)
• What will be the impact of Kong on locally developed integrations that currently call Okapi? What will level the of change be (like find replace okapi/kong or more)? (JC)

Today's notes:

• Motivation here - to a large extent about authentication. Different version of core platform needed for higher security environments. For ex, need end to end encryption, touches how we do authorization.  Partly revamping some of the things we did in the past with more modern choices, as happens with software dev
• Slide illustrating Kong flow
  • A lot questions about Kong. Kong is just an API gateway, Okapi extends beyond that. Kong only does the gateway, Keycloak takes on the authentication.
• Separation of authorization from the gateway. Authorization barrier is located in the sidecars.
• Kong isn't responsible for auth, therefore the Kong auth plugins aren't needed, Keycloak with the sidecar handles the auth.
• Kong won't handle the Kafka interaction
• What is a sidecar? Is it a kubernetes sidecar? No not specific to kubernetes. Additional container that runs along the module container. Enforce authorization, tenant enablement checks. What ensures the module communicates via the sidecar?
  • Quarkus is what we use for the sidecars
• Slide of Eureka based authorization
  • Kong registers the URL for the sidecar so that is how the request is routed, Kong doesn't know about the module, just the sidecar
  • Sidecar performs auth with keycloak then passes request to module then returns response
• What keeps modules from communicating directly?
  • We don't prevent it but want the requests to go through the sidecars. One module's sidecar communicates to the other module's sidecar
  • In Okapi there is an x-okapi-url header. In new platform put the sidecar to populate that header with its own host, its own x-okapi-url. The sidecar knows how to proxy that call
• Keycloak provides login page in new. platform, can make it look like the old login page. Some adjustments in stripes, a branch with minor changes. Instead of local login, use keycloak page, keycloak interacts with mod-login keycloak, gets token for stripes
• Authentication keycloak, authorization side cars. side cars have user and request contexts, sends to keycloak.
• How much code is involved in  the sidecars? Is it mostly configuration? where do the sidecars live? in module repo? central repo?
  • Quarkus sidecars
  • One generic sidecar codebase, develop once and reuse over and over
• Are Kong and Keycloak interchangeable with other products? Are there generic protocols in these products to allow them to be switched out by sysops?
  • At run time OpenID connect is used. Challenge would be when configuring/during deployment. Applications need to be registered which gets into specific models provide by keycloak for instance. Do need some alignment between FOLIO and inner workings.
  • For Kong at least at runtime there's nothing specific to Kong, it proxies request appropriately, manager services and Kong creates routes and services, you'd have to make adjustments in the manager services to use a different gateway. Not plug and play. Same for Keycloak but more work involved to use something else because there are more interactions. Would require code changes.
• Can you run sidecar centrally instead of on every module so you could save some resources? In theory possible but haven't really considered. Might have to do additional things to account for that. Want to position this platform to work with the 'application' future we have envisioned with FOLIO. There's some close relationship between the module and the sidecar.
• Keycloak and Octa? - not so much replacing Keycloak but if using Octa, Octa would be an identity provider
• A lot of the motivation is about authentication/authorization, being able to support multiple providers. Keycloak can support multiple IDPs in a single tenant installation
• As you enable. applications the manager services set up the routes. Use Kong api to configure  the routes. Could add an abstraction later at some point if needed, haven't considered yet. Tried to keep this generic and tied to specific container management technology. Tried to touch as little folio code as possible.  Can you run outside of kubernetes? It would be hard to manage. Will be twice as many containers as today. Seems like even today need container management system. Running on a single server hard now. Being more specific to a certain platform might make things easier.
• How are these part of application formalization? Why have both of these conversations at the same time? Could do app form without these changes? These might be good changes to but why not handle them separately?
  • They are somewhat separate. This is an effort around authentication and using mature components.
  • While doing this assume application formalization is coming so that's why put application manager and put applications in there
  • Haven't formalized any applications really yet. Adoption of application formalization is sort of separate, but this platform will be ready for it
• Kong enterprise - we don't need it because we aren't using anything that doesn't exist in the community version, don't need the plugins
  • Haven't run into anything that was a show stopper that required the non-free versions, would have dropped if they did encounter that
• Is the plan to have Kong/Keycloak/Eureka run side by side and then customers have a choice?
  • Right now have two working platforms that use the same applications, modules and so forth
  • Would like the community to accept it and adopt it, but doesn't need to be pushed in urgent manner into Ransoms
• If this will live alongside current toolset will modules be able to be maintained as they are today without needing special work to have modules work in both platforms
  • Eureka introduces things, sidecars being one. Development would need to happen. Shouldn't be incompatible, some development would need to be done
  • If FOLIO classic wanted to use application manager, they would need work
• Backend modules worked out of the box as is in Eureka. If following usual FOLIO guidelines should be all set
• Eureka Core platform has to be compatible with existing modules in FOLIO
• Will there be overlap time where you could run current FOLIO release in both ways?
  • Wouldn't see modules developed specifically for this platform
  • Will there be a Kong release and a Okapi/classic release?
    • Community will have to figure out if have two platforms supported
    • Especially with potential for smaller application. releases
• None of the backend modules had to be changed. Front end? Did need branch of stripes with some differences for Keycloak for instance. Stripes core and also UI-users, introduced some "if interface" so you get the roles from Keycloak if that is what you are running. Made some modifications to the versions page so it has hierarchical layout with the application. Changes were made to take advantage of architecture
• Integration - have lots of things that integrate with Okapi. What sorts of changes will integrations need to make? 
  • APIs proxied by Okapi shouldn't matter, Kong will just send the request to the right module, shouldn't need changes. External should be unaware of the different
  • Won't integrations need to change their auth calls? Think we have tried to maintain the same endpoints with the different flavors to maintain the apis, still can use refresh token rotation.
  • mod-login-keycloak: alternative implementation, drop in replacement for mod-login
  • tried to make as backward compatible and easy to adopt as possible
• APIs for new tenant management application and it doesn't look like have reimplemented okapi so things done for registering modules would have to be redone?
  • Okapi apis not directly applicable because of working with applications, not modules.
  • Tried to value add: tenant attributes to store more metadata about tenants as example
  • Understand handful of places in FOLIO like dev tools in the UI that make calls to internal APIs to check various things, to support that looking at creating Okapi facade component which may be helpful for this, not sure. Depends on how extensive facade is and what the tooling does
  • Just flagging won't be impactless on hosting providers
  • Not being prescriptive about drop dead date, up to providers if they want to adopt this and what their timeline would be
• Is okapi gone?
  • Yes
  • How is versioning and module compatibility handled?
    • Application manager registers application
    • Tenant manager manages tenants
    • Tenant entitlement brings them together and that has a lot of the dependency checks
    • Happens at the application level, will check to see if at interface level as well,  maybe bit of both
• Would like to do another session. Thanks  to Craig and Vince.