Thunderclap: No-SQL Access Control

Thunderclap is an Alpha stage indexed key-value, JSON document and function oriented database and application library designed specifically for Cloudflare. It runs in Cloudflare Workers on top of the Cloudflare KV store and has a browser based client. Its query language,JOQULAR (JavaScript Object Query Language), is similar to, but more extensive than, the query language associated with MongoDB.

One of the key features of Thunderclap is a powerful, flexible, declarative fine grained access control (FGAC) mechanism that can be used to address many of today’s privacy policy concerns. This article describes how this fine grained, access control is achieved. However, the principles in the article could also be applied to MongoDB with a processing proxy placed between MongoDB and the application using its data; thus, relieving an application of security responsibility to simplify logic, enhance resilience, and improve auditabilty.

Fine Grained Access Control Defined

For JavaScript, fine grained access control extends beyond collections or classes of objects. It includes applying access control based on property names, ranges of property names, the presence of property names, the type and value of the data stored in the properties and contextul information such as requesting IP address. For key-value data stores it includes applying policies based on key names or type and value of the data associated with the keys. For platforms that support remote function invocation it also implies control of function execution by name or end-point.

State Of The Industry

Currently, Accumulo is the most referenced No-SQL database supporting any type of fine grained access control. However, sophisticated data element level access control is also available in Google’s Firebase . MongoDB does not have native support for fine grained access control at the time of this writing. Microsoft’s Cosmos lies somewhere in between Firebase and MongoDB. From a capability perspective, Firebase is closest to Thunderclap.

For more info on this topic, search for “fine grained access control NoSQL”. For quick reference here are a few links:

1. Fine-Grained Access Control Within NoSQL Document-Oriented Datastores
2. Towards Multiverse Databases
3. Enhancing MongoDB With Fine Grained Context Aware Access Control

Thunderclap Architecture

One of the key features of JavaScript and JavaScript documents is that they are interpreted or compiled at run-time, making it is simple to:

1. inspect property names as strings
2. map the structure of one object to another
3. compare the types of values
4. modify behavior and structure at run-time

Thunderclap leverages the above by using access control rules with specifications that closely match the structure of the data being controlled while also providing for more generalized matching using functions or regular expressions. These access control rules are stored in a special file acl.js that contains a single JavaScript object as described later.

Thunderclap combines the content of the acl.js file with role definitions specified in roles.js which hierarchically map roles such as dbo (database operator), user , or other application specific roles.

User is a built-in class for Thunderclap and contains a property for attaching roles themselves to instances. This is also described later in the article.

The Thunderclap ACL File

Thunderclap’s entrie set of ACL rules are represented as a JavaScript object. For security reasons, this object is included at build time as a JavaScript file rather than loaded at run-time as a JSON file. This also allows the ACL language to use functions and shorthand initialized key names representing regular expressions, which can’t normally be loaded when using JSON.

I provide the default Thunderclap acl.js by way of example and follow with an explanation of its structure.

The JSON object in acl.js consists of a set of properties used for rule look-up. The top level properties are:

@

Immediately below each key are read/write/execute specifications that apply to the controlled key as a whole. For keys that point to objects, there is also a special property called properties . This contains property names that should parallel the potential property names in the object being controlled and contain nested access control specifications.

The read/write/execute specifications are the property names read , write , execute followed by either an array of role names, a map of role names with true as each of their values, or a function to determine if read, write or execute should be allowed based on the actual nature of the data, the current user, and the execution context. There can also be a special key, filter, that has a function as an argument. It is effectively a wildcard managing read, write, and execute access.

ACL functions have the signature async function({action, user, data, object, request}) . The action can be one of read , write , execute . The user is the user instance from which the userName or roles property can be pulled. The data is the actual data being controlled. When an object is being controlled this is also aliased to object for convenience. And, request is the HTTP request object which can be used in order to limit access based on such things as requesting IP address. If the target data is an object, ACL functions are free to modify it prior to returning. If a truthy value is returned, processing continues; otherwise, Thunderclap will return an HTTP 401 access error to the requesting client.

Whenever an attempt is made to read/write a key or object and its properties or execute a function exposed to clients, Thunderclap looks at the ACL specifications to see if there is a matching rule based on the name of the function, key, or class being accessed. If there is, the top level level specifications are evaluated. If these succeed, then property level specifications are evaluated for objects.

Unless there is a matching ACL rule, Thunderclap assumes all access is available to all functions and data. In order to control something, there must be a rule that matches. As a result, there are some default rules in acl.js to prevent certain kinds of activity, e.g. direct index access by anyone other than a dbo .

The Thunderclap Roles File

Thunderclap supports an arbitrary number of hierarchical roles. Names are restricted to those that are valid JavaScript property names. The roles are specified in a file named roles.js. Thunderclap has only two built-in roles, dbo and user . The default file is below:

To make one role a sub-role of another, just provide it as a key inside another role.

The Thunderclap User Object

Thunderclap has a built-in User class. It has just two built-in properties, userName and roles . Other properties can be added by passing a configuration object when creating a user, e.g.:

const user = new User("jjones",{age: 27});

will result in the object:

{
  userName: "jjones",
  roles: {
    user: true
  },
  age: 27
}

The configuration object can also be used to pass in additional roles, e.g.:

const user = new User("jjones",{age: 27,roles:{dbo:true});

{
  userName: "jjones",
  roles: {
    user: true,
    dbo: true
  },
  age: 27
}

Note, the above user will not be insertable into a Thunderclap database by anyone other than another user with the role dbo .

The properties and roles can be used by ACL rules to control access to data or function execution on the server.

Conclusion

I hope you found this brief introduction to Thunderclap’s access control model interesting. At a minimum, perhaps you can see how you could simplify your MongoDB applications by applying a similar approach to MongoDB with query re-writes or filtering results. Ideally, you find it sufficiently intriguing to give it a clap and take a look at Thunderclap for Cloudflare.