User Groups

[msheller]

We would like to add group controls to MedPerf to accommodate organizations with multiple users. The goal is to enable multiple employees at an organization be able to register/update assets, run evaluations, etc...

I'm looking toward a system that is simple, not fully-featured, but gets the most value for the least risk. Here is an initial proposal:

New Records:

• Group record: has an owner, name, and list of users in the group
• Group MLCube association record: same as benchmark model, except instead of "benchmark" FK, it has "group" FK
• Group Dataset association record: same as benchmark dataset, except instead of "benchmark" FK, it has "group" FK
• Group Benchmark association record: same as benchmark model, except instead of "dataset" FK, it has "group" FK

New APIs:

• Group apis (see master table for exhaustive permission list)
• Group association apis (see master table for exhaustive permission list)
• Group records are created by users in a similar fashion as a benchmark, meaning they require platform admin approval for a pending group creation request (OPEN: is this really necessary?)
• A Group is owned by the creator
• A Group name must be unique
• Group owners can rename the group, add users to the group and remove users from the group
• Group owners can request/approve group associations
• Benchmark/Dataset/MLCube owners can request/approve group associations
• Group members can remove themselves from a group (OPEN: will we need to have group membership be another association-like step?)

General Notes (find details in the API permission spreadsheet):

• All members of a group have equal permissions wrt associated dataset/benchmark/result/mlcube records.
• The group record itself can only be edited by the group owner.
• Users cannot request group membership (for now). Instead, the group owner manually does the adding/deleting.
• Group associations with a benchmark cannot be done outside the development state, since this could change which users are able to view results AFTER a user agrees to participate in a benchmark. On the other hand, group MEMBERSHIP can change, and participants should be clear that trusting a group means to trust a group owner to appropriately manage access (helpful to consider that this same trust exists in the form of trusting a user to appropriately manage their own credentials).
• Group associations with datasets and mlcubes can be made at any time, as these assets should be long-lived, and changing who manages said asset will be relatively common.
• Members of a given group should be part of the same organization/committee. Groups are not meant to be "people interested in a topic", but "colleagues that know each other and are trusted to work on the same assets", e.g. employees of the same research lab or a challenge organizing committee.

[msheller]

EDIT: I have updated the API endpoint document. LMK what I've missed!

[msheller]

@johnugeorge , users should be able to remove themselves from groups. Should this be its own end-point to simplify the permission check? Otherwise, the permission check would need to examine the contents of the request, right?

[msheller]

I'm inclined to make group association requests require the owners, and not allow associated group members to be able to request/approve. For example, if I am a BraTS Challenge organizer member, but not owner, and there is an mlcube associated with the BraTS Challenge organizers (but I am not that mlcube's owner), I cannot request an association between that mlcube and "Hasan's Heroes".

My thinking is that this is a rare operation, so the convenience of allowing group members to do it isn't very impactful, and by not allowing it, we save ourselves some significant headache in imagine how it could be abused.

[alexkarargyris]

@msheller Can you expand on "All members of a group have equal permissions wrt associated dataset/benchmark/result/mlcube records." above?

Is there a list of user roles?

[msheller]

@alexkarargyris , there are only two "roles" in a group, owner and member. A group owner can manage who is a member and can request/approve a "group association" to a benchmark, mlcube, or dataset. Once a benchmark, group or dataset is associated with the group, all members of the group can update that benchmark, mlcube or dataset record.

In other words, the group owner is responsible for who is in the group and what the group can access (along with the record owner). For example, if Max creates a group called DKFZ, adds user Ralf to it, and associates the group with a benchmark (which requires the benchmark owner approval), both Max and Ralf can now push updates to the benchmark via the "put" API.

[aristizabal95]

Can an entity be associated with multiple groups? If so, how would update permissions work there? It feels like having two or more groups associated to an entity could cause collision because of a group making edits without the aknowledgement of the other groups

[aristizabal95]

Nevermind, I'm guessing the same collision can happen within a group, where someone from the group can modify the entity without aknowledgement from the other group, so this is not something we have control on, either intra-group or between groups

[aristizabal95]

What are the permissions that are given to a group member with regards to a Benchmark? For example, will a group member be able to approve associations?

[msheller]

This should be covered in the "general notes" section above. LMK if it's confusing and I'll try to clarify!

[hasan7n]

1. Let's have a field "access_level" or "role" in a Group-Entity Association, which defines the permission level of this group to the associated entity. We can leave it for now as a placeholder (role=owner always).
2. @msheller regarding point 4 in the general notes section:
   a) isn't the trust model as follows? "participiants trust the benchmark owner. the benchmark owner trust associated group owners".
   b) It seems to me that "associating a group to a benchmark during developement" and "adding a new user to a benchmark group during operational model" should have the same trust level. What am I missing?

[hasan7n]

Q for Johnu: what is an efficient way to create a Group-Entity association table instead of three different tables. dummy inheritence?

[msheller]

Point 1 seems safe. We could also defer, since adding a field with default value is an easy DB migration. I don't have a strong preference.

For point 2a, that's correct. For point 2b, I think the confusion is that a Group association to a benchmark is setting the owning group of the benchmark, which is akin to changing the owner. Does that make sense? sorry for the confusion (it took me a minute to recall what that meant :P)