Management FRG - Permissions Analysis and Matrix

Prepared By: DLP Repository Management Functional Requirements Group (FRG)

Date: March 2018

Status: Approved

Overview

A key component of the chartered work for the Repository Management Functional Requirements Group (FRG) was to address permission needs for repository activities and entities:

Create matrix of entities, roles, activities and user stories to articulate Management activities and permissions:

Identify management activities performed on repository entities (objects, collections, files, policies, agreements, etc.: creating, editing, deleting, triggering preservation actions)

Determine staff needs around managing versions of content (e.g. metadata versioning; file versioning; whole object versioning; object restoration)

Outline needs for users/permissions management within a management application (users, groups, roles, etc.)

Identify access controls and roles needed to support deposit and approvals

Determine requirements for access controls for discovery, viewing, downloading, embargoes, and leases

This document addresses multiple interrelated permissions deliverables for the Management FRG, including an inventory and analysis of DLP Repository user permissions needs for activities such as viewing, creating, editing, and deleting assets in the repository. A detailed matrix of system permissions functionality is provided in Appendix C, which references both native Hyrax software capabilities and anticipated Emory customizations. A mapping of out of the box Hyrax system roles to local user profiles developed by the Repository Management FRG and Deposit FRG is also included for reference (see Appendix A). Emory needs regarding levels of repository assets’ visibility (users’ ability to view and download repository content) are documented separately in Appendix B. Finally, user stories capturing unique permissions scenarios and general recommendations for implementation are also included in this document to summarize some unique scenarios identified during analysis of the matrix detail.

This document contains only abbreviated references to Hyrax workflow-level roles, such as Workflow Approver or Workflow Manager, because these roles may vary for each individual workflow implemented in the system. Mediated deposit workflow definitions have been established in the new Hyrax-based ETD application which can serve as a reference model for future workflow implementations to be configured during DLP Implementation phases.  

The requirements identified here are subject to Hyrax software capabilities and Emory’s local capability to develop and maintain customizations. The details of the permissions matrix included in Appendix C are also subject to ongoing change based on Hyrax software releases and documentation availability: during the course of the Management FRG’s work, 3 new system roles were added which impacted the existing permissions model.

Work Process

While creating a work breakdown structure and analyzing tasks, the group made the determination to consolidate multiple permissions-related deliverables into one effort, since they were closely interrelated. As a preliminary step, the team conducting a three-part brainstorming session to identify repository entities, types of people/roles participating in long-term management of repository assets, and verbs/activities. This information was further refined to produce the Management User Profiles and also helped inform the matrix in Appendix C.

The group learned about current Hyrax system entities and permissions concepts, some of which were added to the team’s glossary. It is important to note that some Hyrax permissions information is undocumented, however. This gap is being addressed in the work of the Samvera Permissions Analysis Working Group. The Management FRG also reviewed work being produced in parallel by the DCSC Policy Task Force, Metadata Implementation Working Group, Digital Preservation FRG, and in order to identify entities and activities in scope.

Local Emory Needs/Potential Gaps

The following user stories, which reference role names based on the group’s Management User Profiles, capture local Emory needs which may not be achievable within the current Hyrax permissions model. These stories have been shared with the Samvera Permissions Analysis Working Group for appraisal.

1. As a Repository Administrator or Collection Manager, I want to assign permissions at the top level of an entity and have them propagate to their children, but be override-able at lower levels if needed, so that it is faster for me to assign permissions to appropriate internal staff users on a collection by collection basis

2. As a Repository Administrator or Collection Manager, I want self-service ability to assign and maintain a set of users within an existing permissions group, so that I don't have to request developer assistance or application redeployment to perform routine tasks

3. As a Repository Administrator, I want self-service ability to create a Group of users that I can assign to various permissions, so that I don't have to request developer assistance or application redeployment to perform routine tasks

4. As a Collection Manager, I want to manage a subset of groups and users relative to my immediate organization, so that I can more easily manage my Library’s staff permissions without having to request full administrator access to the application

5. As a Collection Manager, I want to restrict editing of selected parts of the digital object's metadata to specialized personnel, so that I can minimize unwanted changes to the object in its preservation state

6. As a Repository Administrator or Collection Manager, I want to be able to view individual staff/assistants user activity for users modifying objects/files in my collections/department only, so that I can contact a specific user about their work

7. As a Collection Manager, I want to run reports about analytics and inventory that are scoped to my Library or collection hierarchy only, so that I can exclude extraneous data about other Libraries' content and users

8. As a Repository Administrator, I want to restrict Deletion capabilities to Admins only or enforce via a workflow, because deletion is subject to local policy

9. As a Repository Administrator, I want to be able to deselect/select individual abilities assigned to a System Role in a self service capacity, so that I can customize default system Roles with less developer assistance

10. As a Repository Administrator or Collection Manager, I want to manage visibility and edit access to Preservation Workflow metadata related to a work, so that I can minimize unwanted changes to preservation audits for an object

The following Emory-specific user stories were also captured, but which may be achievable through minor customization or local configurations, and have also been shared with the Samvera Permissions Analysis Working Group:

1. As a Collection Manager, I want to assign a primary Library collection affiliation for a work, but be able to control its use in an Exhibition collection that might include works from other Library Collections, so that its source context is not lost if it is added to a user created or exhibit collection and so that I can manage permissions at the Collection-level

2. As a Repository Administrator, I want to constrain the types of Collections that Self Deposit/non-Library users create, so that user-created collections are not competing with Library-curated collections in search and discovery context

3. As a Collection Manager or Self-Depositor, I want to embargo sub-levels of the work, so that sensitive or proprietary details included in an abstract or table of contents for my work are not visible, but other metadata is

4. As a Repository Administrator or Collection Manager, I want to manage visibility and edit access to agreements/Deeds of gift or sale, so that this information is preserved but not editable or viewable except by selected staff

5. As a Repository Administrator, I want to generally delineate Library Staff/curating users from self deposit users, so that I can restrict certain system-wide activities to users who are Library staff only

6. As a Repository Administrator or Collection Manager, I want to restrict editing of selected parts of the digital object's supplemental preservation files to specialized personnel, so that I can minimize unwanted changes to the object in its preservation state

Additional Recommendations for Implementation

The following are identified as general considerations for DLP  implementation:

1. Utilize the existing Hyrax product permissions model wherever possible to minimize complexity.
   While some customizations may be possible, the current Hyrax model is complex and has been targeted for revision.

2. Design an Emory staff user group strategy that will help streamline the complexity of current state permissions in Hyrax. Developing a robust group model before content migration will help reduce redundant permissions assignments over time.

3. Consult with Samvera Community experts prior to implementing our Administrative Set and Collection configuration.
   We will need to plan our Administrative Set and Collection structure (along with Collection Types’ configuration) carefully in advance: once a Collection has been created and is assigned a specific Type, it can’t be un-set. Collection Types are locally customizable and enable assignment of certain functionality, such as whether or not a Collection is nestable, discoverable, and what types of permissions can be assigned.

4. Continue to work with the Samvera Permissions Analysis Working Group to improve the current permissions model. Emory currently has representation in this group, which will propose significant changes to how permissions are currently assigned and managed in the Samvera technology stack.

Appendix A: System Roles Analysis - Hyrax and Emory

The following table lists out of the box Hyrax software system roles, noting correlation to Emory DLP User Profiles where applicable. In general, individuals with accounts in the repository will be assigned multiple system roles in order to perform necessary tasks.

Note: the new Emory ETDs application also has a “superuser” role defined which can manage all ETD-related Admin Sets, edit all ETDs, and approve submissions from all workflows. This document also consolidates Workflow-related roles into one entry, because these may vary per each individual workflow configured. The Laevigata application can serve as a reference for future production workflows.

Permissions Assigned via Users and Groups

In addition to the abilities assigned to the System Roles outlined above, Hyrax software also enables the assignment of permissions to individual users as well as to groups of users for interacting with specific entities such as collections, objects, files. In particular, groups of users may be assigned to a given system role (instead of assigning individual users), which can help us coordinate permissions assignment. For example, a pre-defined group of individual users from Rose Library could be assigned to the Collection Manager system role for a particular Admin Set or specific collection, as opposed to assigning each individual separately to that role context.

Appendix B: Visibility Levels

The functional requirements noted inform levels of visibility that the system can enable; actual assignment of visibility to material is subject to Emory Libraries policy and procedure. Hyrax documentation indicates “Visibility only controls who can view or download your work – it does not control edit access.” When view permissions are assigned for an object or file, those same settings apply to download options.

Standard Hyrax Software Levels of Visibility:

1. Public: Public makes the work available to the general public. Metadata is available to be crawled by search engines for discovery.

2. Institution: restricts access to works and work metadata to users with login privileges. Users will need to be logged into the repository to access the work. (Note: Institution does not mean the Emory campus network: it means that  any authenticated/internal repository system users can view it, relative to other settings assigned at the Admin Set or Collection level.)

3. Embargo: lets you restrict access to Private or Institution until a specified date, when it will be opened to the public or your institution

4. Lease: permits access to the work to the public or Institution until a specified date, when it will be restricted to Private or your institution

5. Private (Note: this status is not fully documented, but appears to mean only visible to the work owner or Administrator only)

Emory Visibility Customizations Requested

1. IP-range restriction for Reading Room access

2. IP-range restriction to restrict visibility to Emory campus network users only (Emory network/VPN connection required to view)

3. Custom embargo duration lengths

1. ETDs: 6 months, 1 year, 2 years, 6 years

2. Emory FIRST to OpenEmory embargo durations: 6 months, 12 months, 18 months, 24 months, 36 months, 48 months, Indefinite.

3. Ensure open-ended date ranges (Hyrax default) are also available for Libraries’ Admin Sets/Collections

4. Custom embargo for sub-object levels: (e.g. ETDs)

1. Embargo content files

2. Embargo content files and Table of Contents

3. Embargo content files, Table of Contents, and Abstract

Appendix C: Permissions Analysis - Matrix of Entities, Activities, and System Roles

See external document. The tables document basic Hyrax functionality as well as anticipated custom functionality for the DLP repository application(s) to provide, and are broken out into sections reflecting different categories of repository system entities:

• Content Entities: Collections

• Content Entities: Objects and Content Files

• Content Entities: Object Supplemental Metadata & Preservation Files

• Permissions-related Entities

• Other/Administrative Information Entities

The matrix entries were based on known DLP requirements produced by other FRGs as well as available permissions-related documentation in the Hyrax Developer Knowledge Base, primarily the Manager’s Guide for version 2.x.