Synchronize Keycloak users with SORMAS [5]

[markusmann-vg]

Feature Description

In Luxembourg we will have the situation, that users are created and maintained by their own IAM/TAM System. This service will be linked to keycloak, which will be used as proxy.

Users that are created, edited, deactivated or deleted in their IAM/TAM (Identity Access Management / Technical Access Management) System are either manually or automatically (Daily CRON-JOB) synchronized with Keycloak.

The current situation and configuration synchronizes SORMAS to keycloak, meaning that users which are created, edited, deactivated or deleted in SORMAS are manually or automatically (Daily CRON-JOB) synchronized in keycloak.

With the new feature configuration operations are able to decide to either keep the synchronization SORMAS => KEYCLOAK or enable KEYCLOAK => SORMAS

When the Synchronization KEYCLOAK => SORMAS is activated, the users in SORMAS cannot be created, edited, deactivated or deleted anymore EXCEPT the roles/rights they are assigned to.

When a new user from keycloak is created in SORMAS he/she will be created with a default role, that can be changed within SORMAS manually.

If a new user wants to login immediately after being created in IAM/TAM and/or Keycloak, the SORMAS users can fetch the new user data by clicking a button in the user management overview in SORMAS.

If the direction is meant to be Keycloak => SORMAS, then the Create user will be replaced by "Fetch new user"

Consider Migration

Added Value/Benefit

The preferred Authorization process and user management from Luxembourg is applied and they can manage also SORMAS users within their IAM/TAM System. Technical users like API-users can still be created in Keycloak. SORMAS does not have to take care of the IAM/TAM when the service is properly configured to work with keycloak.

Default Role => will be assigned during creation with a parameter taken from configuration => no extra user role needed in IAM/TAM

Acceptance Criteria

Phase 1 [5]:

• [x] users, created in keycloak are either manually fetched and created in SORMAS or by the daily automatic process with a default role and the following parameters: First Name, Last Name, Email, username
• [x] users, edited in keycloak are updated in SORMAS by the daily automatic process (First Name, Last Name, Email, username)
• [x] users, deactivated in keycloak are automatically by the daily automatic process deactivated in SORMAS
• [x] active users can login to SORMAS

-- Phase 2 [3]: separate ticket (https://github.com/SORMAS-Foundation/SORMAS-Project/issues/13042)

• [x] Feature configuration to enable/disable SORMAS => KEYCLOAK // KEYCLOAK => SORMAS (It's either or)
• [x] When KEYCLOAK => SORMAS is enabled, you cannot edit users anymore (except roles and rights)

-- needs to be discussed / out of scope =>

• [ ] users, that are deleted in keycloak are automatically deactivated by the daily automatic process in SORMAS (=> Deletion cannot be done easily when they are linked to any entity, they should be deactivated instead). Clarification pending by data security team of LUX

Implementation Details

No response

Mockups

No response

Additional Information

• [ ] check if email-address can work as username

No response

[XavCol]

users, deleted in keycloak are automatically deleted in SORMAS (=> what needs to be done there? Should they be deactivated instead) If they are removed, will the cases where their names appear as those responsible (for example) retain their names? Maybe deactivated the user should be fine.

[leventegal-she]

Waiting for [Add feature configuration for Keycloak synchronization plus SORMAS adjustments [3]

13042](https://github.com/SORMAS-Foundation/SORMAS-Project/issues/13042) to use the right feature configuration

[richardbartha]

Works as expected but on username change from keyclock the sync is not defined how it should work maybe its a bug maybe its not, anyway a ticket is created related to this. @markusmann-vg can you maybe check and confirm is this an expected behavior or a bug ? https://github.com/SORMAS-Foundation/SORMAS-Project/issues/13080