[MODOAIPMH-243] update edge module institutional user permissions Created: 05/May/20  Updated: 22/Dec/20  Resolved: 22/Dec/20

Status: Closed
Project: mod-oai-pmh
Components: None
Affects versions: None
Fix versions: None

Type: Bug Priority: P3
Reporter: Ian Hardy Assignee: Kruthi Vuppala
Resolution: Won't Do Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original estimate: Not Specified

Issue links:
Defines
defines UXPROD-2740 Stabilize OAI-PMH functionality Closed
Relates
relates to FOLIO-2583 Spike: Distributed configuration Open
relates to FOLIO-2551 SPIKE: System and Tenant Level Users... Closed
Requires
is required by EDGOAIPMH-43 Connect to mod-configuration in edge-... Closed
Sprint: Concorde - Sprint 104
Story Points: 0.5
Development Team: Concorde

 Description   

The edge module user needs some additional permissions:

for edge-oai-pmh:
configuration.entries.collection.get

I also noticed edge patron also has "circulation.requests.item.get" in the README, but we're not giving that.



 Comments   
Comment by Ian Hardy [ 05/May/20 ]

Hi Dmytro Popov we had a couple of questions. When we first set up edge modules we gave the institutional user "diku" in this case permissions to the corresponding Okapi module. For example, the user for edge-oai-pmh gets oai-pmh.all from mod-oai.pmh. So the edge module talks to its partner Okapi module (mod-oai-pmh) in this case for everything it needs.

Is there a configuration that needs to apply to edge-oai-pmh module that's different than what would apply to mod-oai-pmh? It's certainly possible to apply the additional permission to the user if needed (I've noticed this is already done for edge-patron for example).

Comment by Dmytro Popov [ 05/May/20 ]

We are working on a feature that requires making calls to mod-configuration from inside the edge-oai-pmh module and this is not RMB-based module that uses the user diku to make calls to OKAPI. The mod-oai-pmh is a regular rmb module that is registered in OKAPI. In Folio UI we create settings in mod-configuration and some of them need to be read in edge-oai-pmh, for instance switching edge API on/off. There are others too.

Comment by Jakub Skoczen [ 05/May/20 ]

Dmytro Popov could you expose those setting to edge-oai-pmh via a webservice in mod-oai-pmh and grant access to mod-configuration via modulePermissions?

Comment by Dmytro Popov [ 06/May/20 ]

Jakub Skoczen That would result in sub-optimal resource usage and http round-trips, which would increase load on the system. Moreover, it would have a negative effect on our deliverables for Q2 as we would need to rewrite the existing mechanism.

Here is a couple of examples:

  • Consider switching edge api on/off based on a configuration setting.
    We either make one call to mod-configuration and respond to the edge api client with an error. Or we make a call to mod-oai-pmh, it makes a call to mod-configuration, it then finds a setting and responds to edge. Then edge responds to the client with an error. This results in an extra http request and load on the system. And as it happens there is no web service in the oai-pmh module and that would require additional effort.

Additionally there are configuration settings that need to be processed in the edge module:

  • According to the requirements and their current implementation, there are validation checks against inbound requests in the edge module before getting data from Folio(mod-oai-pmh). We are adding new validation checks and, according to the business rules, some of the checks depend on the settings in mod-configuration and some do not.

Could you share your concerns on account of granting the necessary permissions to the edge module?
Alternatively, creating another user for edge-modules would solve the issue. What do you think about it?

Comment by Jakub Skoczen [ 06/May/20 ]

Craig McNally let's link that with the mod-configuration issue about storing sensitive information (if one exists)

Comment by Craig McNally [ 07/May/20 ]

Jakub Skoczen - done.

Just my 2 cents here... Granting the permission to the institutional (diku) user is the easy thing to do here, and really it's safe unless the diku credentials are compromised. The resulting token is never exposed to the end user calling the edge API and it's the edge API that's making the calls into FOLIO.

I've voiced my concern over the use of mod-configuration before (elsewhere), but that mostly concerns the storage of sensitive information. I do think a distributed configuration model is really a better way to go in general (see FOLIO-2583 Open linked above).

Final note: This overlaps with another topic that's on the TC's architectural blueprint topic list - system and institutional users. Ideally we wouldn't have to manually provision these institutional users. To tie this in with that conversation I've linked this to another story - FOLIO-2551 Closed

Comment by Dmytro Popov [ 07/May/20 ]

@All Thank you for your time. The security breach that might happen by granting additional permissions to diku made me think it is much better leave mod-oai-pmh talking to Okapi then granting additional permissions to the edge module.

Comment by Kruthi Vuppala [ 17/Dec/20 ]

After reading the comments and corresponding stories, looks like mod-configuration is not a dependency on edge-oai-pmh anymore. This is the story that moves the config logic to mod-oai-pmh: https://folio-org.atlassian.net/browse/MODOAIPMH-131.
We don't need this story anymore, as the description is not valid

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