*Index
*News
*Status
*Changelog
*Contributors
Downloads
*Releases
*Nightly
Resources
*Source
*Mailing Lists
*CVS
*Library
User's Guide
*Installation
*Configuration
*FAQ
*Examples
*Tomcat Howto
*Avalon Howto
Programmer's Corner
*Architecture
*Domain
*Namespace
Slide API
*Structure
*Security
*Lock
*Content
*Macro
*Index
*Process
WebDAV
*General Info
*Clients
API Reference
*JavaDoc
*WebDAV Client
     Security Helper
 Overview
Principles
Behavior
Object Model

Overview

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.

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,  /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.

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 :
*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.

Object Model



 
Java, JDBC, JNDI, Sun, Sun Microsystems are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States and in other countries. All other product names mentioned herein are trademarks of their respective owners.
 

The Apache Software Foundation. (C) 2000. All rights reserved