FOLIO offers no built-in way to bootstrap an administrative user (a “superuser” who is granted all permissionSets defined in the permissions storage) for a tenant. The current method for accomplishing this is rather convoluted:
- Disable the
authtokeninterface for the tenant (provided by
mod-authtoken). This disables permissions enforcement for all interface endpoints for the tenant. Note that this may also require disabling other modules that require the authtoken interface (for example,
- Create the necessary records in the authentication and authorization modules. Records are required in users storage, login storage, permissions storage, and service points users storage.
- Assign all permissionSets that are not included in other permissionSets to the permissions user record in permissions storage.
- Re-enable the
authtokeninterface (and other modules disabled in step 1 above).
This can be accomplished by a script (see https://github.com/folio-org/folio-install/blob/master/bootstrap-superuser.pl), or as part of system or tenant provisioning (see https://github.com/folio-org/folio-ansible/tree/master/roles/create-tenant-admin and https://github.com/folio-org/folio-ansible/tree/master/roles/tenant-admin-permissions).
This approach has the following problems that I can imagine:
- The Okapi API needs either to be unsecured, leaving a security hole open for the entire system, or the above procedure needs to be followed to create an administrative user for the supertenant, creating a chicken-and-egg problem.
- During the time that the administrative user is being created, all tenant APIs are unsecured.
- The procedure creates an administrative user with all permissions in the system at the time the procedure is run. Any new permissions added to the system (by enabling a new module, for example) then need to be added manually to the administrative user.
The Core Platform team has raised MODUSERBL-70 to address this issue, and is asking for input from the SysOps SIG on possible approaches. A few ideas, in no particular order, which might also be combined:
- An administrative user could be created as part of the tenant initialization of
mod-users-blcould offer an
admin-userAPI for creating and maintaining administrative users
- An “admin user” module could be enabled for the the tenant to create and maintain administrative users
Any input you might have on requirements, desired workflow, or the pros and cons of different approaches, would be valuable to the team. Please feel free to comment here, or on the JIRA issue.