Although each realm can have variations in what information we collect., or what authentication process is setup, there is a minimum set of recommendations that should be follow in each realm setup.
On this page
| Table of Contents |
|---|
Definitions
...
Realm (in Keycloak)
A Keycloak realm is an isolated management space that maintains a set of users, credentials, roles, and groups. By default, Keycloak has the master realm, whose sole purpose is to create and manage other realms in the system. Additional realms need to be created for application-based use.
User Registration Fields
The list below is to be setup be Keycloak realm. We recommend a minimum set of fields to be may mandatory. As per the needs of the projects, realms can add extra fields, following the recommendations below/
Field | Mandatory | Type | |||||
|---|---|---|---|---|---|---|---|
| 1 | First name | Mandatory | Native to keycloak | ||||
| 2 | Surname | Mandatory | Native to keycloak | ||||
| 3 | Username | Mandatory | Native to keycloak | ||||
| 4 | Email address | Mandatory | Native to keycloak. | ||||
| 5 | Phone numberMandatory | Recommended as mandatory | +CCC NNNNNNN | ||||
| 6 | WhatsAppID | MandatoryOptional | +CCC NNNNNNN | ||||
| 7 | Preferred Language | Mandatory | additional field | ||||
| 8 | User profiling | Optional | additional field | 9 | , Date of birth) | Optional | additional field |
| 109 | Type of worker | per realmOptional | additional field | 11SHOULD IDEALLY BE BASED ON AN STANDARD CLASSIFICATION | |||
| 10 | Employee ID | per realmOptional | additional field | ||||
| 1211 | Health Unit | per realmOptional | additional field | ||||
| 1312 | City/Town | Optional | additional field | ||||
| 1413 | SubNational L2 | Optional | additional field | ||||
| 1514 | SubNational L1 | Optional | additional field |
Information not collected:
Country: not necessary, as the user will be on a real that realm that represent that country
Gender
if collection gender, consider a 3rd option for ‘do not with to disclose’
Code | Value text |
|---|---|
F | Female |
M | Male |
X | Do not want to disclose |
Username
By realm - Keycloak enforces uniqueness
A combination of first name and last name can be used, but must be consistent across the realm accounts. Possible patterns include
First Name + “.” + Last Name (rodolfo.melia)
Initial First Name + “.” + Last Name (r.melia)
Initial First Name + Last Name (rmelia)
Username verification
Customization of message By Realm if username is not available - possible, part of the Realm Theme
Expected for all users. Keycloak will enforce uniqueness within the Realm.
For self-created accounts, users will receive an email that they need to open an visit the suggested URL for email validation.
For manually created account or imported accounts, email can be set to ‘verified’
Email verification
| Status | ||||
|---|---|---|---|---|
|
If a user self-register, he/she is expected to verify his/her email by following the link sent to his/her inbox.
Phone Verification
| Status | ||
|---|---|---|
|
If a user list is imported, phones can be marked as verified.
If users self-register, they are expected to verify their phone by entering the SMS sent to them at the time of account creation.
Self Registration
| Status | ||
|---|---|---|
|
Username: pre-populate based on the selected combination (see username section)
Validation: Will display an error is username is taken (or if possible as a number: rodolfo.melia1)
email account will need to be validated (see email section)
Authentication Guidelines
In general, we will setup Keycloak mirroring PSI’s authentication guidelines which can be summarised as detailed below.
...
policies, which are already covered on the guidelines below.
Password
Password complexity
| Status | ||||
|---|---|---|---|---|
|
8 characters or more
Never expires
must include
one lower case,
one upper case,
one number and
one special character
Not user name
Not email
...
Cannot reused last 5 password
Password expiration
For realms with 2FA: we don’t recommend to set an expiry date for password - there is no need to ask users to change their password if 2FA is enforced.
For realms without 2FA: every 60 days
Password recovery
always enabled (email recovery)
2FA
| Status | ||||
|---|---|---|---|---|
|
Enrolment via FreeOTP, Google or Microsoft authenticator
valid for 30 days per application/device
Example: if a user authenticates Firefox on a given laptop, and then uses Google Chrome on the same device, the user will need to authenticate again.
2FA
...
geo-triggering
| Status | ||
|---|---|---|
|
Geo-limit: if IP is > 500 miles from previous login, request 2FA
...
Token validity
| Status | ||
|---|---|---|
|
Session values
- Online - 48 hrs
- Offline - 7 days
...
Account lockout
| Status | |||
|---|---|---|---|
|
...
If a user list is imported, emails can be marked as verified.
If users self-register, they are expected to verify their email by following the link send at the time of account creation.
|
after 3 attempts
Wait increments of 1m, up to 15m
auto-reset: 12 hrs.
Account Expiration Date
| Status | ||
|---|---|---|
|
...
|
If a user list is imported, phones can be marked as verified. If users self-register, they are expected to verify their phone by entering the SMS sent to them at the time of account creation.required, an account can be schedule to expire on a given date. This is used for consultants on short term contracts.
Possible workaround:
Custom field with desired expiration date
A custom script could disable accounts passed the expiration date