Hi Ben,
Thanks! Obviously, this is a lot for anyone to digest so as we've discussed
at
for people to comment on specific points.
I'm also going to cc the dvn-auth list so we don't miss anybody.
People are welcome to discuss these ideas in this very thread too, of
course. I just think the Google Doc will help focus the conversation. :)
Phil
On Thu, Jul 10, 2014 at 9:28 AM, Ben Companjen <ben.companjen(a)dans.knaw.nl>
wrote:
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.