search

NCEAS / metacatui

MetacatUI: A client-side web interface for DataONE data repositories
https://nceas.github.io/metacatui
Apache License 2.0
42 stars 27 forks source link

Group and Portal dataset permissions management #1640

Open mbjones opened 3 years ago

mbjones commented 3 years ago

This Epic describes a new feature to streamline permissions management by groups of researchers (e.g., labs and projects) that need a consistent approach to managing permissions on collections of data.

The current permissions model relies on individual changes to ACLs to data objects, metadata objects, and resource maps to keep data packages accessible to groups of users. The new UI in #1232 will help by allowing users to set permissions properly at create() and update() time, but still requires users to remember to do so. For example, assume data package A exists with files A1 and A2, and they all have been assigned changePermission to group G1. Group members U1 and U2 can make changes to the package and to files in the package, and all should be well. However, if U1 adds a new file A3 to the package through MetacatUI, it seems the default permissions on that new file will only have the rightsHolder set to U1, and now access by group member U2 for file A3 will not be possible (although maybe this behavior is changed under #1232). This problem as it has arisen is described in issue #1638, but there are other related problems that would arise.

A default permissions model feature request

When users are members of a group (e.g., a lab group), or when they are acting in the 'context' of a portal, it would be useful to provide some default ACL and ownership handling for new objects they create. Thus, if a user adds file A4 to package A, then the new file could be created with the same default ACLs as package A. So, for example, if group G1 is assigned to A with changePermission, then the new file A4 would be also created with G1 having changePermission. The trick here is figuring out (or setting) the right set of default ACLs for files and data packages created in different contexts. Here are some example scenarios we could handle:

Case 1: default to package permissions

Case 2: default to include group in new and updated package changes

Can we associate a default ACL for group members? If so, how do we determine when a new package is being created as part of the "group", versus just as a user? Where would we store the default ACL?

Case 3: default to portal-configured default ACL

There's a lot to discuss around how these defaults would work and what the best defaults would be, as well as how to determine when a user is acting as part of a group, part of a portal, or on their own in some way. Looking forward to the discussion. We would also have to determine what happens when mutliple defaults could apply (e.g., a user is a member of group G1 with a default ACL, but also working in portal P1 with a default ACL, and updating a data package D1 with existing permissions that differ from the other defaults). In those cases, which defaults would apply, or would they be merged in some way?

amoeba commented 3 years ago

Good writeup. For Case 1, I say: Yes, let's do it. Newly-added objects get the same access policy as the resource map.

For Case 2, I think we could do some cool things there. LDAP allows us to store arbitrary key-value-pairs so I think we could store a default ACL for the group there and group admins could set or change the value from a web UI. Then when a user submits a package, we could add an intermediate step before the user lands in the editor to choose to "Submit for myself" or "Submit as part of {group}" and we could list their groups. We'll need to think about what happens when a user submits as part of a group that doesn't have a default ACL because nothing special would happen. This approach could be expanded to store metadata templates and possibly other group-specific stuff too.