Package org.dspace.authorize
package org.dspace.authorize
Represents permissions for access to DSpace content.
Policy types
Policies have a "type" used to distinguish policies which are applied for
specific purposes.
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 withResourcePolicy objects, stored in the resourcepolicy table
in the database.
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 asEPerson 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, actor), such as (ITEM, READ, EPerson John Smith) to check if theEPerson
"John Smith" can read an item. ResourcePolicy objects are pretty
simple, describing a single instance of (object, action, actor). If
multiple actors are desired, such as groups 10, 11, and 12 are allowed to
READ Item 13, you simply create a ResourcePolicy for each group.
Built-in groups
The install process should create two built-in groups -Anonymous
for anonymous/public access, and Administrators for administrators.
Group Anonymous allows anyone access, even if not authenticated.
Group Administrators' members have super-user rights,
and are allowed to do any action to any object.
Policy types
Policies have a "type" used to distinguish policies which are applied for
specific purposes.
- CUSTOM
- These are created and assigned explicitly by users.
- INHERITED
- These are copied from a containing object's default policies.
- SUBMISSION
- These are applied during submission to give the submitter access while
composing a submission.
- WORKFLOW
- These are automatically applied during workflow, to give curators
access to submissions in their curation queues. They usually have an
automatically-created workflow group as the actor.
Start and End dates
A policy may have a start date and/or an end date. The policy is
considered not valid before the start date or after the end date. No date
means do not apply the related test. For example, embargo until a given
date can be expressed by a READ policy with a given start date, and a
limited-time offer by a READ policy with a given end date.
Start and End dates
A policy may have a start date and/or an end date. The policy is considered not valid before the start date or after the end date. No date means do not apply the related test. For example, embargo until a given date can be expressed by a READ policy with a given start date, and a limited-time offer by a READ policy with a given end date.- Author:
- dstuve, mwood
-
ClassDescriptionThis class is responsible to provide access to the configuration of the Authorization SystemException indicating the current user of the context does not have permission to perform a particular action.AuthorizeManager handles all authorization checks for DSpace.Command line tool to locate collections without default item and bitstream read policies, and assign them some.Was Hack/Tool to set policies for items, bundles, and bitstreams.Implementation of
PasswordValidatorServicethat verifies if the given password matches the configured pattern.Database entity representation of the ResourcePolicy tableService implementation for the ResourcePolicy object.Basic implementation for validation password robustness.