Re: [dvn-auth] [Dataverse-Users] Distributed user/group/access management

Hi IQSS, all, I'm looking at the future of the Dutch Dataverse Network, which will at some point move to Dataverse 4, and I'm trying to find out how our current model and procedures of distributed user and role management (should) map to Dataverse 4. Philip has pointed out the user model (which is not final) at https://raw.githubusercontent.com/IQSS/dataverse/master/doc/Architecture/Us…, but this class diagram is only one view of the system and I could not be sure that my ideas would fit. So, let me get to the contents of my actual message: a bit of background, an outline of handling access to dataverses in the current situation, use cases I am thinking of for the future (when we switch to v4), some related ideas and finally a few questions. Background: The Dutch Dataverse Network (DDN) is DANS providing Dataverse-as-a-service to universities and other research institutes, based on Dataverse (well, DVN) 3.6.2 with login and semi-automatic account creation via SAML. When the DDNaaS moved from the University of Utrecht to DANS, we implemented SAML using Shibboleth (fronting Glassfish with Apache) and centralised the network admin role at DANS, instead of having a network admin at every 'network participant'. For a longer introduction and link to the code on GitHub, let me refer to a thread on the dvn-auth list: https://lists.iq.harvard.edu/pipermail/dvn-auth/2014-April/000006.html (answer from Philip, my first introductory email is included but the original did not end up in the archives correctly) and https://lists.iq.harvard.edu/pipermail/dvn-auth/2014-July/000008.html (sent today about location of code). Current ways to manage dataverse creation and edit rights in DDN: - by default no-one gets creator/edit rights on account creation - university can decide to allow people to have a dataverse with admin role or access to dataverse with certain other role, because the university library has dataverse creator accounts Current ways of getting account with rights to certain dataverses in DDN: - first create account via federation 1. user logs in for the first time via federation 2. user creates an account 3. user asks: - library to get dataverse - dataverse admin to get access - first create account via Dataverse options -> Create User 1. dataverse admin / library creates 'normal' account with email address set to the address passed on successful login via the federation 2. dataverse admin / library gives user certain role(s) 3. user logs in via federation and has rights set Use cases for the future: - new users should get rights to certain lower-level dataverse(s) based on user's attributes that may or may not be included in SAML response; users need not wait for their access rights to be managed (i.e. go in, click "oh boy, I want my account" and start doing things without allowing them to create a mess). E.g.: - all students in a programme or course get read/dataset creation access to a programme/course dataverse - all faculty of a certain faculty get read and/or dataset creation access to a faculty dataverse - the network admin ("back office") only supports the university libraries/data librarians ("front office"); front office staff determines who needs access to what and supports users when necessary - the dataverse network has no access to LDAP servers or other services at universities ("clients") to query for user attributes that are not in the SAML response - a front office must have admin access to all dataverses at their university so that they can manage it after a researcher/student leaves Ideas relevant to the above use cases: - if real-time access to LDAP or similar services is unavailable, front offices could use lists of email addresses to pre-authorise certain rights to certain dataverses - the nested dataverse structure helps a lot in that a front office (as a dynamic group of staff users) are admin of top dataverses and thus have access to all sub-dataverses - a front office can be a (somewhat) dynamic group of users, whose group membership allows them to manage a top dataverse and dataverse inside that top dataverse, but the sub-dataverses do not belong to any one user in the front office group (currently all dataverses have a user as creator/owner, whose admin role cannot be changed. I deactivated the account of someone who had created five dataverses, but had left the institute, so that I didn't have to go into the database and change the ownership. The institute now uses a shared user account for administration purposes.) Questions: - Does/will Dataverse 4 support use cases like these? - Is my assumption in the second Idea correct? - Will I easily find out if I participate in the usability test? - Do you have any suggestions to do things differently with similar results? - Is anyone interested in discussing archimate views of Dataverse services? :) Well, thanks for getting to the end of this email. I'll be happy to provide any necessary clarification. Groeten, Ben Ben Companjen Information scientist / Information manager ben.companjen(a)dans.knaw.nl +31 6 1334 9717 Skype: bencompanjen *Data Archiving and Networked Services (DANS)* DANS promotes sustained access to digital research data. See www.dans.knaw.nl for more information and contact details. DANS is an institute of KNAW and NWO. DANS | Anna van Saksenlaan 51 | 2593 HW The Hague | P.O. Box 93067 | 2509 AB The Hague | +31 70 349 44 50 | info(a)dans.knaw.nl | www.dans.knaw.nl -- You received this message because you are subscribed to the Google Groups "Dataverse Users Community" group. To unsubscribe from this group and stop receiving emails from it, send an email to dataverse-community+unsubscribe(a)googlegroups.com. To post to this group, send email to dataverse-community(a)googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/dataverse-community/CFE461B6.30A95%25ben.… <https://groups.google.com/d/msgid/dataverse-community/CFE461B6.30A95%25ben.companjen%40dans.knaw.nl?utm_medium=email&utm_source=footer> . For more options, visit https://groups.google.com/d/optout.