In our 2.2.0 version release this week, we made major changes to the way role permissions are managed and used in HarperDB.  

Prior to this release, we used permissions as a way to explicitly identify schema items to restrict role access to. In our new release, we have flipped that paradigm and now use permissions as a way to explicitly identify schemas and tables to grant role access to.

There are two important things to call out at a high-level about what these changes mean:

1. Any schema and/or table that does not have CRUD permissions explicitly defined for a role will not be accessible for that role.
2. If a role does NOT have specific attribute permissions set on a table, all attribute permissions will mirror the tables. If there are attribute permissions set, all other attributes will be fully locked down.
   

More Details about HarperDB Role Permissions

HarperDB utilizes a Role-Based Access Control (RBAC) framework to manage access to HarperDB instances.  A user is assigned a role that determines the user's permissions to access database resources and run core operations.

Role permissions in HarperDB are broken into two categories - permissions around database manipulation and permissions around database definition.

Database Manipulation:  A role defines CRUD permissions against database resources (i.e. data) in a HarperDB instance. Roles not assigned super_user permissions will only have the schema CRUD access explicitly defined within their role’s permissions.

Database Definition:  Permissions related to managing schemas, tables, roles, users, and other system settings and operations are restricted to the built-in super_user role. 

Built-In Roles

There are two built-in roles within HarperDB. See full breakdown of operations restricted to only super_user roles here.

• super_user - this role provides full access to all operations and methods within a HarperDB instance, this can be considered the admin role.
• This role provides full access to all Database Definition operations and the ability to run Database Manipulation operations across the entire database schema with no restrictions.
  
• cluster_user - this role is an internal system role type that is used and managed internally to allow clustered instances to communicate with one another.
  

User-Defined Roles

In addition to the built-in roles above, admins (i.e. users assigned to the super_user role) can create customized roles for other users to interact with and manipulate the data within explicitly defined tables and attributes.

• Unless the user-defined role is given "super_user" permissions, permissions must be defined explicitly within the request body JSON.
  
• Describe operations will return metadata for all schemas, tables, and attributes that a user-defined role has CRUD permissions for.

More information and details about how to effectively create and manage role permissions in our new paradigm can be found in our docs here.

Coming Over the Horizon

We are always working to make improvements to the way HarperDB allows our users to easily and effectively create and manage their database instances.  One additional enhancement we are looking to implement for role permissions soon is to allow user-defined, non-super_user roles to be assigned access to specific database description and/or manipulation operations that are currently restricted to super_user roles. 

Allowing a more ad hoc approach to assigning permissions on an operation-specific level, in addition to the existing schema-level permissions, will enable administrators the ability to more  effectively customize roles for their individual use cases.

Do you have requests for HarperDB’s role permission functionality or another feature/functionality?  Be sure to post it on our Feature Request board!

View original post and leave comments or feedback