Administrative User Bootstrapping

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:

1. Disable the authtoken interface 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, mod-login-saml).
2. 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.
3. Assign all permissionSets that are not included in other permissionSets to the permissions user record in permissions storage.
4. Re-enable the authtoken interface (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:

1. 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.
2. During the time that the administrative user is being created, all tenant APIs are unsecured.
3. 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-bl
• mod-users-bl could offer an admin-user API 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.

So I have some thoughts on two approaches:

1.) A new “admin module” or API created in an existing Folio back-end module (mod-users-bl?) to handle creation/activation/administration of the admin superuser and/or tenants.

2.) A built-in default admin user of the system that is provided as a part of the core-platform (possibly provided by said “admin module” or maybe reference data). You then need to change this password after the Folio system is running.

Each has its pluses and minuses…

Most systems come with a provided superuser or admin user - that then you need to change the password to and/or change the name of, in order to secure your system once it is “On”. This is not unreasonable.

My biggest concern is how that is provided?

One option I envision: An “admin module” where you launch it first before any other Folio back-end modules (with the exception of the built-in Okapi module?) that provides some sort of accessible web UI service. The prerequisites would be Okapi and its DB, and an existing DB or DBs stood up for the back-end modules you will run later. Here in this “admin module” web UI, you define where your Okapi is, where the back-end module’s DB is, an admin user name, its password, and maybe a Tenant to init?

More thoughts to come as I think about this more…