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
- Private item vs embargoed item etc
- 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:
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
- Bram Luyten (Atmire)
- Maureen Walsh (Ohio State UNiversity)
- Iryna Kuchma (EIFL)
- Mike Marttila (Georgetown University)
- Felicity Dykas (U of Missouri, https://mospace.umsystem.edu/xmlui/)
- Mariya Maistrovskaya (University of Toronto)
- Anne Lawrence (Virginia Tech, https://vtechworks.lib.vt.edu/)
- Daniel Draper (Colorado State University, https://dspace.library.colostate.edu/)
- Terrence W Brady (Georgetown University)
- Ignace Deroost (Atmire)
9 Comments
Bram Luyten (Atmire)
Notes about the policy wildcard tool:
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
Terrence W Brady
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
Past challenges that we have encountered
Other notes
Bram Luyten (Atmire)
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
Pauline Ward
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.
Pauline Ward
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.
Pauline Ward
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.
Bram Luyten (Atmire)
Links for the story I mentioned about request a copy:
https://lirias.kuleuven.be/request-a-copy-report
https://lirias.kuleuven.be/handle/123456789/231035
Bram Luyten (Atmire)
DSpace 7 UI outreach group (join now !!!!!!!!!!)
DSpace 7 Marketing Working Group (2016-2020)
Bram Luyten (Atmire)
Following yesterday's meeting, I made a short video about the Advanced Policy Manager tool