[FOLIO-377] Permission model design Created: 09/Nov/16  Updated: 15/Feb/23  Resolved: 15/Feb/23

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

Type: Umbrella Priority: P3
Reporter: Heikki Levanto Assignee: Jakub Skoczen
Resolution: Done Votes: 0
Labels: sprint4, sprint5
Remaining Estimate: Not Specified
Time Spent: 3 hours, 30 minutes
Original estimate: Not Specified

Issue links:
Relates
relates to OKAPI-267 Define permission sets in ModuleDescr... Closed
relates to OKAPI-268 Permission loading interface in Okapi Closed
relates to FOLIO-482 mod-permissions to implement the modu... Closed
relates to OKAPI-269 group routingEntries under appropriat... Closed
Sprint:

 Description   

Summary of permission-related questions that came up when Filip showed his view of the permission system.



 Comments   
Comment by Heikki Levanto [ 09/Nov/16 ]

Things that came up during the demo and discussion:

  • We need to add some metadata to permission sets: Human readable name, Tags, Description
  • We need to be able to query permission sets by the above fields, also partial matches for filtering etc.
  • We also need to be able to query which permission sets contain any given permission, especially for the case when a user sees a message that something is not allowed because this permission is required, the admin needs a quick way to decide which is the proper permission set to enable for that user.
  • We need to be able to query which users have any given permission or permission set. Especially for the case when the admin wants to remove a permission from a set, he needs to see whom that would affect
  • We may also need a way to query unused permission sets, so that it is possible to clean up an old installation.
  • Modules should define the low level permission sets, basically most of the sets that make sense within the module itself. Up to a permission set that covers everything in that module.
  • This is probably best done within the ModuleDescriptor, and imported into the permission system when a module is installed and enabled for a tenant
Comment by Heikki Levanto [ 09/Nov/16 ]

Further things that came up in our breakout session (Kurt and Heikki):

  • The permission bit names should probably be prefixed with the module that generated that permission. We hope we do not need to include module versions in this. Still uncertain if the prefix should be the name of the module, or the name of the interface the module provides.
  • We could probably get away with enabling only permission sets for users, the lowest level CRUD permission bits are probably only useful for API level things. There can be a job that deletes expired users, it should not necessarily have access to read the users sensitive data. But any human who needs to delete a user, will need to view it first, to make sure it is the right one.
  • Also, if we add the human-readable metadata to permission sets, but not to individual permission bits, we can only operate with permission sets in the UI. That is probably all right. If need be, we can define a set that contains only one permission.
  • What do we do with the human-readable stuff (names, descriptions, tags) in different languages? Do we keep all possible translations in the system? Do we arrogantly start with English only, and let the librarian make their own translations?
  • Because the display names may be edited, we need unique IDs for the permission sets, so we can refer to them.
  • When a module is installed and enabled for a tenant, the permission sets need to be imported to the permission system.
  • What happens if the user edits the displayable things in a permission set, and the module gets deleted, and then reinstalled? Compare Debian's "apt-get remove" and "apt-get purge"
  • We can have dummy meta-modules, that only have a module description with permission sets and dependencies. For example a "front desk" that depends on users and circ modules, and provides permission sets that cover stuff from those two.
Comment by Jakub Skoczen [ 17/Nov/16 ]

Note: decide with Kurt to file more specific issues for sprint3.

Comment by Jakub Skoczen [ 18/Nov/16 ]

Guys, a little clarification about the model. Let's make sure we are on the same page before Kurt and Heikki goes off implementing stuff.

The permissions reported by the modules in the ModuleDescriptor (currently, could potentially be moved) are:

  • part of the module interface – that's the conclusion we reached on #development, major reason is the fact that the client/UI needs to know them at implementation-time to e.g control display or look of certain elements (e.g no delete button if no delete permission)
  • cross-tenant (global) and immutable – since they are part of the interface and UI modules are coded specifically to address them, they must be globally understood (apps must be able to operate in any tenant environment/configuration). This means tenants should not be able to modify them in any way (this will cause confusion and result in differences from tenant to tenant), most likely not even modify the "static" metadata (like display name and description) captured in Module Descriptor. But we will allow things like tagging, for the benefit of the tenant admin, it must be clear though, that "tagging" is purely local information.
  • modules can also report "static" permission sets – e.g to conveniently and logically group together permissions (e.g delete/create/update as edit permission). However, since they are part of the module interface, similarly to the granular permissions they should be immutable – once loaded to permission subsystem in FOLIO, tenant admins should not be able to modify them or change their contents. This also means that module developers can "grow" or modify those sets with new version of the modules as they see fit as ease installations of new version of a particular module (e.g by providing permissions for new operations in the existing sets). It also means that module developers need to be extremely careful not too screw up (as with any other interfaces).

Now, for the permission set as managed through the "permissions" module:

  • the initial granular permissions and sets are populated from the module descriptors (interfaces) – but as discussed above they all remain immutable (besides the "tagging" option)
  • new sets can be created and include granular permissions and other sets (both user-created and immutable ones from modules) – on the surface those are indistinguishable (but there should be a way to indicate that to the user somehow?) especially for the purpose of assigning them to Users (or any other entities that need permissions). Creating granular permissions makes no sense and should not be supported – granular permissions only make sense in the context of the module that implements them.
  • tenant-created sets, immutable sets and granular permissions, can all be assigned directly to users

Now, I think, from the point of view of simplicity, especially in terms of treating everything (tenant-created sets, immutable sets and granular permissions) as the same thing when performing assignments, this is a really powerful metaphor. And one that fits quite well with the prototype/mock-up. My fear is that it can be quite confusing for users (or whoever wants to grasp the model) since we are throwing a lot different eggs in the same basket. Thoughts?

Another thing to consider, we don't need to get to the bottom of this now though, is how the interface-level permissions (so the immutable granular permissions but also most likely the immutable sets) are going to be returned down to the UI. We will need this to implement conditional display branched on permissions in the UI. The tenant-created sets are uninteresting on the UI (since the UI has no knowledge of them), which btw, is another reason why we should consider treating them differently. If the list gets very big, we can attempt to trim it by having each UI component "express" what permissions they are ever interested in.

Comment by Heikki Levanto [ 16/Dec/16 ]

Just a stray thought: The fixed permissions need to be fixed when defined in a ModuleDescriptor. But they need to be propagated to the given tenant, when a module is enabled for the first time. After that, we could in theory allow them to be edited by the admins of that tenant. But I don't think we should, we will run into problems when upgrading modules, and they come with new permission sets...

Comment by Heikki Levanto [ 21/Feb/17 ]

After today's discussion we concluded that we need

  • Add permission sets to the ModuleDescriptor, for example user-editing would imply user-post, user-get, user-put, and user-delete.
  • Define a magic interface to add permissions to the permission module
  • When Okapi enables a module, it calls its tenant API first, then this new magic interface (with a full ModuleDescriptor and the tenant in the X-Okapi-Tenant header)
  • Implement (and declare) this new interface in mod-permissions. It will go through the ModuleDescriptor it gets, and add all permission bits mentioned into its storage, and also the permission sets.
  • Make a way for mod-permissions to consider some permissions and permission sets read-only, so that mere mortals can not edit them. This is to preserve the consistency of module-specified permissions and sets. The magic interface can of course modify those.

This still leaves some issues undecided, but should be enough to carry on for now:

  • If mod-permissions is not enabled when enabling a module for a tenant, we can get inconsistent data. This can be avoided by making all modules depend on the mod-permissions, or by mod-permissions looking up all modules and checking its database when it gets enabled for a tenant, as part of what it does in its tenant interface.
  • The new magic interface can not make regular Okapi requests, because the whole thing is initiated through the admin interfaces, so we do not have tokens and permissions in place. This can be fixed with the internal modules (Okapi-194)
  • If we have many modules implementing the new magic interface, we need to pay more attention to error handling. when a module gets enabled, its tenant API gets called, the permissions module gets called, and suppose some magic-token module gets called. If that last call fails, Okapi will report failure, and not enable the module for the tenant. But the tenant API has done its things, and mod-permissions has too...
Comment by Heikki Levanto [ 22/Feb/17 ]

Created specific issues:

  • OKAPI-267 Closed - Define permission sets in ModuleDescriptor
  • OKAPI-268 Closed - Permission loading interface
  • FOLIO-482 Closed - mod-permissions to implement the module-loading interface
Comment by Erin Nettifee [ 15/Feb/23 ]

All of the associated stories are complete, so closing this umbrella story.

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