Wiki source code of Permissions explained

Last modified by messines on 2022/02/24 12:03
Show last authors
1 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>>doc:Collabs.the-collaboratory.Tips to users.Architecture.Permissions.Authentication & Authorisation using OIDC.WebHome]].
2
3 {{toc numbered="true"/}}
4
5 = Definitions =
6
7 == User ==
8
9 A user is an individual, it is the digital identity of an existing human being.
10
11 Users are stored in KeyCloak as users (same terminology): [[https:~~/~~/www.keycloak.org/docs/latest/server_admin/index.html#user-management>>url:https://www.keycloak.org/docs/latest/server_admin/index.html#user-management]]
12
13 == Unit ==
14
15 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/>>url:https://www.humanbrainproject.eu/en/about/project-structure/]]
16
17 Units are hierarchical. They are represented as a tree structure, therefore they can:
18
19 * have 0 or 1 parent unit
20 * contain 0 to n users
21 * contain 0 to n units
22
23 The relations between units are meant to be rigid (they should not change a lot).
24
25 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).
26
27 Units are stored in KeyCloak as groups (different terminology): [[https:~~/~~/www.keycloak.org/docs/latest/server_admin/index.html#groups>>url:https://www.keycloak.org/docs/latest/server_admin/index.html#groups]]
28
29 Follow [[here for more details about units and accreditation>>doc:Collabs.the-collaboratory.Tips to users.Architecture.Permissions.Authentication & Authorisation using OIDC.WebHome||anchor="HUnits%3AtheOrganistationalStructure"]].
30
31 == Roles ==
32
33 Collabs have 3 roles: viewer, editor, admin.
34
35 Each role is bound to local permissions in applications that form a collab (for example the wiki or the drive).
36
37 Usually:
38
39 * viewer can access the collab linked data in the application in read-only mode
40 * editor can modify the collab linked data in the application
41 * admin can edit the settings of the collab in the application
42
43 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>>url:https://www.keycloak.org/docs/latest/server_admin/index.html#client-roles]]
44
45 == Architecture of permissions in keycloak ==
46
47 You can found here some documentations about permissions in our system based on keycloak roles and groups
48
49 [[https:~~/~~/gitlab.humanbrainproject.org/HumanBrainProject/xwiki-distribution-collaboratory/-/wikis/iam/permissions>>https://gitlab.humanbrainproject.org/HumanBrainProject/xwiki-distribution-collaboratory/-/wikis/iam/permissions]]
50
51 [[https:~~/~~/gitlab.humanbrainproject.org/HumanBrainProject/xwiki-distribution-collaboratory/-/wikis/analysis/permission>>https://gitlab.humanbrainproject.org/HumanBrainProject/xwiki-distribution-collaboratory/-/wikis/analysis/permission]]
52
53 == Team ==
54
55 A Collab team is the definition of which users and units can access the Collab with specific roles.
56
57 Each Collab role can be given to:
58
59 * 0 to n users
60 * 0 to n units
61
62 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>>url:https://www.keycloak.org/docs/latest/server_admin/index.html#roles]]
63
64 = Requirements =
65
66 == Secure ==
67
68 Any piece of information or data that is protected for access should be done so in a secure manner.
69
70 == Auditable ==
71
72 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.
73
74 == Flexible ==
75
76 The access management system has to be flexible enough to fulfill users use cases.
77
78 == Manageable ==
79
80 Users must be able to modify the level of access other users have on their resources in a simple way.
81
82 == Trustworthy ==
83
84 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.
85
86 == Extensible ==
87
88 External services must be able to leverage the Collaboratory access management system to reduce engineering costs.