Configure SSO for Confluent Control Center using OIDC¶
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 and to Confluent Cloud.
You can configure SSO for Confluent Control Center 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 on Confluent Platform. For more information, see:
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 7.5.0 or later. Kafka brokers and the Confluent Control Center node must be upgraded.
SSO for Confluent Control Center is not available for on-premises Confluent Platform clusters where Confluent Control Center 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 idenity 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 on Confluent Platform in the client application
The URL should follow this format:
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:
- Microsoft Entra ID (Azure Active Directory): For more information on enabling identity tokens, see the following Azure documentation:
- Keycloak: For more information, see the Keycloak documentation:
Enable refresh tokens¶
Include group claims¶
Include group claims in the ID tokens. Following are some details and links to help you get started.
Navigate to your authorization server under Security > API. Go to Claims and configure a claim for groups.
Microsoft Entra ID (Azure Active Directory)
- To add groups claims, navigate to App registrations > Token configuration.
- Configuring group claims and app roles in tokens
- 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, 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 (
- Authorization endpoint URL (
- JSON Web Key Set (JWKS) URL (
- Issuer URL (
Microsoft Entra ID (Azure Active Directory)¶
For more information, see:
For more information, see /.well-known/openid-configuration [Okta documentation].
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 secret (
Configure identity provider client credentials and endpoints¶
On each Kafka broker and Control Center 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>
Step 2 - Enable SSO using OIDC on Confluent Control Center and Kafka MDS¶
To enable SSO for Confluent Control Center using OIDC, you must configure the following parameters:
On each Kafka broker, add the following parameter to the Confluent Platform broker configuration file:
On the Control Center node, add the following parameter to the Confluent Control Center properties file (typically,
Add group and sub claims¶
To specify your
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
groupsclaim name identifies the groups to which the principal belongs. The default value is
groups. Other ccommon values are
sub(subject) claim name identifies the principal that is the subject of the JWT. The default value is
sub. Other common values are
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
confluent.oidc.idp.refresh.token.enabled=true. For RBAC to work as expected,
the default value of
true should not be changed to
The default value is
true and should not be changed to
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.
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).
Step 4 - Restart the Kafka brokers¶
After you have configured SSO for Confluent Control Center using OIDC, you need to restart the Kafka brokers and Control Center for the changes to take effect.
Ater restarting, you can sign in to Control Center 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.