Configure SSO for Confluent Control Center (Legacy) using OIDC

Important

To use SSO with Confluent Control Center (Legacy) your installation must use Confluent Platform version 7.5 or later. SSO for Confluent Control Center (Legacy) using OIDC cannot be used with both on-premises Confluent Platform clusters where your Confluent Control Center (Legacy) is self-managed, and Confluent Cloud clusters, which use SAML for SSO.

You can configure single sign-on (SSO) using OpenID Connect (OIDC), built on top of the OAuth 2.0 protocol, to enable users to use a single security credential, from your identity provider (IdP), to seamlessly authenticate to Confluent Control Center (Legacy) and to Confluent Cloud.

You can configure SSO for Confluent Control Center (Legacy) using OIDC in the following ways:

Manual configuration: Follow the steps below.
Automated configuration: Confluent recommends using Confluent Ansible and Confluent for Kubernetes (CFK) to automate the configuration of SSO for Confluent Control Center (Legacy) on Confluent Platform. For more information, see:
- Confluent Ansible: Configure single sign-on authentication for Control Center
- CFK: Configure single sign-on authentication for Confluent Control Center

Prerequisites

Identity provider (IdP)

Must be OIDC-compliant. SAML is not supported. Note that OIDC is more robust and easier to set up.
An OIDC-compliant identity provider, with optional multi-factor authentication (MFA). Details about following identity providers are included: Okta, Microsoft Entra ID (Azure Active Directory), and Keycloak.

Confluent Platform

Confluent Platform 7.5.0 or later. Kafka brokers and the Confluent Control Center (Legacy) node must be upgraded.

Note

SSO for Confluent Control Center (Legacy) is not available for on-premises Confluent Platform clusters where Confluent Control Center (Legacy) is self-managed and Kafka clusters are fully managed on Confluent Cloud.
Role-based access control (RBAC) must be enabled.

Configure SSO using OIDC

Step 1 - Establish a trust relationship between CP and identity provider

Identity provider checklist

Use the following steps to ensure that your identity provider is configured correctly:

Create a client application

Create an OpenID Connect (OIDC) application configured with authorization code grant type in your identity provider (IdP).

Following are some links to help you get started:

Microsoft Entra ID (Azure Active Directory): Quickstart: Register an application with the Microsoft identity platform.
Okta: Create OIDC app integrations.
Keycloak: Managing OpenID Connect clients.

Add a redirect URL

Add a redirect (callback) URL to Confluent Control Center (Legacy) on Confluent Platform in the client application

The URL should follow this format:

https://<c3-hostname>:<c3-port>/api/metadata/security/1.0/oidc/authorization-code/callback

Enable identity tokens

Identity tokens are enabled by default when you create an OIDC application in your identity provider. Following is information specific to some common identity providers:

Okta: Creating the authorization server by default enables identity (ID) tokens. For more information, see:
- ID tokens.
Microsoft Entra ID (Azure Active Directory): For more information on enabling identity tokens, see the following Azure documentation:
- ID tokens in the Microsoft identity platorm
Keycloak: For more information, see the Keycloak documentation:
- Server Administration Guide.

Enable refresh tokens

Okta: Check the Refresh Token option in the Grant type section of the Applications page.
Microsoft Entra ID (Azure Active Directory)
- Refresh tokens
Keycloak: Refresh tokens are enabled by default. For more information, see: Authorization Code Flow.

Include group claims

Include group claims in the ID tokens. Following are some details and links to help you get started.

Okta

Navigate to your authorization server under Security > API. Go to Claims and configure a claim for groups.
- Add a Groups claim for the org authorization server.
Microsoft Entra ID (Azure Active Directory)
- To add groups claims, navigate to App registrations > Token configuration.
- Configuring group claims and app roles in tokens
Keycloak
- Configure a new Group Membership mapper. Make sure to have Full group path enabled.

Assign users to the client application

Assign users to the client application in your identity provider. If you are using groups to control access to Confluent Control Center (Legacy), assign users to the groups.

Get the identity provider endpoints

You can use the OpenID provider configuration response to get the identity provider endpoints required to fetch, authorize, and verify tokens. Use the OIDC metadata discovery URI listed below for your identity provider to get the following identity provider endpoints and save them for later use:

Token endpoint URL (token_endpoint)
Authorization endpoint URL (authorization_endpoint)
JSON Web Key Set (JWKS) URL (jwks_uri)
Issuer URL (issuer)

Microsoft Entra ID (Azure Active Directory)

https://login.microsoftonline.com/<tenant-id>/v2.0/.well-known/openid-configuration

For more information, see:

Okta

https://<okta-domain>/oauth2/default/.well-known/openid-configuration

For more information, see /.well-known/openid-configuration [Okta documentation].

Keycloak

https://<keycloak-domain>/auth/realms/<realm-name>/.well-known/openid-configuration

For more information, see Using OpenID Connect to secure applications and services.

Get the client credential details

From the client application created in the identity provider, get the following client credentials and save them for later use:

Client ID (client_id)
Client secret (client_secret)

Configure identity provider client credentials and endpoints

On each Kafka broker and Control Center (Legacy) node, add or update the following parameters to the Confluent Platform broker configuration file using the identity provider endpoints and client credentials obtained in the previous steps.

confluent.oidc.idp.issuer=https://<identity-provider-domain>/oauth2/<client-id>
confluent.oidc.idp.jwks.endpoint.uri=https://<identity-provider-domain>/oauth2/<client-id>/v1/keys
confluent.oidc.idp.authorize.base.endpoint.uri=https://<identity-provider-domain>/oauth2/<client-id>/v1/authorize
confluent.oidc.idp.token.base.endpoint.uri=https://<identity-provider-domain>/oauth2/<client-id>/v1/token
confluent.oidc.idp.client.id=<client-id>
confluent.oidc.idp.client.secret=<client-secret>

Configure group authorization

You can use group authorization to control access of users to any resource, for example, a Kafka cluster or topics. In the identity provider, make sure that you have created the groups and assigned users to them.

In a Confluent Platform cluster, the DefaultPrincipalBuilder creates a KafkaPrincipal that does not include groups. This becomes evident during interactions between the Confluent Control Center (Legacy) and Kafka brokers. For example, when using the KafkaAdminClient to retrieve topics, the DefaultPrincipalBuilder produces the KafkaPrincipal.

In contrast, the OAuthKafkaPrincipalBuilder employs an OAuthBearer token to generate a KafkaPrincipal. This builder also incorporates groups, allowing them to be passed to the authorizer where necessary.

To configure group authorization in a Confluent Platform cluster, you must add the following parameters to the Confluent Platform broker configuration file on each Kafka broker.

The confluent.oidc.idp.groups.claim.scope is required and must match the value of the groups claim configured in your identity provider.
- The default value is groups, but might need changing it depending on your identity provider setup.
- If the values do not match, errors occur during authentication.
By using the OAuthKafkaPrincipalBuilder, the KafkaPrincipal can include groups.

confluent.oidc.idp.groups.claim.scope=groups
listener.name.${listenerName}.principal.builder.class=io.confluent.kafka.security.authenticator.OAuthKafkaPrincipalBuilder

Step 2 - Enable SSO using OIDC on Confluent Control Center (Legacy) and Kafka MDS

To enable SSO for Confluent Control Center (Legacy) using OIDC, you must configure the following parameters:

On each Kafka broker, add the following parameter to the Confluent Platform broker configuration file:
```
confluent.metadata.server.sso.mode=oidc
```
On the Control Center (Legacy) node, add the following parameter to the Confluent Control Center (Legacy) properties file (typically, control-center-dev.properties or control-center-production.properties):
```
confluent.controlcenter.auth.sso.mode=oidc
```

Add group and sub claims

To specify your groups and sub claims, add the following parameters:

On each Kafka broker, add the following parameters to the Confluent Platform configuration file.
```
# Field for groups and sub in JWT
confluent.oidc.idp.groups.claim.name=groups
confluent.oidc.idp.sub.claim.name=sub
```
- The groups claim name identifies the groups to which the principal belongs. The default value is groups. Other common values are organization and team.
- The sub (subject) claim name identifies the principal that is the subject of the JWT. The default value is sub. Other common values are email and employee_id.

Step 3 - Customize additional security and usability

Depending on your requirements, you can optionally configure the session management experience on Confluent Platform to customize additional security and usability. Customizations to the following two parameters are optional. For the majority of use cases, the default values should work.

Verify that refresh tokens are enabled

Session renewal also refreshes user’s claims by default as refresh tokens are enabled. For RBAC to work as expected, you should allow refresh tokens for OIDC.

Session renewal is enabled by default because refresh tokens are enabled by default using confluent.oidc.idp.refresh.token.enabled=true. For RBAC to work as expected, the default value of true should not be changed to false.

confluent.oidc.idp.refresh.token.enabled=true

The default value is true and should not be changed to false.

Set the expiration period for JWT session tokens

To change the JWT session token expiration period, add the following configuration parameter and set the duration, in milliseconds. The value here impacts the time to enforce reauthentication. The default value is 900000 (15 minutes). This value should be less than the value for the maximum session timeout.

confluent.oidc.session.token.expiry.ms=900000

Set the maximum session timeout period

To change the maximum session timeout, after which the session cannot be extended, add the following configuration parameter and set the duration, in milliseconds. The default value is 21600000 (6 hours).

confluent.oidc.session.max.timeout.ms=21600000

Step 4 - Restart the Kafka brokers

After you have configured SSO for Confluent Control Center (Legacy) using OIDC, you need to restart the Kafka brokers and Control Center (Legacy) for the changes to take effect.

After restarting, you can sign in to Control Center (Legacy) using the SSO credentials from your identity provider.

Note: You might experience downtime on the Confluent Platform cluster while the cluster upgrades to enable SSO for Confluent Control Center (Legacy).