A role can be assciated to each node of the Slide namespace. This role
will indicate what are the responsabilities and rights of an object
in the namespace. Of course, most of the nodes in the namespace won't
attempt to perform actions, and are associated to the role "nobody".
The roles are represented in Slide by Java interfaces, which can be
empty or contain additional functions.
To have a particular role, the node must extend SubjectNode, and
implement the role interface. For exemple, FooNode has role Foo if
it extends SubjectNode and implements interface Foo. The node must
always have a default constructor.
Simple names can be associated to the Java interfaces name (in the
namespace configuration). These names can be used instead of the fully
qualified interface class names when defining permissions.
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.
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.