org.dspace.authorize.package.html Maven / Gradle / Ivy

Go to download

Show more of this group Show more artifacts with this name
Show all versions of dspace-api Show documentation

DSpace core data model and service APIs.

There is a newer version: 8.0








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