Single sign-on (SSO) for Confluent Cloud¶
Confluent Cloud allows for single sign-on (SSO) using your existing SAML-based identity provider (IdP). SSO provides access control for multiple independent software systems. With SSO, enterprise users can log in to multiple, unrelated systems using a single user ID and password, which means enterprises no longer have to store and manage passwords in company databases. SSO also improves security and decreases service and troubleshooting issues associated with individual logins.
In Confluent Cloud, SSO is enabled at the organization level. By default, newly users must authenticate using SSO.
When SSO is disabled, the authentication method for users does not automatically change. Before you disable SSO, make sure that you have a local user account with the OrganizationAdmin role to be able to sign in to your organization.
- You must have an existing SAML-based identity provider, such as Okta, OneLogin, or Azure Active Directory (AD).
- Only users assigned the OrganizationAdmin role can view and modify SSO settings.
Identity provider-initiated sign-in flows for SSO are not supported. In an identity provider-initiated flow, Confluent Cloud cannot verify that an end user initiated the flow, which leaves users vulnerable to Cross-Site Request Forgery (CSRF) attacks. Several identity providers suggest workarounds to simulate identity provider-initiated login flows, such as the Okta bookmark application.
Confluent Cloud SSO does not support single log-out (SLO) protocols.
The following terms play a key role in the implementation of SSO for Confluent Cloud:
- Identity provider (IdP)
- The service that stores and manages digital identities. SSO users are redirected to the identity provider for authentication.
- Local user
- Also known as a “non-SSO user”, this user possesses a password that is stored in the Confluent Cloud database and authenticates directly with Confluent Cloud. For details, see Local user accounts.
- Service provider-initiated login
- For a service provider-initiated login, users access the Confluent Cloud login page, and are then redirected to their identity provider to log in.
- SSO user
- The Confluent Cloud user who authenticates using their own identity provider.
Confluent Cloud SSO workflow¶
With SSO enabled, users sign in at
The browser makes an OpenID Connect (OIDC) request to the identity broker at
login.confluent.io, which then redirects the browser to send a SAML request
to the organization’s identity provider. After the user successfully authenticates,
the identity provider responds with a signed SAML ID Assertion, which the identity
broker translates into a JSON Web Token (JWT). Confluent Cloud uses this token to authenticate
additional requests from the browser.
When SSO is enabled and the
confluent login command is issued, the following
browser-based workflow is launched:
- Generates an HTTP server on
localhostto receive the authentication callback.
- Initiates the SSO flow by navigating to
login.confluent.ioin the browser.
- The browser automatically redirects the user to the identity provider sign-in page.
- After successfully signing in, the browser redirects the user back to
localhostwith a signed
- Confluent CLI uses the
id_tokento obtain a Confluent Cloud back-end session.
If the Confluent CLI is running on a server without a web browser (also known as a “jump”
host”), then this flow does not work. In such cases, you must log in using the
option. For details, refer to Sign in to Confluent Cloud using SSO.
Sign in to Confluent Cloud using SSO¶
You can sign in to Confluent Cloud using the Confluent CLI or the Confluent Cloud Console.
For SSO-enabled organizations, you can sign in to your Confluent Cloud organization using the following Confluent CLI command with your SSO user account:
- For the “SSO” authentication method, the
confluent logincommand does not prompt the user for a password. SSO relies on your identity provider for authentication.
- The deprecated “Local and SSO” authentication method defaults to the SSO authentication method and does not allow the user to select the authentication method. For important information about the “Local and SSO” user account type, see the note at User Accounts.
If the Confluent CLI is running on a server without a web browser (also known as
a “jump host”), then you cannot sign in using
confluent login. In such cases,
you must use the
confluent login --no-browser
After running this command, you receive a printout of a URL, which you must copy and paste into a local browser. After you provide your credentials and successfully log in, the browser displays a code that you must copy and paste back into in the Confluent CLI. Your workflow should look like the following:
confluent login --no-browser Updates are available for ccloud. To install them, please run: $ confluent update Enter your Confluent credentials: Email: firstname.lastname@example.org Navigate to the following link in your browser to authenticate: https://login.confluent.io/authorize?response_type=code&code_challenge=NovO_c6FO44G-6cfRbqTrBcEOrDnvm7GNZLCHCmbPM8&code_challenge_method=S252&client_id=hPbGLM8G55HSaUsaaieiiAprnJaEc3rH&redirect_uri=https://confluent.cloud/cli_callback&scope=email%20openid&audience=https://confluent.auth0.com/api/v2/&state=CoOGX1aQhvwdH2dFSvKV-gh09INnYcXFaYbUnWq3Ekw&connection=big-company After authenticating in your browser, paste the code here: #### The following code was copied and pasted from the browser ##### CoOGX1aQhvwdH2dFSvKV-gh09INnXcXFaYbUnWq3Ekw/bf1jJFSANhlQBqPn Logged in as email@example.com Using environment t21388 ("default")
After new users are invited to use SSO, they receive an email notification that includes a link to the new SSO sign-in page. The wording and format of the notification will vary by organization, but it will always include a link that the recipient must click to accept the invitation and complete account setup.
The link in the notification is for one-time use. Do not share the link with other users in your organization. This link only works for the recipient of the email notification.
Fill in the acceptance form and click Submit. The new SSO login screen appears.
The organization-specific SSO login URL should look like
is replaced by the identifier for your organization. This is your new permanent
Confluent Cloud SSO login page. If using bookmarks, save this URL.
To disable SSO:
In Confluent Cloud Console, open the sidebar menu and click ADMINISTRATION -> Single sign-on.
The Single sign-on page displays.
Scroll to the bottom of the Single sign-on page and click Disable.
When SSO is disabled, your organization’s team members will no longer be able to sign in using your identity provider, and must use Forgot Password to create a Confluent Cloud password.
To re-enable SSO, you must repeat the steps in Enable Single sign-on (SSO) for Confluent Cloud.
If you attempt to sign in for the first time after enabling SSO while you are still signed in to your identity provider, you might be signed in immediately and bypass the identity provider sign-in window. If this occurs, sign out of your identity provider session, then sign in using an incognito browser window.