Configuring TLS Protect Cloud to work with your SSO¶

Configuration must be done using your SSO administration console and TLS Protect Cloud. You'll need to do a few things before you get started.

Before you begin¶

A good place to start gathering the information you'll need to configure your chosen SSO is your SSO administrator. Before you refer to the configuration steps in the topics below, make sure you review and gather all of the following information:

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 handy 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
(Optional) Scopes: used for requesting additional 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, which is the TLS Protect Cloud URL, with your SSO administrator.

SSO admins need that URL so they can configure the SSO IdP to redirect users' web browsers back to TLS Protect Cloud after they've successfully authenticated with the IdP. During the following procedure, you'll copy the redirect URL and send it to your SSO admin.

Before you continue, make sure you've gathered all of the prerequisite information described above.

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.

Sign in to Venafi Control Plane.
Click Settings > Single Sign-On.
Do the following:
1. In Client ID, type the client ID, which uniquely identifies your TLS Protect Cloud account to your SSO solution.
  
  If you don't know your client ID, ask your SSO administrator.
2. In Client Secret, type the required password to your SSO.
  
  This is an application password used by TLS Protect Cloud to authenticate with your SSO. Your SSO administrator can give it to you if you don't know it.
3. In Issuer URL, type the URL of the endpoint used to communicate with your SSO.
  
  Your SSO administrator can give this information to you.
4. Under Redirect URL, click to copy the TLS Protect Cloud URL and send it to your SSO admin.
  
  Your SSO administrator needs the redirect URL so he or she can configure the SSO IdP to redirect users back to TLS Protect Cloud following successful authentication with the IdP.
5. Under SSO Login URL, click to copy the SSO Login URL and send it to your SSO admin.
  
  Your SSO administrator needs the redirect URL so he or she can configure the SSO IdP to redirect users back to TLS Protect Cloud following successful authentication with the IdP.
6. (Optional) In Scopes, if you want any additional user attributes to be requested during authentication, type them here.
  
  Your SSO administrator can provide the list of claims that you should provide, such as claims that provide group membership information about your users.
To verify that your configuration is accurate and works as expected, do the following:
1. Click Test Connection.
  
  This option should display your SSO's sign-in page so you can verify that your settings are correct. If your SSO sign-in page doesn't appear, verify your configuration and try again.
2. (Optional) If you specified claims, and if your test is successful, click Show Claims to see the list of returned claims you specified.

Note on user roles¶

Users will be assigned roles at login based on their Team memberships. In the absence of any claim to Team mapping, new users logging in with SSO will be 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