The Collaboratory embeds a powerful and easy to use access management system. This document presents an overview of how it works. For a more detailed explanation, read up on authentication and authorisation in the collaboratory.
Definitions
User
A user is an individual, it is the digital identity of an existing human being.
Users are stored in KeyCloak as users (same terminology): https://www.keycloak.org/docs/latest/server_admin/index.html#user-management
Unit
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/
Units are hierarchical. They are represented as a tree structure, therefore they can:
- have 0 or 1 parent unit
- contain 0 to n users
- contain 0 to n units
The relations between units are meant to be rigid (they should not change a lot).
Units are managed outside of the Collaboratory, by administrators of the institutions. For the Human Brain Project, units will be managed through PLUS (not yet implemented).
Units are stored in KeyCloak as groups (different terminology): https://www.keycloak.org/docs/latest/server_admin/index.html#groups
Follow here for more details about units and accreditation.
Roles
Collabs have 3 roles: viewer, editor, admin.
Each role is bound to local permissions in applications that form a collab (for example the wiki or the drive).
Usually:
- viewer can access the collab linked data in the application in read-only mode
- editor can modify the collab linked data in the application
- admin can edit the settings of the collab in the application
Collab roles are stored in KeyCloak as client roles in a specific client: https://www.keycloak.org/docs/latest/server_admin/index.html#client-roles
Team
A Collab team is the definition of which users and units can access the Collab with specific roles.
Each Collab role can be given to:
- 0 to n users
- 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
Requirements
Secure
Any piece of information or data that is protected for access should be done so in a secure manner.
Auditable
The level of access of a given user for a given resource has to be auditable: at least administrators of the system must be able to verify the access and determine how this access level is granted.
Flexible
The access management system has to be flexible enough to fulfill users use cases.
Manageable
Users must be able to modify the level of access other users have on their resources in a simple way.
Trustworthy
Users need to trust the access management system before they store any private piece of information. The access management system needs to be easy enough to understand for users to trust it.
Extensible
External services must be able to leverage the Collaboratory access management system to reduce engineering costs.