Wiki source code of User registration and accreditation workflow
Show last authors
author | version | line-number | content |
---|---|---|---|
1 | = User registration and accreditation workflow Björn = | ||
2 | |||
3 | I am editing here. Nice. Here I am entering something while... I am now in alllss | ||
4 | |||
5 | == User types == | ||
6 | |||
7 | There are anonymous users and four levels of accredited users. | ||
8 | |||
9 | * **HBP members** are members that are accredited and recognized by an acting official as having a contract tied to the HBP. | ||
10 | * **HBP partners** are members that are accredited and recognized as having a contract with a partnering project. | ||
11 | * **HBP clients** are users that are accredited and ??? | ||
12 | * **HBP guests** are users that are registered and have provided an email which belongs to a list of recognized institutions. | ||
13 | |||
14 | == Accreditations Björn is editing in Accreditations only == | ||
15 | |||
16 | 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. | ||
17 | |||
18 | * Accreditations are represented as a group. //NOTE: see footnote for technical discussion. This might not be sufficient.// | ||
19 | |||
20 | == System components == | ||
21 | |||
22 | **Keycloak** is the identity and authentication manager (IAM) application. It is used for single sign on and stores user information in a profile. | ||
23 | |||
24 | **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. | ||
25 | |||
26 | == Keycloak user profile and groups == | ||
27 | |||
28 | Keycloak stores key value fields on a user profile. They can be shared with other applications by allowing scopes. These are: | ||
29 | |||
30 | * username | ||
31 | * full name | ||
32 | * login email (belonging to an institution | ||
33 | * contact email | ||
34 | * freeform about? (users could enter affiliations, other contact info, etc?) | ||
35 | |||
36 | == Extra user information for special purposes == | ||
37 | |||
38 | There is a requirement to hold statistics on members' gender for gender equality policies. There are many alternatives on how to store this. | ||
39 | |||
40 | The requirements are: | ||
41 | |||
42 | * this information is only available for the purpose it was collected for, and to those who are authorized to access it for this purpose. | ||
43 | |||
44 | At the moment, the only known field is gender, and the statistics will only need to be extracted a few time per year. | ||
45 | |||
46 | 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. | ||
47 | |||
48 | == Workflow == | ||
49 | |||
50 | [[image:workflow.png]] | ||
51 | |||
52 | === Registration === | ||
53 | |||
54 | The initial step is conducted by the new user. It happens in Keycloak. | ||
55 | |||
56 | 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. | ||
57 | |||
58 | 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. | ||
59 | |||
60 | == Revocation == | ||
61 | |||
62 | 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. | ||
63 | |||
64 | == Administrators == | ||
65 | |||
66 | Who manages the administrators? | ||
67 | |||
68 | = Notes = | ||
69 | |||
70 | == Questions on Keycloak's capabilities == | ||
71 | |||
72 | * 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. |