Migrate LDAP RBAC to OAuth RBAC in Confluent Platform

You can migrate from LDAP RBAC in your current Confluent Platform cluster to use OAuth RBAC by transitioning from your existing LDAP server to use an OAuth server.

For example, before migrating to OAuth with RBAC, all authentications might be running through an LDAP server. HTTP Basic Authentication is used to authenticate clients while SASL/PLAIN with LDAP is used for internal services, like Schema Registry and Connect. After successful authentication, the LDAP server provides the roles and permissions associated with users. In summary and as shown in the diagram below, the flow is as follows:

1. The client sends an HTTP request with the Authorization: Basic <base64-encoded-credentials> header, with the Base64 encoded credentials being the username and password.
2. The LDAP server decodes the credentials and authenticates them against the LDAP directory.
3. Upon successful authentication, the LDAP server retrieves the roles and permissions associated with the user from the LDAP directory and enforces RBAC on the user’s requests.

During the transition phase, both LDAP and OAuth are used for authentication. Clients can use either HTTP Basic Authentication or OAuthBearer tokens, while internal services, like Schema Registry and Connect, authenticate using SASL/OAUTHBEARER. This temporary transition is to ensure that there is no disruption to your Confluent Platform cluster during your migration. While you are transitioning, you can still use LDAP for authentication, but you will need to update your client configurations to use OAuthBearer tokens. During the transition, note the following:

• The legacy Client App1 can use HTTP Basic Authentication and LDAP during the transition.
• The new Client App2 uses OAuth tokens, which are validated and enforced by MDS.
• Internal services like Schema Registry and Connect uses SASL/OAUTHBEARER for authentication, with the OAuth tokens validated and enforced by MDS.
• Confluent Server supports tokens from both the LDAP (legacy support) and OAuth (new support), with MDS enforcing RBAC policies based on OAuth tokens.

After you have completed the transition, only OAuth tokens are used for authentication.

Steps to migrate LDAP RBAC to OAuth RBAC in Confluent Platform

To ensure a smooth transition, review and complete the following process.

1. Understand the current LDAP RBAC configuration.

   Review your existing LDAP RBAC configuration to understand how roles and permissions are configured.

2. Configure the Metadata Service (MDS) to support OAuth.

   To modify the Metadata Service (MDS) to enable OAuth support, you need to update the confluent.metadata.server.user.store property to OAUTH or LDAP_WITH_OAUTH for a hybrid approach during migration. You also need to configure the necessary OAuth endpoints and ensure that the MDS can validate OAuth tokens.

   Example configuration of MDS for OAuth support

   Similar to your Confluent Server broker configurations, the following settings are required to enable identity provider (IdP)-issued OAuth token validation in MDS. For details on these configurations, see configurations for supporting identity provider tokens in MDS.

   confluent.metadata.server.user.store=OAUTH
   confluent.metadata.server.oauthbearer.jwks.endpoint.url=<idp-jwks-endpoint>
   confluent.metadata.server.oauthbearer.expected.issuer=<idp-issuer>
   confluent.metadata.server.oauthbearer.expected.audience=Confluent,api://default,https://my-company.com
   confluent.metadata.server.oauthbearer.sub.claim.name=sub
   confluent.metadata.server.oauthbearer.groups.claim.name=groups
   

3. Configure your OIDC identity provider to issue OAuth tokens.

   • Set up an OIDC-compliant identity provider (IdP), such as Okta, Keycloak, or another provider. For details, see Configure SSO for Confluent Control Center using OIDC on Confluent Platform
   • Ensure that your IdP is configured to issue tokens that MDS can validate.

4. Update your Kafka client configurations.

   Update the configurations of clients (for example, Confluent Server brokers, Schema Registry, and Connect) to use OAuth for authentication. This involves setting the appropriate OAuth properties in the client configuration files. For details, see Configure Clients for SASL/OAUTHBEARER authentication in Confluent Platform.

   Example configuration of Kafka client for OAuth support

   To use OAuth authentication with Confluent Platform, you must configure Kafka clients with the following properties:

   sasl.mechanism=OAUTHBEARER
   security.protocol=SASL_PLAINTEXT
   sasl.login.callback.handler.class=org.apache.kafka.common.security.oauthbearer.secured.OAuthBearerLoginCallbackHandler
   sasl.login.connect.timeout.ms=15000 # optional
   sasl.oauthbearer.token.endpoint.url=<idp-token-endpoint>
   sasl.jaas.config=org.apache.kafka.common.security.oauthbearer.OAuthBearerLoginModule required \
     clientId="<client-id>" \
     clientSecret="<client-secret>" \
     scope="<scope>"; # optional
   

5. Test the configuration.

   Thoroughly test the new OAuth configuration in a staging environment to ensure that authentication and authorization work as expected.

6. Migrate your users and roles.

   Migrate your existing user roles and permissions from LDAP to the new OAuth-based system. This might involve creating new role bindings in MDS for OAuth users. For details, see Configure RBAC using the REST API in Confluent Platform.

7. Monitor and validate.

   • Monitor your Confluent Platform cluster after migration to ensure that there are no issues with authentication or authorization.
   • Validate that all users have the correct permissions.