Package org.apache.slide.security

Provides classes to access and manipulate permissions.

See:
          Description

Interface Summary
Security Security helper.
 

Class Summary
ACLSecurityImpl WebDAV/ACL compliant security helper implementation (draft-12)
ActionsCache  
NodePermission Permission object.
SecurityImpl Security helper.
SecurityImplAllGrant Security helper.
 

Exception Summary
AccessDeniedException Access denied.
SecurityException Generic security exception.
 

Package org.apache.slide.security Description

Provides classes to access and manipulate permissions. 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.

Roles

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.

Principles

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,  /users/dave,            /actions/read,     no)
(/foo/document.txt,  /users/dave,            /actions/write,    no)
(/foo,               /users/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.

Behavior

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 :

The client application can define additional action types, and do whatever security checks it needs.

Object Model

NodePermission

The NodePermission class represents a permission (or Access Control Entry) which is placed on a node of the namespace.