Cloud CMS provides two ways to describe access rights to things:
- Object-level / role-based authorities
- Team / role-based authorities
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.
With team / role-based authorities, you create a project team and put Joe on the team. You then configure the team's roles so that anyone on the team will receive the CONSUMER role against things in the project. Thus, Joe will be able to "read" the very same content node from above but without needing to have explicit permission. They very fact that he is on the team lets him do his job.
Teams provide a broad way of working with users across your projects. If you need to get more fine-grained, then you will want to adjust the team's policies. Team policies let you get more specific about exactly what kinds of objects are to be affected. Team policies let you GRANT and REVOKE specific roles against specific object types.
For example, you could have a Team that gives the CONSUMER role to everyone in it. And then, you could add in a policy that REVOKES the CONSUMER role for anything of type "node". By doing so, Joe will be able to read everything in the project except for content nodes. You can then use the object-level / role-based authorities approach to enable Joe's read rights per content-instance or per-content type.
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.
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.