Permissions

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:

For Nodes, the following additional permissions are available:

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.

// 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!");
}

});

<p>
    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.
</p>

<h2>Bulk Permission Checks</h2>
<p>
    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.
    <br/>
    <br/>
    This works much faster than going one-at-a-time.
</p>

// 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); });