Page Comparison

...

2. scheduled job is triggered for /timer-url-A endpoint. mod-scheduler prepares a request and put impersonated token for the system user into x-okapi-token request header. Then the request goes from mod-scheduler to its sidecar, which in turns forwards the request to Kong, since the request URL is not registered inside sidecar’s egress routing table

   1. Kong receives the request and searches for known routes associated with the given URL and method.

      • Once the route is found, the request will be forwarded to target Module A sidecar

   2. Module A sidecar receives the request and as usual performs several steps to authorize request:

      • get token from request header

      • parse token

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

   3. Finally Module A sidecar calls /timer-url-A interface of the module and the chain of calls succeeds

3. External actor (UI or another system) attempts to request /timer-url-A system interface.

   1. Kong performs the same steps to handle the request as it does in case of a call from mod-scheduler:

      • the route is searched in the list of registered routes

      • once the route is found, the request will be forwarded to target Module A sidecar

   2. Module A sidecar receives the request and tries to authorize request in Keycloak

      • external actor has no permission to access /timer-url-A system interface, thus Keycloak will reject the call with "403 Forbidden" error.

Implementation details

The system already supports the above flow except one piece: request authorization for _timer interfaces in sidecar. Currently timer interfaces are treated as system ones, along with _tenant interfaces. For system interfaces in general sidecar skips token analyses and authorization procedures, but from now on it shouldn’t do this for timer interfaces.

The logic to verify user token and access grants resides inside classes called filters. They have shouldSkip(RoutingContext rc) method to understand whether or not a filter should be applied to particular request. Method example from KeycloakAuthorizationFilter:

...

So to enable authorization for timer interfaces shouldSkip(RoutingContext rc) method should be modified in several filter:

• KeycloakJwtFilter

• KeycloakTenantFilter

• KeycloakAuthorizationFilter (the main one responsible for sending authorization request to Keycloak)

Pros

• the implementation is expected to be reasonably simple. it will affect only MTE and Kong

• mod-scheduler and folio-module-sidecar remain unchanged

• the approach can also address Public/Private API problem

Cons

• plugin development in Kong requires knowledge of Lua language but Eureka team has limited experience with it

Option 2

Have mod-scheduler send egress requests to it’s sidecar like every other module, and add a switch to the module-sidecar which indicates it should retrieve ALL bootstrap info at startup, and consume all discovery events.

Pros

• No special handling required in Kong

• No security concerns

Cons

• the sidecar needs to retrieve and manage discovery and interface/endpoint information for all APIs in the system.

...