Splitting user data between database and keycloak

[boehlke]

Abstract

In the current implementation, the user lives as a model in the datastore. The auth service and the backend both access to the same user model.

In the new setup with keycloak, clarity is required about where the user should live. Especially it needs to be specified, how users should be synchronized.

The best case would be circumventing synchronization

User data

Most of the user's data is contained in the user related datastore models. Keycloak is responsible for authentication related data. Coming from the auth service user model (https://github.com/OpenSlides/openslides-auth-service/blob/main/auth/src/core/models/user.ts), there are the following auth related properties:

• saml_id (this should be renamed to kc_id (for keycloak ID) ... this is the UUID that keycloak creates)
• username (readonly on keycloak, so this can remain in the datastore)
  • is changed in import when users are merged using member number
  • in OpenSlides, the username is descriptive, not an identifying feature
• password (handled by keycloak)
• email (handled by OpenSlides, keycloak does not need to know the email since mailing is done by an OpenSlides webhook, see #6824 )
• last_login (number) (handled by OpenSlides, updated by a webhook)
• is_active (boolean) (handled by OpenSlides)

There are discussions to import meeting participation data from the IdP.

Use-Cases/Features

• OpenSlides UI user listing
  • Users should be created in OS whenever created in keycloak and vice verca
  • no data from keycloak is needed to show users in admin UI view
• UI user creation/update/deletion
  • authentication related user properties should be synchronized with keycloak. That could be done before the datastore model is updated.
  • default password is obsolete (replaced by one-time tokens, QR-code/ magic link)
  • no attributes need to be synced
  • when the username is changed in OpenSlides, that needs to be reflected in Keycloak
• User import
  • The import seems to use the same actions as the UI... see above.
• On-Login user provisioning and update
  • If the user is not in the datastore, it should be created.
  • If the user is in the datastore, the auth related properties should be updated.
  • webhook keycloak -> backend on every login handles profile update and provisioning
• Default Password/Reset to default
  • feature removed
  • create issue for replacement
• Keycloak originated user creation/deletion/update
  • Updates don't need to be synchronized, as the user data is fetched from keycloak anyway.
  • Deletions result in stale user data in the datastore. This could be solved by a cleanup job that removes users that are not in keycloak.
• last login field
  • login webhook

Migration

User auth data needs to be migrated from the datastore user model to keycloak.

• use db migration script
• existing password hashes should be re-usable be keycloak
• script requires authentication

[boehlke]

Another issue came up that is also relevant: The superadmin account (user ID 1) needs a proper replacement. A keycloak openslides user has to be marked a superadmin somehow. Superadmin powers are given via the user's organization_management_level attribute An approach to be discussed is reflecting the management level as keycloak user role...