Package org.dspace.authorize

Handles permissions for DSpace content.

See: Description

Class Summary

Class	Description
AuthorizeConfiguration	This class is responsible to provide access to the configuration of the Authorization System
AuthorizeManager	AuthorizeManager handles all authorization checks for DSpace.
FixDefaultPolicies	Command line tool to locate collections without default item and bitstream read policies, and assign them some.
PolicySet	Was Hack/Tool to set policies for items, bundles, and bitstreams.
ResourcePolicy	Class representing a ResourcePolicy

Exception Summary

Exception	Description
AuthorizeException	Exception indicating the current user of the context does not have permission to perform a particular action.

Package org.dspace.authorize Description

Handles permissions for DSpace content.

Philosophy
DSpace's authorization system follows the classical "police state" philosophy of security - the user can do nothing, unless it is specifically allowed. Those permissions are spelled out with ResourcePolicy objects, stored in the resourcepolicy table in the database.

Policies are attached to Content

Policies are attached to Content
Resource Policies get assigned to all of the content objects in DSpace - collections, communities, items, bundles, and bitstreams. (Currently they are not attached to non-content objects such as EPerson or Group. But they could be, hence the name ResourcePolicy instead of ContentPolicy.)

Policies are tuples

Authorization is based on evaluating the tuple of (object, action, who), such as (ITEM, READ, EPerson John Smith) to check if the EPerson "John Smith" can read an item. ResourcePolicy objects are pretty simple, describing a single instance of (object, action, who). If multiple who's are desired, such as Groups 10, 11, and 12 are allowed to READ Item 13, you simply create a ResourcePolicy for each group.

Special Groups

The install process should create two special groups - group 0, for anonymous/public access, and group 1 for administrators. Group 0 (public/anonymous) allows anyone access, even if they are not authenticated. Group 1's (admin) members have super-user rights, and are allowed to do any action to any object.

Unused ResourcePolicy attributes

ResourcePolicies have a few attributes that are currently unused, but are included with the intent that they will be used someday. One is start and end dates, for when policies will be active, so that permissions for content can change over time. The other is the EPerson - policies could apply to only a single EPerson, but for ease of administration currently a Group is the recommended unit to use to describe 'who'.