Cloud CMS allows you to express access control rights to objects and datastores using either broad, sweeping Access Control Policies or fine-grained Authority Grants.
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
deleteamong others. If you have the
deletepermission 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 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.
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:
grantedto him against
My First Project.
grantedto her against all content of type
revokedfrom her against all content in the path
These are all statements where a Principal has a Role granted or revoked for a given object or data store.
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.
Cloud CMS also supports Access control Policy Documents which allow you to define broad-sweeping statements that apply to all resources on your tenant. These statements allow for logical expressions (and, or) and support a large 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 Control Policy Documents for large projects or for enterprise-needs where your content permissions may be far more complex and customized.
When you define Teams within Cloud CMS, you may also assign roles to those teams. These effectively act like Policies from above. They apply to all resources within a Platform or within a Project (depending on where the team is defined). Their only constraint is that they only apply to resources at the same level or below.
We recommend using Teams as a means for getting started. As you figure out your security requirements, move those into standalone Access Control Policies documents and assign them to your Teams. You can then remove the direct assignment of Roles from within Teams as those will be described more accurately by your Policy Documents.