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

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.