Proposal
Users have the need to manage groups of users in order to flexibly apply permissions, for example to participate in a collab or give access to a protected service.
The current Collaboratory has the notion of user managed groups through the Identity Manager: https://collab.humanbrainproject.eu/#/collab/476/nav/7229
The new Collaboratory needs a feature that would let users organise permissions in a similar manner.
Definitions
The document describing permissions should be modified as such:
Group Unit
Groups Units represent divisions and sub-divisions of an existing institution. For the Human Brain Project, it is used to represent the project structure: https://www.humanbrainproject.eu/en/about/project-structure/
Groups Units are hierarchical. They are represented as a tree structure, therefore they can:
- have 0 or 1 parent group
unit - contain 0 to n users
- contain 0 to n groups
units
The relations between groups units are meant to be rigid (they should not change a lot).
Groups Units are managed outside of the Collaboratory, by administrators of the institutions. For the Human Brain Project, groups units will be managed through PLUS (not yet implemented).
Groups Units are stored in KeyCloak as groups (different terminology): https://www.keycloak.org/docs/latest/server_admin/index.html#groups
Team
A collab team is the definition of which users, groups units and groups can access the collab with specific roles.
Each collab role can be given to:
- 0 to n users
- 0 to n groups
- 0 to n units
Teams are stored in KeyCloak through linking client roles to users, groups and composite roles: https://www.keycloak.org/docs/latest/server_admin/index.html#roles
Summary
There are global groups which are shared across users and applications. They can be composed. Groups have admins which can manage the group. They are restricted to the Group App. Groups are implemented as roles in a collab client in KeyCloak (KC).
Applications have local roles which represent the use case of the application and are not shared.
Known applications with their roles are: -
- wiki (editor, viewer, admin)
- drive (editor, viewer)
- group app (admin)
KC Client structure
There are global roles and client roles.
- There is a shared client called collab in KC.
- There is a group app with role-admin on the collab KC client and a group client.
- There is a wiki app (xwiki) with it’s corresponding client.
- There is a drive app (seafile) with it’s corresponding client.
Each app defines the roles it creates. Roles can be assigned to groups, units or users.
Wiki teams
The wiki roles are managed in the same way as presently, except that teams can be added to the wiki roles. Wiki roles are not reuseable.
Use cases
Creating a PCO team
A administrator from the PCO creates a PCO team in the team app and adds everyone from the PCO. She also adds certain other key members as admins for the team.
PC Apero Forum collab
The event organiser (EO) creates a PCO Apero Forum collab. The EO adds the PCO team previously defined as editors of the collab. The EO explicitly adds a few collaborators as admins.
Sharing a library (drive) with the PCO
A PCO member (PM) creates a library in the drive. The PCO member shares the library with the PCO team created above as editors.
Organising a workshop.
An event organiser (EO) creates an Event-X collab. The EO creates a team in the Team app called Event-X. The EO creates a Event-X-organisers team in the team app. The EO adds co-organisers to the Event-X-organisers. The EO assigns the editor role to the Event-X-organisers to the Event-X collab. The EO assigns the viewer role to the Event-X members. The EO adds members to the Event-X team in the Team app when they sign up for the workshop.
MOOC
A MOOC coordinator (MC) creates the MOOC-A, MOOC-A-teachers, MOOC-A-admins, MOOC-A-corrector teams in the team app. The MC assigns the admin role to a MOOC-A collab to the MOOC-A-admins. The MC adds the MOOC-A-teachers to the editor role for the collab. A third party homework application has a corrector and submittor roles assigned respectively to the MOOC-A-corrector and MOOC-A teams.
Implementation
The team app can be implemented as a lightweight service.
The following motivations explain why we should create it as a lightweight service: - it needs to be robust - it needs a clear security model
The team app’s backend is KC.
Limitations
Namespace pollution: Users can create any team. There can be official looking teams which are confusing. There can be lots of teams. To avoid users relying on teams wrongly, the team admins should be visible when selecting the team.