Deep Blue Access Permutations - mlibrary/hydra-prototype GitHub Wiki

Revelation: AccessPolicy is just an object with permissions, and technically any object with permissions can govern other objects (e.g. Item can be governed by Collection, or File by Item).

Keep in mind: the policy-aware ability.rb approach is to first check the resource for a permission and then the policy. This is designed so that a Collection can define which users/groups have read permissions, and an Item governed by that Collection would automatically inherit those readers. The Item can then have its own permissions for edit, in addition to the Collection.

The problem? The Deep Blue model skews toward open collections and restricted files: users would fail the file-read-permission-check but pass the collection-read-permission-check. 💔

This page tries to summarize the access permutations that you can encounter in Deep Blue:

• the tables list action/mode vertically, and possibly valid role/permission horizontally
  • e.g. an x in a column for the deposit row means that role (e.g. DEPOSIT) resolves as true for can(:deposit, current_user)
• the [GROUP] column means a "group of users/groups" that is defined external to MHydra
• UM USER and PUBLIC are AccessProfile objects that only define read permissions
• COLLECTION or ITEM means that the object could be governed by the collection or item
• since there's a theoretical cost for defining an ACL, the table tries to only mark the likely unique possibilities per action

(PLEASE suggest better ways to explain these permutations! 😕)

Collection:

ACTION/MODE	ADMIN	MANAGE	DEPOSIT	UM USER	PUBLIC	[GROUP]
create	x
read				x	x	x
update	x	x
delete	x
deposit		x	x

Item:

ACTION/MODE	ADMIN	MANAGE	OWNER	UM USER	PUBLIC	[GROUP]	COLLECTION
read			x	x	x	x	x
update	x	x	x				x
delete	x						x
upload			x				x

Bitstream/FileSet:

ACTION/MODE	ADMIN	MANAGE	OWNER	UM USER	PUBLIC	[GROUP]	COLLECTION	ITEM
read			x	x	x	x	x	x
update	x	x	x				x	x
delete	x
discover				x	x	x	x	x

---

These tables put together with Table Editor; you can import the <table> HTML for editing.

SPECIFY LISTS OF USERS/GROUPS FOR EVERY OBJECT. We suspect that this is not scalable (because every Hydra::AccessControls::Permission gets indexed in Solr, and every user/group gets its own Permission object), but we can definitely develop/prototype far with this approach.

IMPLEMENT DSPACE'S STRATEGY OF CREATING GROUPS FOR ALL PERMISSIONS. Every time you elect to deviate from ANONYMOUS, DSpace creates a group based on the collection + permission (e.g. GROUP_38_ADMIN). MHydra could similarly use AdminPolicy objects for typical read/discover access (public, UM User, etc), and then create "local" groups in its RDBMS to manage exceptions.

(An MHydra User would be pulling in groups from the local RDBMS, MCommunity, and whatever virtual groups we divine from the request --- in the library, UM User, etc.)

BUILD A DIFFERENT PERMISSIONS ENGINE. One that's designed around the kind of curated management/access/discovery that LIT has done --- not just in Deep Blue, but with DLPS. One designed to handle our use case where the Collection and Item have more permissive access than the File.

This would have to be spec'ed out. And I don't think it precludes the permission-proliferation-issue.

Out of the box:

Access Rights Label	read_groups value
Open Access	public
MLibrary (e.g. Institution)	registered (e.g. user logged in)
Private	(none)