Skip to content

Configuring TLS Protect Cloud to use single sign on (SSO)

Users log in to TLS Protect Cloud using either a local account—where they enter a username and password directly into the TLS Protect Cloud login screen—or through single sign-on (SSO). SSO enables users to authenticate through an identity provider (IdP) such as CyberArk Identity, Azure AD, Auth0, or Okta.

To configure SSO, you must coordinate with your SSO administrator to update both the IdP configuration and the settings in TLS Protect Cloud.

Before you begin

Reach out to your SSO administrator to find out exactly what information they will need to connect your IdP with TLS Protect Cloud. Review the following information, and gather what you need so you can work together to configure SSO.

  • Have OAuth2.0 with OpenID Connect set up with your SSO identity provider (IdP). These are the protocols supported by TLS Protect Cloud Services.

  • Know your SSO solution's information, which is required during configuration, so make sure you have this information available before you begin:

    • Client ID: used by your SSO IdP to uniquely identify your TLS Protect Cloud account.

      It's a longer string and might look something like this:

      85623942900-a2g97bisb3fqrtlink8ci5es1ik91v3r.apps.google

    • Client Secret: an application password used by TLS Protect Cloud to authenticate to your SSO IdP

    • Issuer URL: tells TLS Protect Cloud which endpoints to use to communicate with your SSO IdP

    • Scopes: used for requesting attributes (called claims) for users.

    • You'll need to know the name of the claim and a value, both of which come from your IDP.

  • Share the Redirect URL with your SSO administrator.

    Your SSO admin will input the Redirect URL into the SSO configuration. It's the place the IdP will direct users after successful authentication.

Required claims for login

To successfully log in via SSO, your SSO configuration must include the following user claims:

  • email
  • given_name
  • family_name

Your SSO administrator must make sure these claims are correctly mapped and returned in the ID token during authentication. If any of these are missing, users won't be able to sign in.

Optional claims

You may optionally specify additional claims. For example, you can use the groups claim to map users to teams.

General steps for configuring SSO

The following steps are the general steps you'll take to set up any supported SSO to work with TLS Protect Cloud. Refer to the appropriate topic for your selected SSO.

  1. Sign in to Venafi Control Plane.

  2. Click Settings > Single Sign-On.

  3. Do the following:

    1. In Client ID, enter the value provided by your IdP.

      This identifies TLS Protect Cloud as a known application to your IdP.

    2. In Client Secret, enter the application password from your IdP.

      TLS Protect Cloud uses this to securely authenticate with your IdP during the login flow.

    3. In Issuer URL, enter the URL of your IdP's OpenID Connect issuer (e.g., https://exampleIdP.com/{tenant}/v2.0).

      This tells TLS Protect Cloud where to send authentication requests and where to find public signing keys.

    4. Under Redirect URL, click the copy icon to copy the Redirect URL and send it to your SSO administrator.

      The IdP will use this to redirect users back to TLS Protect Cloud after a successful login.

    5. Under SSO Login URL, click the copy icon to copy the URL.

      This is the URL used to start the login flow. You can share this with your SSO administrator to embed in a portal or test the flow.

    6. In Scopes, enter the following required scopes:

      • openid – enables OIDC and ID-token issuance
      • profile – returns given_name and family_name

      • email – returns the user’s primary email address

        (Add groups or other scopes if you need extra claims for team mapping.)

      These scopes are required for your IdP to include the user identity attributes (claims) that TLS Protect Cloud needs for login.

      Your IdP must return the following claims in the ID token:

      • email
      • given_name
      • family_name

  4. To verify that your configuration is accurate and works as expected, do the following:

    1. Click Test Connection.

      TLS Protect Cloud redirects you to your IdP's login page and initiates the OpenID Connection flow.

    2. After a successful test, click Show Claims to view the list of claims returned from you IdP. Make sure the following required claims are present:

      • Required claims: email, given_name, and family_name. These must be present and populated for SSO login to work.

      • Optional claims: such as groups, if you configured scopes to request them.

    If any required claims are missing or empty, users won't be able to sign in. Work with your SSO administrator and verify the accuracy of the attribute mappings.

Note on user roles

Users are assigned roles at login based on their Team memberships. In the absence of any claim to Team mapping, new users logging in with SSO are assigned the Guest role.

What's next?

After your SSO configuration is complete, consider the following next steps:

  • Enable email sign-in for other administrators as a "break-glass" measure. Allowing a limited number of email sign-in accounts can be helpful in situations where your SSO goes offline—either intentionally or due to an outage of your SSO service—and an alternate authentication method is required.

  • Work with your SSO administrator to publish TLS Protect Cloud in your SSO provider's portal, such as the Okta My Applications page. This can make it much easier for users in your organization to learn about TLS Protect Cloud.

  • Assign users to Teams using claims