Client Security Model

Data is knowledge, so it is fundamentally important that the information you store in CloudTables is secure with access available only to those you've given access. CloudTables has been built from the ground up with security in mind and the model we use is described in this article.

Roles

Access is granted to a data set through roles. These can be thought of as a way to group clients (end users) similar to LDAP or Unix groups. For example you might create different roles that would be suitable for "IT" and "Front of house". Roles can be created and managed on the Security > Roles page and have default access options for Read and Write actions.

Each individual data set has a "Security" tab where the roles can be assigned specific access rights, overriding their defaults. For example, you might choose to have read access enabled, but write disabled by default for a role. But for a specific data set you could then enable write access for that role.

API keys

An API key is a token that you would normally keep secret from client's connecting to your CloudTables (although for internal systems, or read only access it is possible to expose the API key to the client, which makes embedding CloudTables easier). With the API key you can make API calls providing access to the embedding code, or other data available from CloudTables. Each API key can be assigned multiple roles, thus defining the access to the data sets that are available when that API key is used.

Note that if any role assigned to a key (including its default values) grants access to a data set, data point or link then access will be given to the client.

Embed access tokens

As an API key has the ability to grant complete read / write access to a data set, you generally do not want to use the API key in a web-browser where it could potentially be shared or maliciously read and misused. Instead, an API key can be used to generate a temporary access token which can safely be used in the browser as it is attached to a client's access session. Not only will the access granted by the token expire after having been unused for a set amount of time, but it cannot be used in a different browser session, making it unique to the client.

Please see the Embedding and API documentation for further information about creating and using access tokens.