Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  1. Create a Drupal role for members of the Department of History.
  2. In the Drupal permissions (admin/people/permissions), give the Department of History role permission to "view repository objects."
    This allows users with this role to view all public objects and all objects that are viewable only by their role.
  3. Assign Drupal users to the Department of History role.
  4. Go to the History collection and click on the Manage tab.
  5. Click on Object Policy.
  6. Check the box for "Enable XACML restrictions on Object Viewing"
  7. In the Object Viewing menu, select "Department of History." 

    Warning

    Select multiple roles or users with CTRL + click (Windows) or Command +click (Mac) to avoid unselecting previously highlighted items in the list.

  8. Click Set Permissions. This adds a POLICY datastream that restricts the collection object itself, and any new objects added to this collection will automatically receive the same POLICY.

Below are more detailed instructions on using the Object Policy tab together with Drupal roles and permissions to restrict access to collections, objects, and files.

Item/Child Policy

With the XACML Editor enabled, each object and collection will gain a new tab where you can define XACML policies for that object/collection. At the object level this tab is Item Policy; at the collection level, it is Child Policy (defining policies for all children of that collection). The basic options under both tabs are similar, with additional configuration options available for Collections.

Image Removed

Object Management

Object Management policies effect who can set XACML policies for a particular object. Anyone who can Manage an object can also view it, even if Object Viewing permissions would otherwise deny access. To select multiple users, use ctrl+click (Windows) or command+click (Mac).

Object Management

Object Management policies restrict access to the Manage tab on objects or collections to only the users and roles who are highlighted. These users and roles must also have Drupal permissions to perform management functions on repository objects.

Users and roles who have object management permissions also have object viewing permissions, regardless of the settings in Object Viewing. Drupal users with the "administrator" role also have access to manage and view all Islandora collections, regardless of Object Policy settings.

Image AddedImage Removed

Warning

In order to prevent accidentally locking yourself out of an object or collection, the XACML Editor will prompt you to always select your account and that of the admin user (user 1). To remove a XACML policy completely, delete the Xacml Policy Stream POLICY datastream under the Object Details tab rather than deselecting members in the XACML Editor.

Object Viewing

 

Object Viewing policies control who can view an object. If this option is not enabled, then only regular Drupal permissions will apply.

When enabled, this option will override Drupal permissions negatively, but not positively; in other words, a user who has Drupal permissions to view an object but not XACML permissions will not be able to view that object, and a user who does not have Drupal permissions but does have XACML permissions will also not be able to view the object. In order to view the object, the user will need both Drupal and XACML permissions to access it.grant viewing access only to users and roles who have the necessary Drupal permissions and who are selected in the list of allowed users under Object Viewing. Object viewing permissions also affect all Solr views and search results.

Image AddedImage Removed

Datastreams and MIME types

Datastream (DSIDSDSID) and MIME type restrictions control user access to individual data streams datastreams on an object or collection. This restriction applies to viewing those datastreams, and not to modifying them. Permissions to modify datastreams should be controlled l through Drupal permissions in admin/user/permissions. If this option is enabled, users who do not have permission only the selected users will be able to view certain datastreams will not see them listed for or file types attached to an object or collection. An example use of this functionality is to restrict the master copy (OBJ) of a file to administrators, but make an access copy or the metadata available to more users.

Viewing restrictions can be added by DSID (Fedora datastream ID, shown in the Manage > Datastreams tab under ID) or by MIME type (shown in the Manage > Datastreams tab under MIME TYPE)Restrictions in this section must be enabled by DSID or MIME type, instead of simply being applied to the entire object.

  • DSID: Restrict a particular data stream datastream on the object. Provided as a lookup field so that you can search for available data streams.
  • DSID Regex: Create a rule to restrict all data streams fitting a certain pattern or in a certain class, i.e, POLICY/*
  • MIME type: Restrict access to a particular MIME type on an object.  Provided as a lookup field so that you can search for the MIME types available.
  • MIME type Regex: Create a rule to restrict all MIME types fitting a certain pattern or in a certain class, i.e, text/*

Image RemovedImage Added

Collection Children

When editing policy the Object Policy at the collection level, an additional option menu is available to determine how the policies will be applied to children of the collection (objects and child collections). If there are numerous objects in the collection or its child collections, this process may take some time.

Image Added

The options are:

  • New children of this object: XACML policies will only be applied to newly added objects; existing objects will not be changed.
  • All children of this collection and collections within this collection (existing and new)
  • All immediate children of this collection (shallow traversal)

 

Info

Applying an XACML policy to a large number of existing objects requires updates to the RELS-EXT and Solr index, and can be a time-intensive and resource-intensive process. Treat this option as you would a batch ingest.

 

 Image Removed