Package org.dspace.authorize

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'.