Meta-Issue: Access Restrictions and Embargoes

[dannylamb]

This is a meta issue to track development of access restrictions and embargoes. Please refer to this issue in any subsequent issues to link them.

One powerful feature of islandora_scholar is the ability to restrict access based on a variety of factors/workflows. This functionality should be extracted from islandora_scholar for Islandora CLAW and made generic for uses outside of institutional repositories.

[mjordan]

I thought I'd bring together some of the issues that fall under this meta... issue. I also suggested this set of topics as the focus for an Islandora 8 webinar, and have hacked together a simple module to see if we can use Context to implement IP-based access control (this module is based on a capability of 7.x's Islandora Context, which SFU uses).

I've found the following dealing with embargos:

• Replacement for Scholar Embargo
• Replacement for Islandora IP Embargo
• Provide embargo management capabilities

And then some (probably not all) additional issues about access control, which are very much related to "embargos":

• AuthZ: Permit metadata access but deny (some) file access
• Derivatives of restricted items shouldn't be publically accessible
• Access control via (and on) taxonomy terms

I think we've been assuming (perhaps correctly) that there will be some off the shelf D8 contrib or core capabilities that will replace the functionality we currently have in Islandora 7.x, but we should also keep in mind that sites that have embargoed content in 7.x will not be able to migrate to 8 until equivalent functionality is available in 8. Content that is embargoed now may need to continue to be embargoed after migration.

In order to get a handle on where we are, should we follow @bryjbrown's lead way back in 2016 and create some use cases around embargoes?

[pautri]

For us, an ideal access control setup in Islandora 8 would have the following features:

• an option to define (and frequently modify!) access policies for collections, without having to recursively apply the policy to all members of the collection
• an option to override these collection access policies for specific members of the collection (and their children if there are any)
• an option to define "read" as well as "write" permissions
• distinguishing "view" permissions (in the sense of listing the items/media while searching and browsing) from "access" permissions (in the sense of opening up the content of files in a viewer or downloading them). Typically, we want all "repository items" and "media" ("objects" and "datastreams" using old stack terminology) to be listed and their metadata being accessible, while having the option to restrict access to individual media.
• a user interface for being able to easily define access policies on a collection, item or file. The policy potentially needs to include many specific users, selected from a large number of registered users (in the order of thousands)
• group functionality

The first two points are basically how WebAC authorisation works in Fedora 4/5, as far as I understood. If an item does not have an ACL of its own, Fedora walks up the tree until it finds one, or uses the default repository policy if there are none. Not sure how costly this lookup is going to be if you have deeply nested structures, but at least defining policies on a large collection this way is very efficient. Now that in Islandora 8 all content lives in Drupal as well as in Fedora, we might not want a setup where we depend on Fedora for the authorisation records, but perhaps a similar system could be implemented on the Drupal side. Authorisation records could then perhaps also be serialised to WebAC and stored in Fedora.

Being able to define access policies on individual "Media" is covered in Rosie's use case and is more or less implemented with the current taxonomy-based access control. Restricting access on derivatives however does not seem to have an effect when viewing them in context, only when accessing them directly. This might be due to use of the general "view media" permission in the view.

Group functionality could perhaps be achieved by some sort of integration with Group or Organic Groups. Neither of them have a full D8 release at the moment, but Group seems to be close.

[mjordan]

@pautri thanks for the nicely detailed requirements.

I'll add one from my institution, in the form of a structured use case:

Title (Goal)	Redirect off-campus users to Ezproxy when they access IP-restricted content
Primary Actor	Repository admin
Scope	Drupal content
Level	?
Story	We have content in our Islandora that is restricted to authorized users only, specifically users on campus or users who are able to authenticate through our campus' Ezproxy. I want to configure Islandora to redirect off-campus users to Ezproxy when they attempt to access such content.

We currently do this with Islandora Context, which is one reason I started putting together IP Range Access. Here's the admin UI in a Context from 7.x: