Page Comparison

...

In general, this option repeats the idea of security and principles described in option 1.2 of the spike https://folio-org.atlassian.net/wiki/x/BACNCg, but eliminate the Kong from the timer flows.

The following diagram displays the main components and actors involved in the flow.

Description

This option introduces a new component, mgr-discovery, that acts as a facade for the Sidecars and provides a single point of interaction between Them and the mgr-* components. Sidecard will use mgr-discovery to read all bootstrap info related to the FOLIO module the Sidecar serves and dynamically retrieve discovery information that will be useful for timer routings.

Timer Flow:

1. mod-scheduler prepares a request and puts impersonated token for the system user into x-okapi-token request header. Then the request goes from mod-scheduler to its sidecar.

2. Because Sidecar (mod-scheduler) has dynamic routing enabled and the requested route is not known, it calls the mgr-URLs discovery to resolve the discovery information.

3. mgr-URLs discovery calls mgr-Tenant-Entitlements to resolve the actual module's version.

4. mgr-URLs discovery calls mgr-Applications to retrieve the actual discovery information that points to the Sidecar (Module A).

5. Sidecar (mod-scheduler) dynamically routes the request to the Sidecar (Module A).

6. Sidecar (Module A) authorizes the request to Module A.

   1. get token from request header

   2. parse token

   3. call Keycloak to evaluate permissions. Since the system user has access to all resources, authorization will be successful

7. Sidecar (Module A) forwards the request to Module A for processing.

This option introduces a new component, mgr-URLs, that plays a critical role in the routing mechanism for scheduled timer calls within the Folio system. Its primary function is to maintain and manage a cache of routes, which includes resolving the actual routes and versions of modules based on the tenant context.

Key Functions:

1. Routes

Key Functions:

1. Bootstrap info reading:

   • When a request for bootstrap data is received, the module mgr-discovery performs calls to mgr-Tenant-Entitlements and mgr-Applications to collect and compile all the information needed for the Sidecar.

2. Routes Resolution and Cache with Expiration Policy:

   • Purpose: The module mgr-URLs module discovery maintains a cache of routes that includes information about various system/timer interfaces and their respective routes. This cache has an expiration policy to ensure that the information remains up-to-date and valid.

   • Functionality: When a request for a specific route (e.g., /timer-urlA) is received, the module mgr-discovery checks its cache for the corresponding route. If the route information is available and valid, it proceeds to use it. If the information is expired or not found, the module queries relevant systems to fetch and update the route information.

   Route Resolution:

   • Resolving Routes: The module resolves the actual route for the requested URL, ensuring that the correct path is used for system/timer calls. This involves determining the correct endpoint based on the module version and the specific tenant making the request (e.g., tenant Diku).

   • Integration with Other Modules: It interacts with mgr-Tenant-Entitlements and mgr-Applications to resolve the module version and obtain the correct route information. This ensures that the requests are directed to the appropriate module version and interfacefetch and update the route information.

3. Lightweight and Simple: the mgr-URLsdiscovery module does not use any persistent storage and integrates only with mgr-Tenant-Entitlements and mgr-Applications

4. Single Integration Point for Sidecars: Sidecars will interact with the mgr-discovery only, which will simplify the Sidecar implementation as it no longer has to integrate with different mgr-* modules.

Pros

• Kong is excluded from the timer workflow. The system/timer interfaces are not configured in Kong and are not available from the outside.

• The implementation is relatively simple. it will affect only the sidecar and a new mgr-discovery module

• The Sidecar’s codebase will be simplified as it will interact with the mgr-discovery module only and the rest of the complex logic will be encapsulated in the mgr-discovery

• No need to track the timer interface changes as the discovery info will be resolved dynamically and stored in the cache with a short retention time.

• No need for the sidecars to get ALL discovery information, only what’s required, when it’s required.

• Protects timer interfaces in a standard way via Keycloak authorization, like all other resources

• Can be extended later to support more accurate resource-based access as opposed to “all resources“ access

Cons

• Multiple ways for sidecars to get discovery information when “Dynamic Routing“ is enabled.

...

...

...

...

...

...

...