[FOLIO-1713] Edge module support in FOLIO/Okapi Created: 17/Jan/19  Updated: 03/Jun/20

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

Type: Umbrella Priority: P4
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:
Relates
relates to OKAPI-652 Design for global modules Open
relates to OKAPI-314 public URI Open
relates to FOLIO-1630 include "edge" modules in daily snaps... Closed
relates to OKAPI-705 confirm public module support Closed
Sprint:
Development Team: Core: Platform

 Description   

Technical design/discussion document for Okapi support for hosting Edge modules:

https://docs.google.com/document/d/1pg6lj5UxwcWrrex8xlS-w8eKzIy7Ge0PAPVb7l3n9v4/edit?ts=5b71b9c3#



 Comments   
Comment by Jakub Skoczen [ 28/Jan/19 ]

Adam Dickmeiss VBar Craig McNally as discussed on a special TC session on Friday we will add deployment capability and add existing edge modules (listed on FOLIO-1630 Closed ). The Okapi functionality for hosting edge modules is independent and does not block the task.

Comment by Jakub Skoczen [ 28/Jan/19 ]

Craig McNally Adam Dickmeiss and I discussed how the institutional user (and the Okapi token) is provisioned for the edge-modules? Is this something that needs to be done manually right now? Assuming the "edge" modules can support the tenant API, we are wondering if this process can be done automatically, when a new tenant is created in Okapi (through the lifecycle callback)?

E.g:

  • on tenant creation Okapi calls the tenant init callback on the edge-module
  • the provided token could allow the edge module to create an inst user
  • the edge module can use the token to bootstrap the inst user for the newly created tenant.

Or something roughly along those lines.

Comment by Hongwei Ji [ 29/Jan/19 ]

Jakub Skoczen, at tenant creation or during enabling module for tenant? I assume it is the latter. Since the newly created institution user also needs proper permission, would the provided token be used to do that as well? Is there a way in the token to control which permissions can be assigned to the new user (not okap.all for sure)?

Comment by Craig McNally [ 29/Jan/19 ]

It's an interesting idea... A few comments:

  1. There's nothing special about the "institutional user"... these are just standard folio users w/ particular permissions - e.g. mod-rtac.all. IMO whatever we do here, we shouldn't prevent a tenant from manually setting up these users as they see fit. For instance, if they want a single user that's used by all of their edge APIs, they should be able to do so. If they want separate users for each edge API they should be able to do that as well.
  2. The edge APIs don't currently define a tenant init API this would need to be added
  3. Do we really want to force edge modules to require the users interface?
Comment by Jakub Skoczen [ 30/Jan/19 ]

Hongwei Ji Correct, when module is enabled for a tenant.

Craig McNally Agree. Almost. It looks like for the existing edge modules the convention is that "edge" API is implemented directly in the Okapi module (mod-rtac, mod-oai-pmh) with granular permissions for each endpoint (oai-pmh.records.item.get, etc) and a single permission set (oai-pmh.all) that is then granted to the "institutional" user. The thing that is "special" for the user is the permission set that needs to match what the "edge" module needs. But how do the operator know this? How do they know that the insitutional users for "edge-oai-pmh" needs "oaipmh.all"?

( I am not sure I understand what you mean in #3)

Comment by Hongwei Ji [ 30/Jan/19 ]

What I was trying to say is that do we really want an edge module to create any users and assign any permissions to the users? Unless we have a fine control that okapi token, it seems loose from security perspective.

Comment by Craig McNally [ 30/Jan/19 ]

( I am not sure I understand what you mean in #3)

Jakub Skoczen I mean that if the edge API is going to be creating users, each edge API will need a dependency on the users interface, which isn't a huge deal, but it does mean additional dependencies for all Edge APIs.

It looks like for the existing edge modules the convention is that "edge" API is implemented directly in the Okapi module (mod-rtac, mod-oai-pmh) with granular permissions for each endpoint (oai-pmh.records.item.get, etc) and a single permission set (oai-pmh.all) that is then granted to the "institutional" user. The thing that is "special" for the user is the permission set that needs to match what the "edge" module needs. But how do the operator know this? How do they know that the insitutional users for "edge-oai-pmh" needs "oaipmh.all"?

I see your point. The edge APIs do provide a module descriptor with required interfaces; This proabably isn't ideal, but typically there's a .all permission set associated with each interface. By convention we could probably say the institutional user requires the .all permission associated with each of the edge API's required interfaces. In some cases that might be a little overkill, but not by much. Edge-patron for instance has a requirement on the users interface so it can lookup a patron's uuid via the externalSystemId provided. Giving the institutional user users.all (or whatever the equiv. is) is probably overkill here, but it's much better than granting them okapi.all

Whether or not it's too onerous to place this burden on the "operator" comes down to who would typically be doing this provisioning... Is it safe to assume that if you're creating tenants you're familiar enough with the administration of FOLIO that you'd A) know about this convention - ideally it would be documented somewhere and B) know how to determine the required interfaces and derive the appropriate .all permission sets that the institutional user(s) would need?

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