Every ObjectNode has associated permissions, which are tuples with the following format:
(target subject, executing subject, action, inheritance)
Here are examples of permissions:
(/foo/document.txt, /user/dave, /actions/read, no)
(/foo/document.txt, /user/dave, /actions/write, no)
(/foo, /user/john, /actions/read, yes)
Permissions granted on an object are inherited (unless specified otherwise during permission assignement) by the children of the object. For example, a permission specified on object whose URI is /foo would be inherited by object /foo/bar.
This inheritance behavior also applies to subjects and actions. Subject /users/dave will have all the permissions given to all the subject /users. Likewise, a subject who can perform action /actions on an object will be able to perform /actions/read.
In a future Slide release, interitance on subjects will also use links. However, due to some performance issues, the administrator will be able to disable this feature.
The security checks for those action types are automatically done by the helper functions used by the client applications. If a check fails, an AccessDeniedException is thrown, which is a checked exception, so the client application will know when an underlying security check occurs, and can take appropriate actions if it fails.
The basic actions are :
|
 | Read object |
 | Create object |
 | Remove object |
 | Grant permission |
 | Revoke permission |
 | Read permissions |
 | Lock object |
 | Kill lock |
 | Read locks |
 | Read revision metadata |
 | Create revision metadata |
 | Modify revision metadata |
 | Remove revision metadata |
 | Read revision content |
 | Create revision content |
 | Modify revision content |
 | Remove revision content |
The client application can define additional action types, and do whatever security checks it needs.