HarperDB gives you the ability to restrict access to schemas, tables & attributes. This level of access control allows you to isolate which users/roles can do specific actions against HarperDB as well as limiting access to data you don’t want certain users to view all the way down to the attribute level.  On install of HarperDB a super user level user is create who has access to all levels of data throughout your data model. This is great for evaluating, but when you need to deploy to production best practices may require you create new roles & users.  In this blog we will be using the operations listed under our Roles & Users section of our docs. 

Creating a Role

A Role in HarperDB allows you to assign specific privileges to a user or many users. Here we will be creating a new role that grants all access to the dog table.  In this example we are granting all CRUD access to the dog table under the dev schema. The one limitation is we do not want this Role to have any access to the breed_id column.

{
  "operation": "add_role",
   "role": "dog_access_role",
   "permission": {
       "super_user": false,
       "dev": {
           "tables": {
               "dog": {
                   "read": true,
                   "insert": true,
                   "update": true,
                   "delete": true,
                    "attribute_restrictions": [
                       {
                           "attribute_name": "breed_id",
                           "read":false,
                           "insert":false,
                           "update":false,
                           "delete":false
                        }
                      ]
                  }
              }
          }
     }
}

 To break down this JSON body we will through attribute by attribute:

• operation - here we are telling HarperDB to add a new Role
• role - Name of the new role, in this case we are calling it “dog_access_role”
• permission - this JSON object defines access to specific schemas, tables & attributes
• super_user - if true you are granting access to all aspects of HarperDB and there is no need to grant further permissions as they will be ignored.  In this case we are not creating a super_user.
• dev - the name of the schema we are granting access to.
• tables - This JSON object defines table and attriibute level access.
• dog - the name of the table we are granting access
• read - Role access to read this table, this includes SQL SELECT, search_by_hash and  search_by_value.
• insert - Role access to insert data
• update - Role access to update data
• delete - Role access to update data
• attribute_restrictions - this array defines access controls for table attributes
• attribute_name - Attribute to assign access control, in this case, breed_id
• read - Role access to read this table, this includes SQL SELECT, search_by_hash and  search_by_value.
• insert - Role access to insert data
• update - Role access to update data
• delete - Role access to update data

On execution of this operation we will receive a response from HarperDB:

{
  "operation": "add_role",
   "role": "dog_access_role",
   "permission": {
       "super_user": false,
       "dev": {
           "tables": {
               "dog": {
                   "read": true,
                   "insert": true,
                   "update": true,
                   "delete": true,
                    "attribute_restrictions": [
                       {
                           "attribute_name": "breed_id",
                           "read":false,
                           "insert":false,
                           "update":false,
                           "delete":false
                        }
                      ]
                  }
              }
          }
     },
 "id":"90e852e5-7dbf-4a64-99f2-5e7f4ffa65cc"
}

 As you can see the response back is confirming the Role you entered plus the unique identifier of id.  We will need this id in our next step of creating and assigning a user to dog_access_role. 

Create User

In this step we will create a user record which grants them access to the dev.dog table minus access to the breed_id table, this Role was created in the step above

{
   "operation": "add_user",
   "role": "90e852e5-7dbf-4a64-99f2-5e7f4ffa65cc",
   "username": "jerry",
   "password": "jerry_rox",
   "active": true
}

 Here is a break down of the attributes in the create user request: 

• operation - The add_user operation which will create a new user 
• role - Unique identifier of the role assigned to the new user
• username - Unique name for a HarperDB user
• password - Password for the user
• active - Defines if the user is active or not

Change a User

As important as it is to add a user it is equally important to be able to change them.  It maybe the user needs to be assigned to a new role, deactivated or their password needs to be changed.  Our first example will show changing the role and password for our user “jerry”

{
   "operation":"alter_user",
   "role":"2ebc3415-0aa0-4eea-9b8e-40860b436119-
    1499362372145",
   "username":"jerry",
   "password":"bestJerry4Ever"
}

alter_user is almost identical to add_user, the primary difference being that we can pick and choose between role, password and active attributes that we wish to alter.  The one attribute we did change was the active status of user “jerry”.  Here we will finally deactivate “jerry”

{
   "operation":"alter_user",
   "username":"jerry",
   "active":false
}

 Creating access controls and assign users to them is an essential part of any database, HarperDB gives administrators granular control of CRUD access to their schema all the way down to the attribute level.