Introducing the Role-Based Access System in Specify 7.7.0
Specify 7.7 implements a new, role-based access system for granting privileges to user accounts to access Specify components, data tables and fields. The new permissions system provides considerable flexibility for a collection institution to align data security policies with Specify functions to reflect institutional preferences for how curators, collection managers, researchers, students, guests and other kinds of users process collections data. The new system is built on Specify’s foundational concepts of institutions, collections, users, and permissions, then adds concepts of Institution Administrator (IA), Collection Administrator (CA), Roles, and Policies.
The role-based access or permission system attempts to reflect the varied responsibilities and activities of diverse users of collections data. In Specify 6, we defined these user classes: Administrators, Managers, Full Access, Limited Access, and Guest. This user type classification was adequate for many collections, but from member requests, and with the feedback from our 2021 SCC member permission system requirements survey, we learned that collections (particularly larger ones) increasingly prefer a more structured and fine-grained model for provisioning user accounts with permissions.
This document is a general introduction to the role-based access system for Specify 7.7. In this document, we will explain key conceptualizations of the new system, provide a basic description of how it works, and suggest some likely usage scenarios. In the near future, we will elaborate on this introduction using the Specify Forum and webinars, to provide more detail for configuring and applying this new comprehensive system.
The Specify 7.7 access system exerts control in three areas: 1) access to the security system itself, to control which roles (and users) can access security setup and permission granting functions, 2) it sets access rights to most Specify 7 components and their constituent functions. For example, the system controls access to data forms, the Query Builder, WorkBench, data exporting, reporting and printing functions, etc., and 3) roles control access to data in trees, forms, queries and Record Sets by granting (or not) permissions for CRUD operations (Create, Read, Update, Delete) on the underlying data tables. Specify 7.7 does not implement record- or field-level security based on the content of data fields, and it does not change Specify 6’s account security system.
The new permissions system is designed to accommodate a variety of institutional security models for collections data–ranging from small collections with one or few trusted users, to the largest institutions with multiple collections and many users who play more specialized roles in collections data processing. The extent to which an institution uses most or even some of the hundreds of atomized permissions settings in Specify 7’s role-based system will vary and within an institution, utilization of the system may evolve as finer-grained security or specialized roles become more important. We expect many small collection institutions will be satisfied with the user account security settings they use in Specify 6.8 or 7.6.1.
If a site is currently using Specify 6, installing Specify 7.7 will copy the pre-existing user accounts created in Specify 6 into the correct user “Legacy” Roles in Specify 7.7. But Specify 7.7 will not pick up customized access settings from Specify 6. Custom user account settings in Sp6 must be recreated with roles and policies in Specify 7, if permissions must match when using the two platforms concurrently with the same Specify database. Subsequent changes to roles, policies, and permissions in Specify 7.7 will not be reflected in Specify 6’s permission system. Backward compatibility is not practically feasible, so the two security systems will be separate going forward. There is one exception to that, on the new “Accounts and Security” page in Specify 7.7 administrators can create new user accounts in both Specify 6 & 7 for sites operating both platforms.
It is important to recall that the scope of the access control system is a single installation of Specify; a server with MariaDB or MySQL and all the collection databases managed on that server. It is not uncommon for a Specify server at small institutions to include data from a single collection in Specify 7 (or for Specify Cloud users). In those cases, this new security architecture would apply to that single collection and database. Large institutions with multiple collections may operate each collection within its own SQL database, or they may combine multiple collections into a single Specify database. In the latter case, the Specify 7 permission system would interact across all collections and users within a database. (User accounts are scoped to the Institution, and added to the Collections to which they have access.)
In Specify 7.7, we have a three-level user hierarchy with the concepts of an Institution Administrator (IA), then for each collection, a Collection Administrator (CA), and then any other collection user role beyond that. It is important to emphasize that the IA/CA/user hierarchy is an administrative one for organizing and operating the permission system. User accounts do not inherit permissions from IAs or CAs, but rather obtain permissions that are granted by CAs in their assigned roles and any optional bespoke policies. The IA user (which is technically not a “Role” in our system) can create role templates and set some permissions for the CA role, but the CA would typically have authority to set permissions for all of the collection’s users, through the definition and assignment of roles and special access policies.
In our model, IAs have the power to do everything–they can create user accounts, manage collection setup and configuration, set default values of various kinds, define roles and their permissions, assign roles to users, assign a Specify Agent to user accounts, change passwords, set up external authentication, access all functions and data. IAs are the super users at the institutional (database platform) level; they can manipulate security settings and accounts for all users across the institution. Collection Administrators oversee the security issues, user accounts, and collection-level policies and permissions for their collection. They can create new roles with custom sets of permissions for their collection, create policy exceptions to grant additional privileges to a user in that collection as a supplement to the privileges granted by the user’s role assignments. CAs also manage user account setup and configuration for their collection. A user assigned a CA role in one collection may be a CA in another collection, or they may be assigned a different role there.
In Specify 7.7’s role-based system, the IA can predefine roles as “templates” with sets of permissions for Collection Administrators to use when they set up and assign the actual roles for users in their collection. In our model, the IA creates a library of predefined roles for CAs to copy and apply to user accounts. There are several role templates in this release to show the potential range of specificity for roles. These are simply examples and can be used, or not, for managing access permissions in a collection. IAs and CAs can create and define any number of new roles, and clone or edit existing ones, to implement a level of access granularity appropriate for their institution and collection. A collection with a single Specify user might grant themselves IA status and consider security configuration complete. Because IAs are omnipotent in our security model, they have no access restrictions whatsoever. (Make regular backups!)
Larger institutions with multiple collections would likely utilize the security model’s three-tier administrative hierarchy to more finely differentiate the use of roles. In Specify 7.7’s model, an IA would set up databases, and then create a CA role for a user for each collection. They would perform the initial configuration of CA roles, typically granting the CA permission to create other user roles and to set the permissions granted in those roles. Once defined, roles can be copied from the templates in the IA-created institution role library and used in any collection within that Specify database. For institutions that maintain separate SQL databases for each collection, standardized roles can be exported and imported between databases. For institutions currently operating Specify 6.8.1 or 7.6.1 with existing databases, the installation of Specify 7.7.0 will automatically read and install existing user accounts in the new access system. Those user accounts will be assigned “Legacy” roles based on their status in one or both of the preexisting systems.
A key concept of account security in Specify 7.7 is that permissions are additive. In the absence of any assigned roles, or supplementary institution- or collection-level policies, a user who is granted access to a collection (a checkbox on Accounts and Security page) would have no privileges to do anything or to see any Specify data. All user permissions must be granted through roles or by specifying custom policies for a user account. Once a permission is granted (by checking a checkbox) to a user through a role or through a custom policy, there is no countervailing “deny” setting. To withdraw a granted permission, it must be removed from the role or policy that granted it, by unchecking it. One way to remove a role-granted permission from an account would be to create a new role with lesser privileges, and then assign and substituted it for the existing role.
Collections interested in fine-grained access settings would find it advantageous to create a number of specialized roles with narrow permission boundaries, and then to assign as many specialized roles as needed to enable a user’s access. Smaller collections with less user specialization would likely find it efficient to create roles with broader sets of permissions to simplify user account management.
Policies are an additional way to add permissions to a user account, they operate outside of, and in addition to, granting permissions to users by assigning roles. Policies provide access to the same set of permissions as do roles–to access Specify component functions, tables and fields–but they are a separate mechanism for adding custom privileges for a user, and again, they are additive to the permissions granted by roles. Policies exist at two levels: institution and collection. When permissions are granted to a user account at the institution level (top part of the ‘Accounts and Security’ page) those permissions apply to that user across all collections to which that user has been granted access in that database. When permissions are granted in collection-level policies, they apply to the user’s account only within the scope of that collection. We expect policies to be used sparingly to add additional permissions to user accounts, as roles should satisfy user permission profile requirements most of the time.
Documentation for members on creating user accounts, role-based policies, and user permissions can be found here.