0010-eureka
Start Date | Oct 21, 2024 |
End Date | TBD |
Contributors | @Craig McNally @VBar |
Status | RFC Preparation |
Summary
The Folio Eureka Platform (henceforth referred to as Eureka for brevity) represents the next generation of Folio’s architecture which allows the project to operate at enterprise scale and expand its solution space. It seeks to replace custom-developed core components found in the original Folio architecture, with feature-rich, best-of-class, specialized open-source components. The need for this has become critical as Folio has become widely adopted, and particularly in ever increasing numbers in complex configurations such as consortia and national libraries.
Motivation
It became increasingly clear that requirements imposed by some high-profile libraries adopting Folio were going to be very difficult, if not impossible to meet on the current platform.
Scope
This RFC is intended to cover all aspects of Eureka at a high level. This includes:
Authentication
Authorization
Sidecars
API Gateway/Routing
Dynamic Scheduling/Timers
Role Based Access Controls
Application Formalization
Covered in more detail here: 0005-application-formalization
Application Composition is Out of Scope
Detailed Explanation/Design
New Components
The Eureka platform introduces several new components. These will need to undergo some evaluation process. However, there is insufficient time in the proposed timeline to use the standard TCR/New module evaluation process.
folio-kong - API Gateway, CORS
folio-keycloak - Authorization, Authentication
mgr-applications - Application (and constituent module) registration, Discovery information
mgr-tenants - Tenant management
mgr-tenant-entitlements - Application/Tenant entitlements
folio-module-sidecar - Authorization, module-to-module request routing
mod-roles-keycloak - Roles and policies
mod-users-keycloak - Bridges the gap between user records in folio and in keycloak
mod-consortia-keycloak - Alternative implementation of the
consortia
interface, compatible with Eurekamod-login-keycloak - Alternative implementation of the
login
interface, compatible with Keycloakmod-scheduler - Static and Dynamically defined timers
mod-okapi-facade - Partial implementation of the
okapi
interface, primarily to support modules which call okapi APIs to get a list of entitlements, tenants, etc.ui-authorization-roles - User interface for role management
ui-authorization-policies - User interface for policy management
ui-plugin-select-application - Plugin for selecting/unselecting applications. Used by ui-authorization-roles.
stripes-authorization-components - Components to be used by modules and applications that handle Authorization (ui-authorization-roles, ui-authorization-capabilities, etc.) duties
application-poc-tools - Shared library used by many of the components listed above. Yes, it should be renamed.
folio-flow-engine - Shared library used by some of the manager services
folio-keycloak-plugins - Keycloak extensions/plugins
Deprecations
The following could be deprecated/archived once Eureka has been fully adopted and these components are no longer within the support period:
Okapi - Functionality has been delegated to various single-purpose components
folio-kong
folio-keycloak
folio-module-sidecar
mgr-tenants
mgr-applications
mgr-tenant-entitlements
mod-scheduler
mod-okapi-facade
mod-authtoken - Replaced by Keycloak/Sidecars
mod-login-saml - Replaced by Keycloak
mod-consortia - Replaced by mod-consortia-keycloak
mod-login - Replaced by mod-login-keycloak
mod-permission - Replaced by mod-roles-keycloak
Slightly different from the components above in that it’s included in app-platform-minimal. Mod-permissions is needed for migration APIs used when moving to the Eureka platform. After that, it’s no longer needed. So, we need to be sure everyone has fully adopted Eureka before removing it from app-platform-minimal along with the migration APIs.
Benefits
Maintainability
By adopting trusted open source software like Kong and Keycloak, Folio can focus their development effort on library business logic, leaving the API gateway and Security code to the experts.
Security
Improved SSO integrations
Support for multiple identity providers
Single logout
Federation support
etc.
Use of standard protocols (OIDC, OAuth2, etc.)
RBAC support
Policies allow for greater control of who can do what, when, from where, etc.
Provides a better UX for managing privileges (Grid instead of flat list of permissions/permissionSets)
Additional features like MFA, LDAP/AD integration, etc.
Enabler for independent application lifecycles
Application-level packaging (application formalization)
A step toward the envisioned app stores / application marketplaces
Improved system user management
Modules no longer need to create, manage, and use system users. The platform handles this instead.
Configurable structured transaction logging (https://github.com/folio-org/folio-module-sidecar?tab=readme-ov-file#logging-configuration )
Risks and Drawbacks
Rationale and Alternatives
Timing
We would like to get the Eureka platform formally approved and adopted by the Folio community for the Sunflower release.
Unresolved Questions
Keywords