Version 8.1 by allan on 2019/05/08 09:36
Show last authors
1 = User registration and accreditation workflow =
2
3 == User types ==
4
5 There are anonymous users and four levels of accredited users.
6
7 * **HBP members** are members that are accredited and recognized by an acting official as having a contract tied to the HBP.
8 * **HBP partners** are members that are accredited and recognized as having a contract with a partnering project.
9 * **HBP clients** are users that are accredited and ???
10 * **HBP guests** are users that are registered and have provided an email which belongs to a list of recognized institutions.
11
12 == Accreditations ==
13
14 Accreditations are a way of recognizing that a user has membership with a group that is recognized in the HBP stucture as a representative of an institution. Thus, a user must be part of a group such as an SP in SGA2, and a member of an institution, such as EPFL.
15
16 * Accreditations are represented as a group. //NOTE: see footnote for technical discussion. This might not be sufficient.//
17
18 == System components ==
19
20 **Keycloak** is the identity and authentication manager (IAM) application. It is used for single sign on and stores user information in a profile.
21
22 **PLUS** is an internal tool to the HBP where project management is done. It is a Keycloak client and drives the management of certain data stored in Keycloak through Keycloak's API.
23
24 == Keycloak user profile and groups ==
25
26 Keycloak stores key value fields on a user profile. They can be shared with other applications by allowing scopes. These are:
27
28 * username
29 * full name
30 * login email (belonging to an institution
31 * contact email
32 * freeform about? (users could enter affiliations, other contact info, etc?)
33
34 == Extra user information for special purposes ==
35
36 There is a requirement to hold statistics on members' gender for gender equality policies. There are many alternatives on how to store this.
37
38 The requirements are:
39
40 * this information is only available for the purpose it was collected for, and to those who are authorized to access it for this purpose.
41
42 At the moment, the only known field is gender, and the statistics will only need to be extracted a few time per year.
43
44 To limit the cost of development, this could be implemented as a private field in Keycloak which is not part of the public user profile. It could be extracted from the restricted Keycloak API only by administrators.
45
46 == Workflow ==
47
48 [[image:workflow.png]]
49
50 === Registration ===
51
52 The initial step is conducted by the new user. It happens in Keycloak.
53
54 The user visits the Keycloak registration page. The user provides an email, username, name, and optional fields. The user must also agrees to the T&C. If the email's domain is validated against a whitelist of domains, the user account is created and added to the **HBP Guest** group. If the user's email domain is not in the recognized domains, the user is presented with a page specifying how they can request that their institution be added to the list.
55
56 To obtain a higher level of accreditation, users can go to PLUS to request to be accredited within specific groups. A manager or group of managers is notified and responsible for approving or rejecting the requests.
57
58 == Revocation ==
59
60 An accreditation can be revoked by an admin of an accreditation group. The managers are responsible for ensuring the list of validated members is up to date.
61
62 == Administrators ==
63
64 Who manages the administrators?
65
66 = Notes =
67
68 == Questions on Keycloak's capabilities ==
69
70 * should we store accreditations there? Keycloak has a KV storage on users. How do we represent the accreditation eg (SP05 + EPFL)? 1 group per accred will make a huge cross product. Or we store it as an attribute on the user: (accred1: SP5, instit1: EPFL) (accred2: SP11, instit2: JULICH) Or we store it in plus.