[FOLIO-1786] SPIKE: evaluate "init" tokens as a way to trigger system tasks Created: 06/Feb/19  Updated: 20/Mar/23

Status: Draft
Project: FOLIO
Components: None
Affects versions: None
Fix versions: None

Type: Task Priority: P3
Reporter: Jakub Skoczen Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: platform-backlog
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original estimate: Not Specified

Issue links:
Blocks
blocks UIEUS-3 Regular harvesting Closed
is blocked by FOLIO-1953 SPIKE: propose an approach for schedu... Closed
Relates
relates to FOLIO-1781 Change metadata when user performing ... Closed
relates to FOLIO-2551 SPIKE: System and Tenant Level Users... Closed
relates to OKAPI-705 confirm public module support Closed
relates to RMB-320 Updating records containing metadata ... Closed
Sprint: CP: ready for planning
Development Team: Core: Platform

 Description   

TLDR

In FOLIO user accounts are optional to issue API calls, instead FOLIO relies on signed tokens for authentication. User accounts are, however, required to request a signed token in the first place.

More

In FOLIO authentication is based on passing signed tokens between parties (browser, modules, Okapi). Authorisation is based directly on permissions encoded in the signed token or, indirectly, based on permissions assigned to the user account the token points to, both of which are optional.

The only way to request a signed token is to authenticate against a login endpoint. After the token has been issued the client may use it to initiate requests with secured FOLIO endpoints.

Problem

This approach may be problematic when modules would like to call FOLIO APIs without a context of an authenticated client request. Use cases:

  • module makes a request on their own e.g periodically to perform a system task (cron-like behavior)
  • module makes a request during the "init" phase (e.g moduleA needs to bootsrap data in moduleB)
  • module makes a request to another module in response to an unauthenticated request (request made to the unauthentifcated endpoint, example: calls to /login)

Proposed solution

When a module is enabled for a tenant, Okapi issues an "init" call (Tenant API) to the module. Assuming the Okapi installation has been properly secured (this is a requirement for a secured system) the "init" call issued from Okapi originates from a privileged security context (which is required for enabling modules). This privileged context may be downgraded to a less privileged context specific to the module being enabled. This is done by encoding module's permissions (defined in the modulePermission entry for init) in the token passed to the module. The token passed during init can be then peristed by the module to subsequently trigger system tasks (that are allowed within the init's modulePermissions) or the module may request "init" permissions to "create users and grant them permissions" and automatically install a "system" user it needs.



 Comments   
Comment by Julian Ladisch [ 14/Feb/19 ]

The solution proposed above handles different levels of permissions. This is like system users for specific tasks but without such system users accounts.
What about a solution where such system user accounts are actually used? Then we can use the existing ways to deal with permissions, and we have better logging because the specific system user name shows up in the logs.
Example system users: cron system account for patron notices; init system account of a specific module; login system account that checks the login credentials.

Comment by Jakub Skoczen [ 28/Feb/19 ]

Julian Ladisch Correct – you can always use a "system" user, grant him relevant permissions and authenticate API calls. The problem is: when such a user should be created and who should be responsible for creating it? E.g consider a module that would like to periodically trigger some FOLIO API. To trigger this API it requires permissions to do so. The module could "install" a user with a given permission during the "init" phase but to do so it needs to have the permissions to a) create users b) grant them permissions. And, currently, those permissions would have to be granted to... a user that the module should use to authenticate the call to create a user. And so it becomes a chicken-egg problem. We already have a mechanism to grant permissions directly to the module, this proposal only extends this notion to the "init" calls.

How is used by the module is left to the module to decide: the module could request permissions to create users and grant them permission and install a "system" user it needs with appropriate permissions. Or the module could just request the target permissions for the API it needs to call and the token passed during init could be used for making those calls without having to create a system user.

Comment by Jakub Skoczen [ 13/May/19 ]

Adam Dickmeiss we should verify if the token should be expired

Comment by Annika Schröer [ 12/Aug/19 ]

At the moment regular report harvesting (periodical system task, cron-like behaviour) can only be implemented without permissions on the harvester. This could be a security issue.

Comment by Marc Johnson [ 12/Aug/19 ]

Annika Schröer

At the moment regular report harvesting (periodical system task, cron-like behaviour) can only be implemented without permissions on the harvester. This could be a security issue.

What is the report harvester? Or are there many, and if so, can you give me an example?

What do you mean by permissions on the harvester?

Comment by Richard Redweik [ 13/Aug/19 ]

I think Annika wanted to comment the issue link to our ticket UIEUS-3 Closed and not on this FOLIO-1786 Draft . Sorry for that!

The harvester belongs to the eUsage module.
The report harvester is able to fetch counter reports via the sushi protocol. We plan to automate the harvesting task and let it run periodically.
In the current design, the harvester calls its own 'start harvesting' interface in order to start the task. Thus, the harvester will make a request on its own e.g periodically to perform a system task (cron-like behavior).

Comment by Marc Johnson [ 13/Aug/19 ]

Richard Redweik

I think Annika wanted to comment the issue link to our ticket UIEUS-3 Closed and not on this FOLIO-1786 Draft . Sorry for that!

No need to apologise

The report harvester is able to fetch counter reports via the sushi protocol. We plan to automate the harvesting task and let it run periodically.

In the current design, the harvester calls its own 'start harvesting' interface in order to start the task. Thus, the harvester will make a request on its own e.g periodically to perform a system task (cron-like behavior).

This sounds like it could be done with the special _timer interface in Okapi using module permissions.

Comment by Richard Redweik [ 14/Aug/19 ]

Marc Johnson

This sounds like it could be done with the special _timer interface in Okapi using module permissions.

In principle this can be done with the _timer interface. However, we have the following requirement in UIEUS-3:

Each tenant can define:

download schedule (date+rhythm, e.g. monday/weekly, 1st of month/monthly ...)

This is why we thought of a cron-like behavior.

Comment by Marc Johnson [ 14/Aug/19 ]

Richard Redweik

This is why we thought of a cron-like behavior.

There have been some discussions about adding more options to the _timer interface

Generated at Thu Feb 08 23:15:54 UTC 2024 using Jira 1001.0.0-SNAPSHOT#100246-sha1:7a5c50119eb0633d306e14180817ddef5e80c75d.