Management FRG - Permissions Analysis and Matrix

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

Date: March 2018

Status: Final Draft

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

The tables on the pages that follow 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.

Permissions Matrix Key for Coding

Yellow striped row = local configurations pending confirmation in Implementation

Red striped row = not currently available via UI

Orange striped row = Emory customization or custom feature

Y: Hyrax default

E: Desired for EUL

* Clarify Hyrax capability

** Per local policy/procedure

1 Selected instances

2 Per assigned visibility level

Content Entities: Collections

Yellow: discuss local needs; Red = not currently available via UI; Orange = Emory customization or custom feature

Y: Hyrax default E: Desired for EUL * Clarify Hyrax capability ** Per local policy/procedure 1 Selected  instances 2 Per assigned visibility level

Emory notes:

• Hyrax 2.1 is releasing Collection Extensions, which introduces more Collection-level roles: Manager, Creator, Depositor, Viewer

• If our Collections are configured properly, this also introduces the potential for a Collection Manager to edit all works in a collection, which is a new feature (previously, Collection Managers can only edit Collection entities themselves, not the works within, unless explicitly granted).

• Investigate the new Collection Depositor role to control users/groups that may deposit directly into a Collection, in coordination with our use of Admin Sets. Collection Depositor will enable Collection-by-collection assignments which could be useful for project work.

• The new Collection Creator role restricts who can create not only Collections, but certain types of collections. E.g. only users in Group A (such as EUL Collection Managers) can create a Library-curated collection, but users such as EUL Metadata Editors cannot.

• See additional user stories at the beginning of this document, which articulate additional local needs for Collections.

Content Entities: Objects and Content Files

Yellow: discuss local needs; Red = not currently available via UI; Orange = Emory customization or custom feature

Y: Hyrax default E: Desired for EUL * Clarify Hyrax capability ** Per local policy/procedure 1 Selected  instances 2 Per assigned visibility level

Emory Notes

• We have a general need to restrict editing around selected sections of metadata only. This capability does not natively exist in Hyrax, and may pose implementation challenges:

• Only Library staff users should be able to see/edit Administrative metadata, not any user with an account. A content creator submitter/depositor who is assisted by a mediated workflow should not see this information nor create it.

• Only Library staff users should be able to see/edit Preservation Workflows metadata.

• Restrict ability to Delete:

• Deletion is a workaround for ETD right now, because it’s hard to replace files. Deletion is used in other workflows as a workaround for reconciling duplicates.

• Versioning UI: an abbreviated version trail should be visible to end users, with full version details shown to Library staff via Preservation Workflows/Events metadata. See the separate Versioning UI document for more information.

Hyrax Notes (from product documentation):

• “The “Relationships” tab lets you add the work to an Administrative Set or a Collection. [Administrator] users can add a work to any Administrative Set or Collection in the repository. Regular users are only able to add works to Collections that they have created or collections for which they have been granted a depositor/manager role. The Administrative Set and Collections fields will be automatically populated with options to which the user has depositor access.

Content Entities: Object Supplemental Metadata & Preservation Files

Supplemental Preservation Files may include additional metadata files or files containing administrative information for the object, distinct from content files (see Emory AIP Specification)

Yellow: discuss local needs; Red = not currently available via UI; Orange = Emory customization or custom feature

Y: Hyrax default E: Desired for EUL * Clarify Hyrax capability ** Per local policy/procedure 1 Selected  instances 2 Per assigned visibility level

Emory Notes

• In Hyrax, we can control visibility at a per-file level as well as at the object level. You can make File A public, File B private.

• Differences for creating/editing supplemental preservation files vs. regular content files are:

• Submission agreements or Deeds of Sale/Gift

• Should be visible to selected (e.g. Admins) staff users only.

• Stored as supplemental files, or unique objects: for implementation, examine if they could be re-usable objects.

• If stored as files, these should a) not be visible to non-staff users and b) not be readily editable by staff except Admins or Admin Set managers

• These may potentially be treated as distinct (administrative) objects of their own right, which are then related to content objects

• OpenEmory has individual files for submission agreements (could they be re-usable objects too?). There is an Assent to Deposit license that comes along with a successful file submission in OpenEmory. This should not be editable by self-depositor. It can be edited by a EUL Admin in the event the license is changed.

• Source metadata (e.g. PREMIS) files should not be edited/replaced (or deleted, per policy) because they are essential documentation of provenance for an object.

• Supplemental Descriptive metadata, on the other hand, may be subject to occasional updates. For implementation, investigate if these are more efficiently handled as supplemental content files.

Permissions-related Entities

Administrative Sets; user accounts/profiles; proxies; user groups; system roles/abilities; workflow or embargo configurations, etc.

Yellow: discuss local needs; Red = not currently available via UI; Orange = Emory customization or custom feature

Y: Hyrax default E: Desired for EUL * Clarify Hyrax capability ** Per local policy/procedure 1 Selected  instances 2 Per assigned visibility level

Emory customization requests:

• Provide UI/self-service ability for Library/stewarding units to manage group membership (for existing groups): would like to add/remove users from an existing group using a UI without needing developer time

• Repository staff need workarounds to address deletion of duplicate objects that occur as a result of system error, if Deletion is restricted

Other/Administrative Information Entities

Other repository administrative objects such as reports, repository-wide configurations, identifiers, authority objects, agreement objects, policy objects, etc. Some entities here are pending scope determination for whether the repository will manage them directly.

Yellow: discuss local needs; Red = not currently available via UI; Orange = Emory customization or custom feature

Y: Hyrax default E: Desired for EUL * Clarify Hyrax capability ** Per local policy/procedure 1 Selected  instances 2 Per assigned visibility level