RFC: 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) ... can be equal to username or a custom external when the username is just calculated from firstname/lastname)
• username (readonly on keycloak, so this can remain in the datastore)
  • is changed in import when users are merged using member number
• password (handled by keycloak)
• email (synchronized both ways?)
• last_login (number) (handled by OpenSlides)
• 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
• UI user creation/update/deletion
  • authentication related user properties should be synchronized with keycloak. That could be done before the datastore model is updated.
  • attributes: email (if required)
  • default password is obsolete (replaced by one-time tokens, QR-code/ magic link)
• 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.
  • to be clearified: how / when does the provisioning happen
  • webhook keycloak -> backend (on every login)
• 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.
  • Newly created users will be provisioned on the next login. Or the sync could be implemented in user admin UI.
• last login field
  • login webhook

Migration

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

• define process how an instance is migrated
• existing password hashes should be re-usable be keycloak

[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...