Date & Time

  • December 13th 16:00 UTC/GMT - 11:00 EST

This call is a Community Forum call: Sharing best practices and challenges in the use of existing DSpace features

Dial-in

We will use the international conference call dial-in. Please follow directions below.

  • U.S.A/Canada toll free: 866-740-1260, participant code: 2257295
  • International toll free: http://www.readytalk.com/intl 
    • Use the above link and input 2257295 and the country you are calling from to get your country's toll-free dial in #
    • Once on the call, enter participant code 2257295

Agenda

Community Forum Call: DSpace authentication and authorization demystified

Sharing best practices, challenges, and questions. The call will be dedicated to answering participants questions and discussing.

Following topics are considered in-scope of the conversation:

  • Authentication
    • Normal groups & Special groups (LDAP)
    • ... 
  • Authorization
    • Policies
    • Working with the policy wildcard tool / advanced authorization
    • Default policies on collection level and how they are applied to items & bitstreams.
    • ...
  • DSpace item state definitions

Information about authentication and authorization, groups and policies, is currently scattered over different pages in the DSpace documentation and is quite limited. As an outcome of the call, participants can indicate which pieces of information from the call are candidates to be added to the general DSpace documentation.

If anyone wants to volunteer to extend the documentation for authentication and authorization, by al means feel welcome.

Related open tickets in JIRA:

Unable to locate Jira server for this macro. It may be due to Application Link configuration.  

Unable to locate Jira server for this macro. It may be due to Application Link configuration.   

Unable to locate Jira server for this macro. It may be due to Application Link configuration.

Preparing for the call

Bring your questions/comments you would like to discuss to the call, or add them to the comments of this meeting page.

If you can join the call, or are willing to comment on the topics submitted via the meeting page, please add your name, institution, and repository URL to the Call Attendees section below.

Meeting notes

With the DSpace community calls the DCAT group wants to open up the DCAT calls and get groups of DSpace administrators together. The main topics of DSpace community calls are current DSpace features and how administrators are (or are not) using them. The goal is not only to discover flaws or opportunities for improvement of these features. We also want to share our best practices and ideas to learn from each other.

DSpace Authentication and authorization

Authentication is a rather technical aspect, and thus more interesting for DSpace developers than DSpace administrators. For this reason it was more interesting to focus on the authorization aspect.

When it comes to DSpace authorization one thing is very clear. It needs to be better documented. Up to now the rights of some authorization roles are not sufficiently elaborated upon in the DSpace documentation.

Discussion

During this meeting's discussion one attendee mentioned using only the administrator role, as they were told the other roles did not function well. One issue with only using this administrator role is that it is extremely powerful. E-persons with that role are even capable of changing things like the metadata profile.

Editing metadata after submission

A participant mentioned often receiving the request from submitters to edit their own submissions' metadata. To avoid the main DSpace administrator has to edit all of those submission there currently is no other option than giving submitters the collection administrator role. This however, implies that those submitters are also able delete bitstreams, which the participant wants to avoid.

One way of dealing with this is granting collection administrators granular access by altering the DSpace config file. In this config file it is possible to disable the collection administrator's permission to delete bitstreams.

Although the authorization described above does grant submitters access to the metadata records of their own submission so they are able to modify them, it does have a disadvantage. By applying this method, all submitters are able to alter all items of the entire collection, not only their own.

At this moment there is no out of the box way to grant submitter just enough access to alter their own metadata records after submission, without providing them edit rights to other items.

Making items invisible for end users

One participant wanted to make certain items invisible to the end user. The participant first tried to give these items the 'private item' status. Although this did make those items invisible to the end user, those item were still harvested through OAI-PMH. This forced the participant to make those items into withdrawn items.

It is possible the issue with harvesting private items was caused do to a bug in earlier DSpace versions. Using the latest DSpace version may already fix the issue.

On a side note, the private item status is one of the things currently inadequately documented. It was mainly created to avoid a certain item from being indexed by search, and thus make it not retrievable through the search function. At the same time, users with the item's url would still be able to view the item.

One participant mentioned using the withdrawn status as an embargoing tool. They did not want to limit the embargo to the bitstream, but instead embargo the entire item. As DSpace does not support this out of the box, they give the item the withdrawn status until the embargo period is over. One downside is that those items are difficult to retrieve, as they already were private items before they were withdrawn, and thus they can not be searched for.

Information provided in the UI

Multiple participants mentioned DSpace is currently not providing information regarding affected items when altering authorizations. It would be useful to have both a report before and after authorization changes. The report prior to the change could indicate how many items will be affected. The report after the execution could summarize what exactly has changed.

Request a copy

A participant mentioned internal staff at one institution was extremely enthusiastic about the request a copy feature for metadata only items. The reason for this is that it are the authors themselves who receive the request a copy emails, and so the authors could see who was interested in their work. These requests for copies are often used by them to examine possible research collaborations, and function as a conversation starter.

DSpace 7 outreach group

The DSpace 7 outreach group is still looking for a chairman. The required commitment for the outreach group is likely to be able to attend one meeting every two weeks. Participating in this group has the benefit of being able to closely interact with developers and stakeholders, and have influence in the DSpace 7 project.

DCAT topics for 2017

Up to now there is no formal topic list for 2017's DCAT meetings. The DCAT chairs will send out an email with suggestions on subjects, which is open for other proposals.

Call Attendees

  • No labels

9 Comments

  1. Notes about the policy wildcard tool:

    • accessible from "authorizations" admin menu entry
    • No documentation in the general DSpace docs
    • "Description" field is used to fill out the policy field when a new policy is added. Is not used when policies are deleted
    • The clear policy button will only take into account the selected collection and the type of object (items or bitstreams). It will then proceed with deleting all policies for those objects in that collection. They interface makes you think that it would only remove a specific type of policy for a specific group, but it effectively deletes all.

    related pieces of code:

    https://github.com/DSpace/DSpace/blob/master/dspace-xmlui/src/main/java/org/dspace/app/xmlui/aspect/administrative/FlowAuthorizationUtils.java#L414

    https://github.com/DSpace/DSpace/blob/master/dspace-xmlui/src/main/resources/aspects/Administrative/administrative.js

    https://github.com/DSpace/DSpace/blob/master/dspace-xmlui/src/main/java/org/dspace/app/xmlui/aspect/administrative/authorization/AdvacedAuthorizationsForm.java

    Basic: Which policy conveys which permission on which object?

    READ-WRITE-ADD ... can mean different things for collection, community, item, bitstream, bundle, ... as far as I know there is no single resource/writeup that summarizes this.

    Public 3rd party docs/instruction regarding Authorizations

    Covers functionality in different DSpace versions.

    https://www.ohiolink.edu/sites/ohiolink.edu/files/uploads/UsersGroupsAuthorizations.pdf

    https://cache.kzoo.edu/bitstream/handle/10920/5747/DSpaceProceduresManual.pdf?sequence=10

  2. We make use of the authorization system in the following manner

     

    • General rights strategy

      • Collection edit/submit rights are granted by user name

      • Faculty submission rights are granted by Shibboleth group

      • Collection/item view rights are granted by Shibboleth group

      • Streaming media is linked from DSpace - streaming media access rights are handled separately

    • Collection content is either publicly available or restricted to the university community
    • Items under embargo may be restricted to 
      • the university community
      • everyone (except repository administrators)
    • We have a "preview" community for collections under development that is restricted to a specific audience
      • This allows us to provision production handles while custom theme/facet code is under development
      • While this can be useful, it does create some challenges.
        • We have hard-coded handle names in code to suppress this community from view
        • After we move a collection from the preview area to its proper location
          • Need to alter collection rights
          • Need to alter item/bitstream rights for any items placed in the collection
          • Need to re-index the collection in order for browse to update properly

    Past challenges that we have encountered

    • Restricted content appeared in the discovery index (fixed in DSpace 4 I believe)
    • Restricted content appeared in the OAI index (fixed in DSpace 5 I believe)
    • Restricted thumbnails appear as broken images
    • Item pages do not convey the accessibility of content
      • Once we migrated to DSpace 5 and Mirage 2, we noticed a lock icon next to our bitstream links (a big improvement)
      • We have custom XSLT code that queries access rights and replaces a thumbnail with the text "Restricted Thumbnail"
    • Viewing access rights in XMLUI
      • Item metadata and bitstream names are available at /metadata/xxx/yyy/mets.xml
      • Bitstream access rights are available at /metadata/handle/xxx/yyy/mets.xml?rightsMDTypes=METSRIGHTS
      • When processing an item page, it is easy to query the METSRIGHTS data for that item
      • When processing a list of items in search/browse it would be more expensive to pull METSRIGHTS for every item
      • Evaluating thumbnail access in XMLUI
    • Sample links
      • Sample search pulling content with embargoed content
        • Broken image links are suppressed
      • Sample item with lock icon next to bitstream, "Restricted Thumbnail" in place of image, visible embargo end date
        • XSLT displays "Restricted Thumbnail" to avoid broken image icon
      • Sample item linked to streaming server with permissions enforced by streaming server

    Other notes

    • The link to the raw collection policies ("Policies for X") is now only available through "Authorizations"
      • I used to be able to access this from the "Roles" page
    • When editing a group role, one can accidentally edit a group rather than the policy
      • The UI can be a bit confusing for someone who does not perform this action often
    • The wildcard tool is necessary but intimidating

     

  3. Collection admin config rights

    This is in dspace.cfg, check here what you can change:

    https://github.com/DSpace/DSpace/blob/master/dspace/config/dspace.cfg#L260

  4. At Edinburgh we've also found ourselves sometimes using the Withdrawn function to avoid items being accessible through the Request a Copy function. So we have set up a tombstone function, which I've written about on our blog - it allows us to make the files completely inaccessible while the metadata is visible - http://datablog.is.ed.ac.uk/2016/12/07/datashare-upgraded-to-v2-3-the-embargo-enhancement-release/ . Apologies for joining the call late, had some issues with the audio because of my laptop docking station.

  5. About Request a Copy - we had a handful of complaints of junk mail after we activated it, but that was all. The bigger issue was when the depositor (postdoc) leaves the institution but still has the power to Agree to any request-a-copy that comes in, and we've had to withdraw one item temporarily to stop that. So the tombstone feature (or directing the requests to a support team) would deal with that issue.

  6. I agree with Mariya that it would be nice if the file-level embargo dates were displayed publicly on the item page, for full transparency.

  7. Following yesterday's meeting, I made a short video about the Advanced Policy Manager tool