[FOLIO-617] Super user and super tenant Created: 22/May/17  Updated: 12/Nov/18  Resolved: 25/Jul/17

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

Type: New Feature Priority: P3
Reporter: Heikki Levanto Assignee: Unassigned
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: 3 hours
Original estimate: Not Specified

Issue links:
Relates
relates to OKAPI-344 implement Internal Modules Closed
Sprint:

 Description   

Consider if we need to have something analogous to the 'root' user on Unix systems, a user that has implicit permission to do anything at all.



 Comments   
Comment by Heikki Levanto [ 22/May/17 ]

I can imagine a few different types of 'super' users:

  • One who may do anything at all, including creating and deleting tenants and modules
  • One that may operate on Okapi's module/tenant functions, but may not do stuff internal to a tenant (forgive fines)
  • One that may do anything at all, within his own tenant, but may not touch other tenants or Okapi itself
  • A specif super-tenant that is allowed to do Okapi stuff, but that will not have (regular) users, or many active modules to do anything library-like

There is a philosophical difference between a true superuser that implicitly has permission to do everything, and a mere mortal user who happens to have all permissions granted. The second one can have some permissions redacted, and when new modules are enabled, he will not automagically get full permissions for those. Whereas the true superuser will always have all permissions for all modules.

I am not quite sure of how much of these we will ever need. I could imagine that we would need at least one operator who can create tenants and install new modules on a cluster, and who would not be part of any tenant as such. And that each tenant would need some kind of admin user, but that could just be a regular user who has the permission to grant any permission to any of his users, and maybe enable (already-installed) modules for his tenant...

This needs some more thought and discussion...

Comment by Heikki Levanto [ 22/May/17 ]

I start to believe that we can get away with two kinds of "super" users, none of which needs to have true superuser superpowers:

For the first, I think we need a special site-admin tenant that will be used for site administration only. Inside that tenant, we need to create a very powerful user ("landlord"?) that has powerful permissions to do various things like

  • Manage tenants, modules, and other Okapi-related things
  • Enable and disable modules for any existing tenant (although the tenant's own admin should be allowed to do this as well)
  • Create lesser users inside this tenant and grant those some subset of his own powers.
  • This user may also need a permission to log in as a superuser inside a regular tenant, to see that all works there, but I am not quite sure of that.

This tenant and site-admin user should be created as a part of the process of setting up a new Folio installation.

For the second, I think we need a fairly powerful admin user within each tenant with powers to

  • Enable and disable modules for the tenant (maybe with some restrictions, like not being allowed to disable the auth modules, not to leave the whole system wide open)
  • Create users and manage their permissions
  • Manage his own permissions
  • Bulk-load data into the system

This user should be created as a part of the process of creating a new tenant. He does not need magic permissions to do everything, he can grant permissions to himself if he needs.

Comment by Heikki Levanto [ 23/May/17 ]

On the other hand, it would not be too difficult to define a superuser permission bit. If the user has that one set, the auth module could blindly grant what ever permissions are required or desired, without consulting the permissions module at all. That would be powerful, but also a security risk. It would be possible to make the permissions graduated, so that a a regular superuser would be able to do anything within his own tenant, but still not get magic access to okapi-level operations, but this starts to get messy.

I believe we can get far without introducing superusers at all. If needed, they can be added later.

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