Okapi creating tenant level module users
Description
Environment
Potential Workaround
blocks
Confluence content
Checklist
hideTestRail: Results
Activity
Jakub SkoczenJanuary 11, 2022 at 2:44 PM
@Mikhail Fokanov @Julian Ladisch I think the approach using API Tokens (as captured in Steve's Token re-architecting document https://docs.google.com/document/d/1K_QdgnOo2wOSfY-rQ8phOD6nCO_3jvdAnEG0BEqtnjU/edit#heading=h.6g7k992x57hm) is a more suitable approach than what is proposed in this ticket or in Mikhail's comment. It also avoids making any exception in regular token's expiration by introducing a new, dedicated token type that can be revoked by administrators on as-needed basis.
Mikhail FokanovDecember 23, 2021 at 2:01 PM
If there was a strong requirement, that the 3rd party cannot create users and only Okapi must do it, I would propose that Okapi can create typical users in mod-users and send the username/password to the module on postTenant. The module should store this info in database or else where, so that all instances of the module can see it. As storing of secrets in database is insecure, the module can be provided with some "salt" in environment variable (to all instances of the module) and encrypt the credentials with this "salt" before putting it to database.
Craig McNallyDecember 22, 2021 at 3:53 PM
I agree with @Adam Dickmeiss that this doesn't really belong in OKAPI, which is already doing more than it should... We've been discussing splitting out some of the functionality in OKAPI into separate pieces for years now... At least I remember it coming up during the WOLFcon in Texas.
I also agree that having users automatically provisioned is better than placing the burden on sysOps (the current situation we're in with edge APIs).
WRT sharing passwords, I think it's probably better if they weren't shared at all. It limits the impact if/when a password is compromised.
Adam DickmeissDecember 22, 2021 at 1:58 PM
I think this solution is much better than the edge modules approach.. Which makes it impossible to stand up the system in "one pass".. As the install will have to be split into two.. First part with modules that includes users.. Second pass .. With modules that have "system users".
It's unfortunate that passwords are to be used at all. A token is all what is needed.. And using a password in the approach is effectively like an API token.
I don't think the logic of populating system users is a job for Okapi. Much better to leave it to a mod-system-users or mod-users (or similar). It could be a system interface that is called whenever a module is enabled/upgraded/disabled.. Like a listener on module changes for a tenant. That interface could be used for all sorts of things.. Not just for system users.
Mikhail FokanovDecember 22, 2021 at 1:31 PM
"For each module with tenant level module users Okapi creates a random password that is shared across all tenants when the module is deployed. This is secure because it is used in a single module only."
@Craig McNally, @VBar please provide your opinion if it is secure to have only one password for all modules.
Details
Assignee
UnassignedUnassignedReporter
Julian LadischJulian LadischPriority
TBDDevelopment Team
Core: PlatformTestRail: Cases
Open TestRail: CasesTestRail: Runs
Open TestRail: Runs
Details
Details
Assignee
Reporter
Priority
TBD
Purpose/Overview:
Some modules (e.g. mod-pubsub, mod-search, mod-remote-storage) creates users on tenant init, which is considered insecure. Also such virtual (module) users could be deleted by mistake by librarians using Folio UI.
In order to resolve both problems Okapi should automatically create, change and delete such users when a module is enabled, upgraded or disabled for a tenant. This is triggered by the module descriptor that lists what tenant users and module users are needed.
In a single server installation Okapi executes all necessary steps.
Note: This is an alternative solution to FOLIO-3372 where these tasks are executed by sysops.
Implementation
For each module with tenant level module users Okapi creates a random password that is shared across all tenants when the module is deployed. This is secure because it is used in a single module only. There is no more security if the single module has a separate password for each tenant but has access to all of them.
When deploying the module Okapi passes the password in the MODULE_USER_PASSWORD environment variable.
When enabling the module for a tenant Okapi creates the user with that password and with the username and permissions specified in the module descriptor.
When disabling the module for a tenant Okapi deletes the user.
When upgrading a module for a tenant Okapi makes any changes if the module descriptor about module users changes, for example altering the permissions.
The module descriptor max contain multiple module users with different permissions and different user name.
Multi-server implementation
If Okapi doesn't deploy the module, for example in multi-server installations with rancher, the sysop needs to know the MODULE_USER_PASSWORD to put it into the secret store or use some other way to pass it to the module.
Therefore we need these Okapi APIs:
Get MODULE_USER_PASSWORD for a module.
Set/change MODULE_USER_PASSWORD for a module. Okapi will change the password for all module users of each tenant that has this module enabled. If Okapi has deployed the module (for example single server) it restarts the module after the password change.