Authentication, authorization and security

[]

The HCMS Client is shipped with a ready-to-go functionality for enabling user access to the application, managing and tracking users.

(Self-)Registration

(Self-)Registration is an optional feature and can be disabled. It includes:

• a registration form where users need to enter (or accept):
  • first and last name are required
  • password, twice; this is required and gets validated against the set rules
  • email, also required and validated
  • Terms of Use and Data Protection Agreement
• email confirmation with an activation link sent per email
• a possibility to use an email of an existing user; in this case, an informational email is sent
• automatic assignment of any default roles to the new user

Login page and functionality

On the login page, the following is shown:

• username and password fields
• a link to the new user registration (if enabled)
• a link to the Forgotten password form
• Terms of Use and Data Protection Agreement can be shown
  • in case of changes in any of them since the last login, the user is promoted to accept them again
• an alternative OIDC login if configured
  • can be skipped if only one OIDC is configured and becomes the only login option

In addition to that, the following functionality is included:

• password reset
• brute force prevention: short-term blocking after too many invalid credentials

The existence of an account is not shown.

Password reset form and funtionality

Once the user makes use of the reset password (forgoten password) form, the following happens in the background:

• A reset link is sent to the registered email
  • This link can only be used once
• Upon clicking on the link, the user needs to retype the new password twice

Change email

It is possible to change the login email for the user. In this case, a confirmation link will be sent to the new address, and the user needs to confirm the change with their password.

User management

On the frontend side

There is a user module in the web application UI. From there, users can manage the following, depending on their rights. In general, there are only two roles (and associated levels of access) in the application:

• read-only (r/o)
• read-write (r/w)

Users with read-only access can see their own user and edit user information.

R/w users can:

• edit user information for any user
• manually register new users
• create and edit groups, add users to these groups
• list users
• search users
• filter users by activation status
• sort users by name

Not all user data is accessible to the frontend. For some, you need to go to the backend.

On the backend side

A complete user data is stored in assets on the censhare server:

• user (person) assets
• feature assets (for features appearing on the user/person assets); this includes roles, passwords (as hashes), activation and reset tokens, etc.
• group assets: memberships in groups are represented through asset relationships

OIDC support

The OIDC support can be configured in the system configuration, in the JSON file. If you use OIDC, users are still represented as censhare assets. The user identity is paired by their email. User (person) assets that are auto-created upon user registration. This can be disabled, if you, for instance, create users in the censhare system before registering them as HCMS Client users, e.g., by some automation. Indeed, if auto-creation is disabled, the users assets must exist before the users are added in the HCMS Client, otherwise, they won't be able to log in.

You can add any number of providers. It is also possible that the same user is present in more than one provider's database. We have tested the following providers - Keycloak, AWS Cognito, and Okta - and can confirm that they work perfectly with the HCMS Client. From the provider side, the OIDC session and logout support are required to be used with the HCMS Client.

Apart from that, the OIDC support is fully standard-compliant. It implements a confidential client support through client id and secret.

From the GUI point of view, all providers are shown on the login page, and the user can select between them. You can also configure the application to skip the login page and go directly to the provider, if you only have one configured.

Authorization

Authorization session

The session uses a JWT token with a short expiration period that gets refreshed periodically. A missing refresh leads to automatic logout for the user. Such missing refresh may happen due to the interrupted connection or user inactivity.

User logout

A user logout throws away all tokens. When the user was logged in using OIDC, the web application log out will also log them out of the provider.

Authorization on the backend

On the backend side, authorization is a standard HCMS feature. Read this article for more information. It means that the same model is applied to the HCMS Client users: users become assigned with roles and user-based permissions, e.g., ownership, is handled by the HCMS, via sub claim in JWT.

The backend (middleware) bypasses these restrictions by using special role and sometimes a special schema. The backend (middleware) does it own checking in some places.

Self-registration is implemented as an HCMS webhook. It involves a PUT request from the frontend and creates a user (person) entity in the HCMS that is then replicated as a user (person) asset in the censhare system. In such scenarios, the asset names given is always constructed as the user first name and last name put together. However, group membership cannot be changed from the frontend.

User tracking

Please read the main article to leanr more.

The data is collected by a real usage, not by login/logout. Read more in this article. The raw data is processed, anonymized and summed up by a server-side automation. Each tracked day becomes an asset with a single value: the maximum number of active users. Detailed information is attached as a storage file.

The tracking can be visualized in the HCMS Client itself, with granularity on a day level.

SMTP server

You can (and often) should configure an SMTP server to allow sending emails for registration and password reset confirmations. This can be done directly in the GUI. Only basic authentication is supported.

Terms of Use and Data Protection Agreement

Upon registration or changes in both documents, the users are prompted to accept Terms of Use and Data Protection Agreement. You can edit both documents directly in the Client. It is possible to keep more than one version for both documents, but only one version can be active as a time (for each document). Changing the active version forces all users to agree again upon their next login.

Roles and permissions

The Client comes with the following default roles and associated permissions.