Every data store and object in Cloud CMS maintains access control lists so that you can finely describe the rights of any principal in the system against it. This lets you finely tune the rights of individual users against data stores and objects down to a single permission.

This access control is authority-based which means that it's applied by granting authorities (or roles) that a principal has over an object.

Let's buckle down on the terminology for a moment:

  • A Permissioned entity is a data store or object that the permissions service knows how to work with. As noted, this includes absolutely everything within Cloud CMS.
  • A Principal is the user or person acting upon a Permissioned.
  • A Permission is a capability that you can grant to a principal.
  • An Authority is a Role that packages together multiple permissions. When you grant a principal an authority over an object or data store, all of the permissions of that authority are in turn granted.

Let's take a look at the list of permissions:

Permission Description
CONNECT The principal can connect to a Permissioned. This permission supersedes all others. If not granted, the principal is not aware of the Permissioned and can perform no operations against it.
READ The principal can read the Permissioned.
CREATE_SUBOBJECTS The principal can create objects that are contained within the Permissioned.
UPDATE The principal can update the Permissioned.
DELETE The principal can delete the Permissioned
MODIFY_PERMISSIONS The principal can assign, revoke and modify permissions against the Permissioned.
GRANTAUTH The principal can assign impersonating around another principal. This is solely used for Authentication Grants as a means of describing who can create new grants for a principal.
MODIFY_CREDENTIALS The principal can modify the credentials for another principal. This is solely used to describe rights against Identities.
IMPERSONATE The principal can impersonate a target principal. As such, when the principal is signed on, they can take on the authentication credentials of the target principal.

For Nodes, the following additional permissions are available:

Permission Description
CREATE_WITH_DEFINITION The principal can create objects of the given type.
This is solely used for Node Definitions (type, feature or association).
READ_WITH_DEFINITION The principal can read objects of the given type.
This is solely used for Node Definitions (type, feature or association).
UPDATE_WITH_DEFINITION The principal can update objects of the given type.
This is solely used for Node Definitions (type, feature or association).
DELETE_WITH_DEFINITION The principal can delete objects of the given type.
This is solely used for Node Definitions (type, feature or association).
MODIFY_PERMISSIONS_WITH_DEFINITION The principal can modify permissions for objects of the given type.
This is solely used for Node Definitions (type, feature or association).

Assign Permission

Cloud CMS does not let you assign individual permissions to data stores or objects. Instead, permissions are collected together into Roles/Authorities. When a principal is granted a Role over a data store or object, they are granted all of the roles' permissions.

See the section on Authorities for information on working with role-based security.

Check Permission

We can check whether a principal has a given permission over a datastore or object by making a simple call over to the server to ask.

// assume we have a repository
var repository = ...;

// and a user named bob
var bob = ...;

// check whether bob has READ permissions over the repository
repository.checkPermission(bob, "READ", function(canRead) {

    if (canRead) {
        console.log("Bob can read!");
    } else {
        console.log("Woe unto he, Bob cannot read!");

Bear in mind that this approach makes a call over to Cloud CMS to check the permission. Thus, it's fairly expensive to do. Fortunately, Cloud CMS permission checks everything for you, before it allows the caller to interact with data stores or objects. Thus, most of the checks that you'd probably find yourself wanting to perform happen automatically on the server side.

Bulk Permission Checks

In the case shown above, we checked a single permission against a data store. Well, what if wanted to check a whole bunch of permissions? Rather than make lots of HTTP calls, we can send them all over the wire at once and have the bulk check and come back in one fell swoop.

This works much faster than going one-at-a-time.

// assume we have a repository
var repository = ...;

// and a few users
var richie = ...;
var fonzie = ...;
var potsie = ...;
var ralph = ...;

// here we define everything we want to find out
// let's find out if any of them have READ rights to the repository
var checks = [{
    "permissionedId": repository.getId(),
    "domainId": richie.getDomainId(),
    "principalId": richie.getId(),
    "permissionId": "READ"
}, {
    "permissionedId": repository.getId(),
    "domainId": fonzie.getDomainId(),
    "principalId": fonzie.getId(),
    "permissionId": "READ"
}, {
    "permissionedId": repository.getId(),
    "domainId": potsie.getDomainId(),
    "principalId": potsie.getId(),
    "permissionId": "READ"
}, {
    "permissionedId": repository.getId(),
    "domainId": ralph.getDomainId(),
    "principalId": ralph.getId(),
    "permissionId": "READ"

// run the checks
platform.checkRepositoryPermissions(checks, function(results) {
    console.log("Richie result: " + results[0].result);
    console.log("Fonzie result: " + results[0].result);
    console.log("Potsie result: " + results[0].result);
    console.log("Ralph result: " + results[0].result);