Configure LDAP as SSO
View the list of LDAP properties. Here’s a sample snippet containing server, users and groups to put in your configuration file.platform-config.yaml
If your LDAP server is Active Directory and you get an “invalid user” error when trying to log in, try setting your
search-filter
to '(sAMAccountName={0})'
.User mapping
Here is the mapping between LDAP user’s information and Conduktor Console:LDAP | Conduktor Console |
---|---|
uid | User ID, used to log in |
mail , email or userPrincipalName | User email (The only mandatory field) |
cn | User name |
sn | User family name |
givenName | User first name |
displayName | User display name |
Groups
To retrieve the groups each user belongs to, you have to setgroups-enabled
to true
, and populate the attributes groups-base
and groups-filter
.
Note that depending on your LDAP objectClass
, the attribute used to filter groups might be changed. For example:
LDAP objectClass | Conduktor groups-filter |
---|---|
groupOfNames | "member={0}" |
groupOfUniqueNames | "uniqueMember={0}" |
Map to external groups
Now that your configuration is finished, you can set up a mapping between your LDAP groups and your Console groups. That way, when a user logs in, they will be automatically added to the corresponding Console groups, based on their LDAP groups. To create this mapping, you have to create a group from Console, and mention the ID of the group on your LDAP (you should find it in the attribute you mentioned asgroups-base
).


Configure LDAPS certificate
For LDAPs (LDAP over SSL) connection, you have to provide a trusted certificate using Java JKS TrustStore file. LDAPS SSL certificate can also be passed as PEM encoded string using the propertysso.trustedCertificates
.
platform-config.yaml
Configure Auth0 as SSO
View the list of Auth0 properties. On Auth0 side, you’ll have to create a new application:-
Create a regular web application:
-
Get the
client ID
,client secret
anddomain
: -
Configure the callback URI.nThe redirect URI can be something like:
http(s)://<Console host>(:<Console port>)/oauth/callback/<OAuth2 config name>
. For example, if you deployed Console locally using the nameauth0
in your configuration file, you can usehttp://localhost:8080/oauth/callback/auth0
.

Remember to specify how you want to connect using the Connections tab of your Auth0 application.
Configure Console
On the Console side, you can add the snippet below to your configuration file. Replace theclient ID
, client secret
and domain
with values from step 2 above.
platform-config.yaml
Configure Amazon Cognito as SSO
On Amazon Cognito side, you’ll have to create a user pool with an application:-
Create a new user pool
-
Configure the application client. You can select the name you want, shown here as
Conduktor Console
and enter the redirect URI as the following:http(s)://<Console host>(:<Console port>)/oauth/callback/<OAuth2 config name>
. For example, if you deployed Console locally using the namecognito
in your configuration file, you can usehttp://localhost:8080/oauth/callback/cognito
.
Confidential client
.

- Set the scopes
profile
,email
andopenid
in the Advanced app settings:

- Get the
user pool ID
,client ID
, andclient secret
, that you’ll use in the configuration file of Console


You can find the .well-known at:
https://cognito-idp.<region>.amazonaws.com/<user pool ID>/.well-known/openid-configuration
.Configure Console
On Console side, you can add the snippet below to your configuration file. You have to replace theclient ID
, client secret
, region
, and pool ID
, with what you got during step 4.
platform-config.yaml
Configure groups
If you want to use theexternal groups mapping
to map groups between your Conduktor Console instance and Amazon Cognito, you must set the property groups-claim
to "cognito:groups"
in Console configuration file. Below is the full snippet for your configuration file:
platform-config.yaml
Map to external groups
Now that your configuration is finished, you can set up the mapping between Amazon Cognito and Console groups. That way, when a user logs in, they will be automatically added to the corresponding Console groups, based on the groups they belong to in Amazon Cognito. The value you need to put as an external group is theObject ID
of the Amazon Cognito group.
Configure Entra ID as SSO
On the Entra ID (formerly Azure Active Directory) side, you’ll have to create a new application:- Step 1: Create a new application in
App registrations
and set the callback URI
Conduktor Console
, and enter the redirect URI as the following: http(s)://<Console host>(:<Console port>)/oauth/callback/<OAuth2 config name>
.
For example, if you deployed Console locally using the name azure
in your configuration file, you can use http://localhost:8080/oauth/callback/azure
, like on the screenshot below.

- Step 2: Create a new client secret from the Certificates and secrets tab

You need to keep the
Value
somewhere safe, as you will not have access to it again.- Step 3: Find the
client ID
andtenant ID
in the Overview tab

You can find the .well-known at:
https://login.microsoftonline.com/<tenant ID>/v2.0/.well-known/openid-configuration
.Configure Console
On Console side, you can add the snippet below to your configuration file. You have to replace the client ID, client secret, and tenant ID, with what you got during steps 2 and 3.platform-config.yaml
Configure groups
If you want to use theexternal groups mapping
to map groups between your Conduktor Console instance and Azure, you must add this claim to your Azure application in the Token configuration tab:

The external groups mapping will not work for users who belong to more than 200 groups. In this case, you will need to assign some groups to the application and check the Groups assigned to the application box when creating the groups claim on Azure AD. This is to avoid exceeding the limit on the number of groups a token can contain.
groups-claim
to "groups"
in the Console configuration file. Below is the full snippet for your configuration file:
platform-config.yaml
Map to external groups
Now that your configuration is finished, you can set up the mapping between Azure AD and Console groups. That way, when a user will log in, they will be automatically added to the corresponding Console groups, based on the groups they belong to in Azure AD. The value you need to put as an external group is theObject ID
of the Azure AD group.
Configure Google as SSO
On Google side:- Step 1: Create an application on the OAuth consent screen tab
email
, profile
, and openid
. Optionally, you need read only
for external group mapping.

- Step 2: Restrict access to your internal workspace by checking the
Internal
user type in the OAuth consent screen.

- Step 3: Create a new
OAuth client ID
Conduktor Console
, and enter the redirect URI like this: http(s)://<Console host>(:<Console port>)/oauth/callback/<OAuth2 config name>
.
For example, if you deployed Console locally using the name google
in your configuration file, you can use http://localhost:8080/oauth/callback/google
, like on the screenshot below.

- Step 4: Get the
client ID
and thesecret ID
You can find the .well-known at:
https://accounts.google.com/.well-known/openid-configuration
.If you need to add an authorized domain to your Google account, you can follow this guide.Configure Console
On Console side, you can add the snippet below to your configuration file. You have to replace the client ID and secret with what you got during the step 4.platform-config.yaml
Configure groups
An additional scopehttps://www.googleapis.com/auth/cloud-identity.groups.readonly
is required if you want to sync Google Group with Conduktor Groups.
platform-config.yaml
Map to external groups
Now that your configuration is finished, you can set up the mapping between Google groups and Console groups. That way, when a user logs in, they will be automatically added to the corresponding Console groups, based on the groups they belong to in Google. The value you need to put as an external group is theemail
address of the Google Group.
Configure JumpCloud as SSO
On the JumpCloud side, you’ll have to create a new application:-
Step 1: Create a new application in
SSO Applications
. -
Step 2: Select a
Custom Application
as shown below.
Manage Single Sign-On (SSO)
, then Configure SSO with OIDC
and Export users to this app (Identity Management)
as seen in the screenshot below.

conduktor
as seen in the screenshot below and configure this application.

- Step 3: Configure OAuth settings including
Redirect URI(s)
,Login URL
and the client authentication type.
http(s)://<Console host>:<Console port>/oauth/callback/<OAuth2 config name>
.
For example, if you deployed Console locally using the name jumpcloud
in your configuration file, you can use
https://localhost:8080/oauth/callback/jumpcloud
, as seen in the screenshot below.
Enter the Login URL, which is the URL users need to log into this application. In the example below, this is https://localhost:8080
.
For the Client Authentication Type make sure to select the Client Secret Basic option.

- Step 4: Find the
Client ID
andClient Secret
.
Client ID
and Client Secret
, be sure to save these somewhere safe.

You need to keep the
Client Secret
somewhere safe, as you will not have access to it again.Configure Console
On the Conduktor Console side, you can add the snippet below to your configuration file. You will have to replace the Client ID and Client Secret, as shown in steps 3 and 4.You can find the opendid issuer at:
https://oauth.id.jumpcloud.com/
as shown here
platform-config.yaml
Configure groups
If you want to use theexternal groups mapping
to map groups between your Conduktor Console instance and JumpCloud:
From the JumpCloud side, ensure you have:
- Checked
Email
andProfile
under the standard scopes - Set the
email_verified
to true - The same value in
group attribute
as in thegroups-claim
orCDK_SSO_OAUTH2_0_GROUPS-CLAIM
value of your Console’s configuration

groups-claim
to "groups"
in the Console configuration file.
Below is the full snippet for your configuration file:
platform-config.yaml
Map to external groups
Now that your configuration is finished, you can set up the mapping between JumpCloud and Conduktor Console groups. This way, when a user logs in, they will be automatically added to the corresponding Conduktor Console groups, based on the groups they belong to in JumpCloud. The value you need to put as an external group is the name of the JumpCloud group.Configure Keycloak as SSO
On Keycloak side, you’ll have to create a new application:- Step 1: create a new OpenID Connect client, and set the
client ID

- Step 2: Select the Client authentication

- Step 3: Configure the redirect URI
http(s)://<Console host>(:<Console port>)/oauth/callback/<OAuth2 config name>
For example, if you deployed Console locally using the name keycloak
in your configuration file, you can use http://localhost:8080/oauth/callback/keycloak
, like in the screenshot below.

- Step 4: Get the
client secret
in the Credentials tab

You can find the .well-known at:
http://<Keycloak host>:<Keycloak port>/realms/<realm name>/.well-known/openid-configuration
.Configure Console
On Console side, you can add the snippet below to your configuration file. You have to replace the client ID, client secret, and tenant ID, with what you got during the previous steps.platform-config.yaml
Configure groups
If you want to use theexternal groups mapping
to map groups between your Conduktor Console instance and Keycloak, you must create a scope and add it to your Keycloak application:
- Step 1: Create the scope and configure the mapper to Group Membership


- Step 2: Add the scope to the application

groups-claim
to "groups"
in the Console configuration file. Below is the full snippet for your configuration file:
platform-config.yaml
Map to external groups
Now that your configuration is finished, you can setup the mapping between Keycloak and Console groups. That way, when a user logs in, they will be automatically added to the corresponding Console groups, based on the groups they belong to in Keycloak. The value you need to put as an external group is the name of the Keycloak group.If you’ve selected
Full group path
in the mapper details of the scope, you will need to use the full path instead of the name of the group.Configure Okta as SSO
On Okta side, create a new application:- Step 1: Create an OpenID Connect web application

- Step 2: Configure the callback URI
http(s)://<Console host>(:<Console port>)/oauth/callback/<OAuth2 config name>
.
For example, if you deployed Console locally using the name okta
in your configuration file, you can use http://localhost:8080/oauth/callback/okta
, like in the screenshot below.

- Step 3: Configure app assignments, and save changes

- Step 4: Get
client ID
andclient secret
, that you’ll use in the configuration file of Console

- Step 5: Find the
issuer URL
in the Sign On tab of your application. It’s made likehttps://<domain>.okta.com

You can find the .well-known at:
https://<domain>.okta.com/.well-known/openid-configuration
.Configure Console
On the Console side, you can add the snippet below to your configuration file. You have to replace theclient ID
, client secret
and domain
, with what you got during steps 4 and 5.
platform-config.yaml
Please note that if you are using a custom auth server in Okta, the OPENID_ISSUER should be in the form
https://<yourOktaDomain>/oauth2/<authorizationServerId>/
rather than https://<domain>.okta.com
. Find out more about token customization.Configure an OIDC provider as SSO
Conduktor supports various OIDC (OpenID Connect)/OAuth2 providers, including: For others, follow these generic steps.-
Create an OIDC (OpenID Connect) application in your chosen provider. This application should use standard OAuth2/OIDC authorization code flow with
CLIENT_SECRET_BASIC
authentication method. - Set OAuth2 authorized redirect URI in your application
redirect URI
or callback URI
.
The redirect URI will look like this:http(s)://<Console host>(:<Console port>)/oauth/callback/<OAuth2 config name>
Where <Console host>
and <Console port>
depend on the Console external URL used and/or configured, and <OAuth2 config name>
is the name of the OAuth2 configuration in your Console configuration file see Console configuration step.
More details on Console external URL
When Console initiate the OAuth2 authorization code flow, it tells the OIDC provider where to redirect the user after the authentication process. But to forge this redirect URI, Console has several choices:Console external URL is configured
If the Console external URL is configured using environment variableCDK_PLATFORM_EXTERNAL_URL
or configuration platform.external.url
, it will use it.But SSO will work ONLY if Console is accessed using this URL. If you try to log in from the second URL you will be redirected to the first URL and then lose browser authentication cookies meaning the SSO will not work.
Console external URL is NOT configured
When no external Console URL is enforced, Console will use requests headers to resolve this external URL. This is recommended if Console is accessed using multiple URLs (internal, external, etc) and have SSO on each of them. The resolution strategy is the following:- Use the
Forwarded
header. This is the preferred method if you are using a reverse proxy in front of Console. It uses thehost
andproto
directives (if set) ofForwarded
header to determine the external URL. - Use the
X-Forwarded-*
headers. Support for the non-standard forwarded headers coming from some reverse proxy implementations. It uses theX-Forwarded-Proto
,X-Forwarded-Host
andX-Forwarded-Port
headers to determine the external URL. - Use the
Host
header. Used if you access to Console directly, without a reverse proxy. In this case, theHost
header (generally set by the browser) will be used to determine the external URL.
Port will be guessed depending on the content of the
Scheme (http/https) will be guessed depending on the current TLS configuration of Console. (default to
Host
header and fallback to Console configured port using environment variable CDK_LISTENING_PORT
(default to 8080
).Scheme (http/https) will be guessed depending on the current TLS configuration of Console. (default to
http
).- Get the client ID and secret from application settings
Configure Console
On Console side, you need to configure several properties to enable OIDC SSO. Required properties are:sso.oauth2.name
: the name of the OAuth2 configuration. This name will be used in the redirect URI defined on your provider in the steps before. It must be unique.sso.oauth2.client-id
: the client ID of your OAuth2 application.sso.oauth2.client-secret
: the client secret of your OAuth2 application.sso.oauth2.openid.issuer
: the issuer URL of your OpenID Connect provider. This url is used to discover the provider configuration using the.well-known/openid-configuration
path.
sso.oauth2.scopes
: the list of scopes to request during the authorization code flow. See OAuth2 configuration for details.
Example
The provider exposes its configuration using the well-known endpoint:https://<oidc domain>/.well-known/openid-configuration
. Here’s an example of a configuration file for a generic OIDC provider.
platform-config.yaml
SSO config properties
Property | Description | Environment variable | Mandatory | Type | Default |
---|---|---|---|---|---|
sso.ignoreUntrustedCertificate | Disable SSL checks | CDK_SSO_IGNOREUNTRUSTEDCERTIFICATE | false | boolean | false |
sso.trustedCertificates | SSL public certificates for SSO authentication (LDAPS and OAuth2) as PEM | CDK_SSO_TRUSTEDCERTIFICATES | false | string | ∅ |
OAuth2 config properties
Property | Description | Environment variable | Mandatory | Type | Default |
---|---|---|---|---|---|
sso.oauth2[].name | OAuth2 connection name | CDK_SSO_OAUTH2_0_NAME | true | string | ∅ |
sso.oauth2[].default | Use as default | CDK_SSO_OAUTH2_0_DEFAULT | true | boolean | ∅ |
sso.oauth2[].client-id | OAuth2 client ID | CDK_SSO_OAUTH2_0_CLIENTID | true | string | ∅ |
sso.oauth2[].client-secret | OAuth2 client secret | CDK_SSO_OAUTH2_0_CLIENTSECRET | true | string | ∅ |
sso.oauth2[].openid.issuer | Issuer to check on token | CDK_SSO_OAUTH2_0_OPENID_ISSUER | true | string | ∅ |
sso.oauth2[].scopes | Scopes to be requested in the client credentials request | CDK_SSO_OAUTH2_0_SCOPES | true | string | [] |
sso.oauth2[].groups-claim | Group attribute from your identity provider | CDK_SSO_OAUTH2_0_GROUPSCLAIM | false | string | ∅ |
sso.oauth2[].username-claim | Username attribute from your identity provider | CDK_SSO_OAUTH2_0_USERNAMECLAIM | false | string | email |
sso.oauth2[].email-claim | Email attribute from your identity provider | CDK_SSO_OAUTH2_0_EMAILCLAIM | false | string | email |
sso.oauth2[].allow-unsigned-id-tokens | Allow unsigned ID tokens | CDK_SSO_OAUTH2_0_ALLOWUNSIGNEDIDTOKENS | false | boolean | false |
sso.oauth2[].preferred-jws-algorithm | Configure preferred JWS algorithm | CDK_SSO_OAUTH2_0_PREFERREDJWSALGORITHM | false | string one of: “HS256”, “HS384”, “HS512”, “RS256”, “RS384”, “RS512”, “ES256”, “ES256K”, “ES384”, “ES512”, “PS256”, “PS384”, “PS512”, “EdDSA” | ∅ |
sso.oauth2-logout | Wether the central identity provider logout should be called or not | CDK_SSO_OAUTH2LOGOUT | false | boolean | true |
LDAP config properties
Property | Description | Environment variable | Mandatory | Type | Default |
---|---|---|---|---|---|
sso.ldap[].name | Ldap connection name | CDK_SSO_LDAP_0_NAME | true | string | ∅ |
sso.ldap[].server | Ldap server host and port | CDK_SSO_LDAP_0_SERVER | true | string | ∅ |
sso.ldap[].managerDn | Sets the manager DN | CDK_SSO_LDAP_0_MANAGERDN | true | string | ∅ |
sso.ldap[].managerPassword | Sets the manager password | CDK_SSO_LDAP_0_MANAGERPASSWORD | true | string | ∅ |
sso.ldap[].search-subtree | Sets if the subtree should be searched. | CDK_SSO_LDAP_0_SEARCHSUBTREE | false | boolean | true |
sso.ldap[].search-base | Sets the base DN to search. | CDK_SSO_LDAP_0_SEARCHBASE | true | string | ∅ |
sso.ldap[].search-filter | Sets the search filter. By default, the filter is set to (uid={0}) for users using class type InetOrgPerson . | CDK_SSO_LDAP_0_SEARCHFILTER | false | string | "(uid={0})" |
sso.ldap[].search-attributes | Sets the attributes list to return. By default, all attributes are returned. Platform search for uid , cn , mail , email , givenName , sn , displayName attributes to map into user token. | CDK_SSO_LDAP_0_SEARCHATTRIBUTES | false | string array | [] |
sso.ldap[].groups-enabled | Sets if group search is enabled. | CDK_SSO_LDAP_0_GROUPSENABLED | false | boolean | false |
sso.ldap[].groups-subtree | Sets if the subtree should be searched. | CDK_SSO_LDAP_0_GROUPSSUBTREE | false | boolean | true |
sso.ldap[].groups-base | Sets the base DN to search from. | CDK_SSO_LDAP_0_GROUPSBASE | true | string | ∅ |
sso.ldap[].groups-filter | Sets the group search filter. If using group class type GroupOfUniqueNames use the filter "uniqueMember={0}" . For group class GroupOfNames use "member={0}" . | CDK_SSO_LDAP_0_GROUPSFILTER | false | string | "uniquemember={0}" |
sso.ldap[].groups-filter-attribute | Sets the name of the user attribute to bind to the group search filter. Defaults to the user’s DN. | CDK_SSO_LDAP_0_GROUPSFILTERATTRIBUTE | false | string | ∅ |
sso.ldap[].groups-attribute | Sets the group attribute name. Defaults to cn . | CDK_SSO_LDAP_0_GROUPSATTRIBUTE | false | string | "cn" |
sso.ldap[].properties | Additional properties that will be passed to identity provider context. | CDK_SSO_LDAP_0_PROPERTIES | false | dictionary | ∅ |