Slide features an integrated herarchical security system. When a subject (ie. a user) wants to perform an action on a given subject (ie. a file), Slide will automatically check that the subject has the appropriate permissions. The client application can add additional security checks and permissions by directly calling the Security helper fuctions.

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.

NodePermission

The NodePermission class represents a permission (or Access Control Entry) which is placed on a node of the namespace. Object: Uri of the node associated to the permission. Subject: Subject of the permission. This can be either the uri of an object in the namespace, the name (or interface class name) of a role or a self permission (in which case the subject is equal to "~"). Action: Action of the permission. Inheritable: Flag which indicates if the permission also applies to the children of the node it is associated to. Negative: True if the permission is negative, which means the subject is denied the permission to perform the specified action. If there is a permission conflict on the same node, the negative permission prevails.