Security

Cloud CMS lets you define enterprise-grade access control policies across all of your content to ensure and assert that
the right content is being accessed by the right people at all times.

To achieve this, Cloud CMS offers a security engine that incorporates multiple levels of access provisioning.
These include:

  • A Role-based, multi-level Authorization engine that asserts Permissions on every API, service and DAO method invocation.
  • Fine-grained, object-level access control lists for specific assignment of capabilities on a per-item basis
  • Users and Groups for encapsulating inherited authorities from ancestral memberships and group-based assignment
  • Teams for assigning easy broad-stroke Role assignments within Projects
  • Access Policies to evaluate more complex, multi-concern conditions ahead of assigning Roles.

With Cloud CMS, you can rigorously define your required security policy with an assurance that it will be implemented
down to the letter. All objects, data stores and content that flow in and our of Cloud CMS is checked for required
permissions at every level.

Access rights are checked with every call into the Cloud CMS API, no matter whether those calls originate
from HTTP, WebDAV, FTP or the user interface. At the end of the day, all calls route through the same
backbone services.

Basic Concepts

To begin with, lets define what Permissions, Authorities and Principals are:

  • Permission - A Permission is a capability or a right that can be bestowed upon something. Permissions include read, update and delete among others. If you have the delete permission against a content node, for example, then you are allowed to delete that node.
  • Authority - An Authority (also called a Role)is a grouping of Permissions. Together, they effectively describe the kinds of things that someone with a specific role within the organization might be able to do. For example, a Content Editor might be able to create, update and delete things.
  • Principal - A User or a Group of users.

Grants and Revokes

In Cloud CMS, you grant or revoke an principal's authority against an object or datastore. These grants or revokes can be assigned
directly or these can be broadly described using an Access Control Policy.

Consider the following statements. These all makes sense in the Cloud CMS vernacular:

  • *Bob has the Consumer role granted to him against the folder named My First Project.
  • *Jill has the Manager role granted to her against all content of type my:article.
  • *Wendy has the Editor role revoked from her against all content in the path /products/sony.

These are all statements where a Principal has a Role granted or revoked for a given object or data store.

Fine-Grained Assignments

Within Cloud CMS, you can grant a role for a user against an object or datastore directly. This allows you to individually
control permissions on an object-by-object basis. This is fine grained and very useful when you need to get very precise.
However it also may require a lot of redundant assignments for large sets of objects or data stores.

We recommend using direct assignments for small projects or for one-off adjustments on an as-needed basis.

With object-level / role-based authorities, you assign a principal (either a user or a group) a role against
something. For example, you might give Joe the consumer role against a content node. When Joe then interacts
with the content node in the future, he will do so with the consumer role which will allow him to "read" the node.

Inheritance

Access control assignments that are assigned to a group will automatically be assigned to the members of the group.
Thus, you may find using groups to be an easier way to manage your users. Rather than assign rights to individual
users, you can put all of the users into a single group and then set up object-level or team role-based authorities
using the group.

The ACL tree is automatically managed for you and updated whenever users or groups are added, removed or their
membership is altered.

Propagation

When using content containers (i.e. folders), authorities that are granted to a container will automatically
propagate to all child objects within the folder. If those objects are files, those files will receive the
same authority grants. If those objects are containers/folders themselves, then the propagation will continue
to all children so on down.

Propagation can be disabled by toggling the "enabled" setting on the association that links the parent to child.
This association must have the f:propagates-authority feature on it. By default, the a:child association has this
feature and so propagation is enabled by default for all folders/documents within the main user interface.

Teams

You can define Teams at both the Platform and the Project level. A Team is effectively a Group that allows for some
additional capabilities. These capabilities are:

  • a simple, blanket assignment of a Role across the Platform (or the Project)
  • a more complex, conditional assignment of a Role across the Platform (or the project) that is driven by an Access Policy

With simple, blanket assignments you can set things up so that all members of a Team will be granted a specified
Role against all items that the Team oversees. For example, if a team grants the Consumer role, then all members of the
Team will have READ rights over all content in the project.

With Access Policies, you can describe more complex, conditional rules that must trip in order for the Role to be
granted. These are used to implement more advanced assignments. They're described in more depth below.

Access Policies

This section describes features that are coming in 4.0

Cloud CMS supports Access Policies that allow you to define broad-sweeping statements that apply
to all resources within your tenant or within a project within your tenant. These statements allow for logical
expressions (and, or) and support a library of conditions to apply grants and revokes against resources that match
regular expressions against content path, type, properties, features and a lot more.

We recommend using Access Policies for large projects or for enterprise-needs where your content
permissions may be far more complex and customized.

Examples of Access Policies may include the following:

  • Can Edit all Content that is in Spanish
  • Can Manage all Content of type my:article that is localized into Spanish
  • Can Publish content that is in the Live lifecycle state

Access Policies allow you to describe broad boundaries of content and then describe the roles that someone should be
endowed against them. For example, "all of the content in Spanish" is a broad description of content as it doesn't
precisely describe any content by ID. Rather, it's a transient description that includes any content that may be
in Spanish at a given moment in time.

Access Policies are then applied to either Teams or Users.

Teams

You assign Access Policies to Teams to allow all members of a team to inherit the rights conferred by the Access Policy.
For example, you may create a team called Spanish Editors. You might then assign that Team the following
Access Policy:

  • Can Manage all Content of type my:article that is localized into Spanish

Once you assign that Access Policy to the team, all team members will now be able to create, update or delete articles
that are in Spanish.

Users

You may also assign Access Policies directly to users. You may opt to do this for cases where one-off assignments
for specific privileged users is more practical.

Team Roles

Teams also support direct assignment of Roles. Direct role assignments act as unconditional access policies.

For example, if you were to assign the editor role to a team, it ends up becoming an internal Access Policy that
looks like this:

{
    "statements": [{
        "action": "grant",
        "roles": ["editor"]
    }]
}

Note that this Access Policy doesn't have a conditions section. This means it is unconditional. It will always be
applied to all resources under the team. If you were to assign the consumer role to a Project Team, then that team
would grant Consumer rights to all of the content underneath it.

You're free to use either Access Policies or Direct Role assignments with your teams. However, we would stress that
Direct Role assignments are very limited in that they're all or nothing. If you need more fine grained permissions,
you're going to want to use Access Policies.