Oasis specific visibility, rights, and role management

[markus1978]

NOMAD has only a very simple management of visibility, rights, and roles tailored towards publication on the central server.
Entries have owners, coauthors, and "shared with" users. All users are the same. All users have the same rights on the central server and on each Oasis. For the Oasis we need a more powerful management of visibility, rights, and roles.

In #1 the notion of "project" is introduced. Here we still talk about uploads as they are currently used in NOMAD. As entity uploads/"projects" will obviously play an important role in these features.

Stories

• Oasis owner control who can upload and access data on the Oasis
• Oasis owner can invite users to their Oasis
• upload owner manage who can modify files and see unpublished data

Requirements

• there are roles "owner", "author", "reviewer". These roles can be assigned to users per Oasis and per upload, [maybe] per entry
• Oasis roles: owner (invite, manage users), author (create uploads), reviewer (view published uploads)
• upload roles: owner (manage users, publish, delete), author (add files, delete files), reviewer (view unpublished data)
• Oasis owner can determine that all NOMAD users get a certain default role (e.g. "reviewer")
• upload roles can be assigned to all users, independent of them belonging to the Oasis
• on the central NOMAD all users are "authors", i.e. can create uploads
• Oasis owner have owner rights on all Oasis uploads

Implementation

• the Oasis gets a singleton entity to manage users
• we extend the user API to manipulate the Oasis user roles
• we add a GUI page to manage Oasis users
• the upload part is a "side quest" for A flexible staging area #1

Later feature request might extend this with a "team" or "group" notion. We should start with "user's only" to have less complexity in the beginning. As a general comment, NOMAD's user rights management will be limited due to its non relational backend, where most relations (e.g. team-user) need to be "unfolded" on lower levels (e.g. in elasticsearch).

[markus1978]

We implemented a very simple white-list based restriction mechanism that you can use, if you cannot wait for this. We will add this to the upcoming NOMAD v0.10.0 release. You can test with the pre-release build:
gitlab-registry.mpcdf.mpg.de/nomad-lab/nomad-fair:oasis-with-auth (i.e. the regular nomad docker image with oasis-with-auth tag).

This will allow you to add a list of NOMAD account email addresses to your nomad.yaml and only those accounts can access your Oasis:

oasis:
    allowed_users:
        - [email protected]
        - [email protected]

[helgestein]

Can this get a bump? It would be great to have the possibility to have multiple users within an oasis wth some more fine grained acess controls of who sees what.
Example user stories beyond what is written above:

• Uploader has data that needs to be in database but contains sensitive information (i.e. patient data) that should only be disclosed to some people the uploader specifies
• Uploader has data that is originating from a project only a group of people is allowed to see (industry or protected project)
• Option to set embargo period on Oasis to infinity in well defined use cases