Skip to main content

Release date: 2024-01-15

User management unification

We refactored all authentication process to unify some concern accross all authentication mechanism in Gateway.

Previously, the gateway user was defined differently depending of your authentication choice (mTls, SASL plain, SASK Oauthbearer, Delegated). This made user management and interceptor targeting complex.

Today we've uncoupled the authentication process from the user identification to leverage the UserMapping added in Gateway 2.2.0, for all authentication processes.

All sucessfull authentication process will result in a Principal based on exhanged credentials (See information below to know how principal is detected based on your choice). This principal will be used to search in UserMapping the associated gateway user and it's information.

You can now easily create and manage Gateway users, associate them to your authentication provider and define gateway information in the same fashion.

New authentication flow : new_authentication_flow

API change

The following UserMapping http API's now provide an optional body field principal to be able to define the principal for a mapping.

  • /userMappings/v1
  • /userMappings/v1/vcluster/{vcluster}

FAQ

- Do I need to recreate all my users?

No, you don't. This new unified flow is compatible with existing credentials and if a mapping doesn't exist it will detect the Gateway User based on authentication information. User mapping will always have priority over authentication specific information like claims for SASL with Oauthbearer. That means that you can start managing your users with UserMapping while keeping your existing credentials.

- What is the principal extracted for my authentication ?

Here is the list by authentication mechanism that will be used as source for the principal:

AuthenticationPrincipal
mTlsCertificate subject (ex: CN=myuser)
Sasl (Plain)username
Sasl (Oauthbearer)Token subject (sub claim by default)
Sasl (Delegated)username

- Is a principal and username the same thing?

No, depending on your authentication provider, the principal (the authorization id exchanged and validated) could be complex to manage. To solve this issue, a UserMapping defines a username and a principal.

  • principal is the field used to search for a user based on an authentication
  • username is the field to identify and target a user for Gateway processes (ACL, Interceptor targeting, ...)

By default if a principal is not defined when creating a UserMapping we define that the principal is the same as username.

Concentrated topics

Logical partitions are no longer automatically remapped to another partition when their backing partitions are deleted.

Virtual clusters

Virtual clusters are currently under rework and this release introduces some deprecations:

  • We removed flags for Virtual topics no longer used
  • We remove the ability to mark a real topic as physically deleted (a legacy product feature)
  • We removed some string interpolation in the real topic concentration that were unused
  • We deprecated some fields in the response of the internal APIs (these APIs will probably go away in the next release)

General fixes 🔨

  • Concentration: Fix transaction support (but the support is still a bit experimental)
  • Concentration: Fix retention not emulated on policy=compacted,deleted
  • Concentration: Fix retention emulation issue that could cause some message to reappear after decreasing retention
  • Disabled auto topic creation in more scenarios