[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: |
|
||||||||||||||||||||||||||||||||
| 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:
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. |
| 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 ] |
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
The harvester belongs to the eUsage module. |
| Comment by Marc Johnson [ 13/Aug/19 ] |
No need to apologise
This sounds like it could be done with the special _timer interface in Okapi using module permissions. |
| Comment by Richard Redweik [ 14/Aug/19 ] |
In principle this can be done with the _timer interface. However, we have the following requirement in UIEUS-3:
This is why we thought of a cron-like behavior. |
| Comment by Marc Johnson [ 14/Aug/19 ] |
There have been some discussions about adding more options to the _timer interface |