MODSIDECAR-13: Options for handling modules which call OKAPI
Overview
User story: MODSIDECAR-13: PLACEHOLDER - Spike - Options for handling modules which call OKAPIClosed
Some modules (FE and BE) make API calls directly to OKAPI. On the new platform, these things are going to break. We need to look at the options and decide how we want to resolve this issue.
Okapi permissions usage
Permission | Interface | Required by modules | Notes |
---|---|---|---|
okapi.env.list |
|
|
|
okapi.proxy.modules.list |
|
| can be provided by |
okapi.proxy.tenants.modules.list |
|
| a list of installed modules can be provided by
|
okapi.proxy.tenants.modules.post |
|
| This API cannot be provided, cause mgr-components cannot perform installation of a single module |
okapi.proxy.tenants.modules.enabled.delete |
|
| This API cannot be provided, cause mgr-components cannot perform uninstallation of a single module |
okapi.discovery.get |
|
| Can be provided by |
okapi.version.get |
|
| There is no okapi in the system, this interface cannot be supported |
Note: UI-Developer is not included in the production deployment, according to the README.md file
mod-permissions
requires perms.users.assign.okapi
permission to assign okapi permissions to the user. This permission is hardcoded in the codebase and required in permissionsDesired
section, without this permission - okapi permissions cannot be assigned.
Okapi interface provision using mgr-components
mgr-tenant-entitlement
If the module requires okapi
interface API
allowed
okapi
endpoints are stored inmgr-tenant-entitlements
in Json (key is the permission id, values - is theAuthorization
resource(permission + endpoint)mgr-tenant-entitlements
generates and adds Keycloak resources (for instance,GET /_/proxy/tenants/{tenantId}/modules
)mgr-tenant-entitlements
generates corresponding capabilities (for instance,view + Tenant Modules
with assigned endpointGET /_/proxy/tenants/{tenantId}/modules
)
mgr-applications
mgr-applications
will collect (using HTTP calls) okapi interfaces from the mgr-components
and will include them in the module bootstrap information. This service will provide endpoints with new field pathOverwrite
, so sidecar can overwrite the path to call mgr-components:
{
"methods": [ "GET" ],
"pathPattern": "/_/proxy/tenants/{tenantId}/modules",
"pathOverwrite": "/entitlements/{tenantId}/modules"
"permissionsRequired": [ "okapi.proxy.tenants.modules.list" ]
}
mod-roles-keycloak
Requires the same prevention measure to prevent assigning system (okapi) capability to anyone.
folio-module-sidecar
To cover all cases except ui-developer
, all modules can call sidecar for GET /_/proxy/tenants/{tenantId}/modules
, and sidecar will proxy request according to the diagram.
In-place solution to support okapi interfaces
Requires a lot of changes in all modules, including manager components
Can be difficult to maintain in the future cause of the complexity of this approach
Okapi API Facade
This module can be part of app-platform-minimal and it will work as a light-weight router to mgr-components.
In comparison with the first approach - there is no need to modify the existing codebase in mgr-applications
, mgr-tenant-entitlements,
and folio-module-sidecar
. This module will belong to the app-platform-minimal
and it will provide supported okapi interface, or all of them, but only partially implemented. Other calls to the service will return 501 Not Implemented
.
Straight-forward solution which aligns with the Folio microservice approach
Lightweight, this service won’t require connection to the database, enabled tenants will be handled by sidecar
Okapi modules are defined in module information, all the data will be handled by mgr-components
Additional microservice to deploy
Excluding Okapi interfaces from the system
mod-data-export-worker
and mod-bulk-operations
use the same approach to retrieve custom fields by calling okapi to identify the version of deployed mod-users
for specific tenants.
If one tenant can have only 1 version of the module - we can set up Kong Gateway routes to include only the module name instead of the module version, and Okapi request becomes obsolete.
Okapi modules are defined in module information, all the data will be handled by mgr-components
Okapi call no longer required by module
Requires change of community codebase
Works only with Kong and sidecar
Conclusion
Partially okapi interfaces can be supported by the platform, excluding all interfaces related to the module installation (application installation is only supported) and deployment (for example, env variables).
UI-developer implementation relies on okapi interfaces, so there is no guarantee that the functionality of this module can be fully supported