Single Sign On

What's SSO?

Single Sign-On is a mechanism that enables a user to log in using the same set of credentials within multiple third-party services, Conduktor being one of them.
There are two principal kinds of SSO:
  • Social login lets users connect to applications with Google, Facebook, or other social network accounts.
  • Enterprise login lets users connect to external applications using their company's credentials.
This mechanism encompasses multiples techniques, protocols, and technical jargon:
  • OIDC, OAuth, SAML, Kerberos, LDAP

Supported protocols

We support Enterprise connection Single Sign-On using any of the following protocols:
  • SAML
  • OpenID Connect (OIDC)
  • Google Workspace
  • Microsoft Azure AD


By configuring SSO with Conduktor, you can:
  • Maintain within your IdP who is allowed to Conduktor
  • Control the Authentication policies (2FA, network rules)
  • Automatically disable accounts when people leave the company
  • Forward your company groups to Conduktor (incoming feature)
    • leverage Conduktor RBAC
    • share Cluster Configuration between team members
Once we have configured the link between Conduktor and your Identity Provider, users from your company will be redirected to your identity provider automatically.

What will change when I migrate to SSO?

Nothing from Conduktor's point of view as long as you use the same email address before and after the migration.
Before the migration, Conduktor was using Auth0 User Store or Social Identity Provider to authenticate you.
After the migration, the next time you connect to Conduktor, you will automatically get redirected to your company's IdP.
Your users will get redirected to your IdP based on their email address

SAML configuration step by step

We first need to agree on a Connection Name that we'll share. It's most likely going to be your company name converted in kebab-case (a-z, 0-9, or -). In the following examples, we'll use your-company.
You first need to declare a new SAML 2.0 Application in your IdP.
There are two important fields you need to declare your Application:
Post-back URL or ACS URL
Entity ID
Due to some limitation on Auth0, we need that your SAML assertion contains a custom claimemail_verified with the value true.
Okta documentation: Configure SAML attributes
Once you're done, you need to collect and provide us with the following information:
Signing Certificate
A .cer, .crt or .pem file
Domain names to redirect authentication,

OIDC configuration step by step

You first need to declare a new OIDC Application in your IdP.
If you are asked about the Application Type, pick Server-side or Web Application type.
Leave most default as-is except for the "Sign-in redirect URL":
Once you're done, you will provide us with your information:
Client ID
Client Secret
Domain names to redirect authentication,