Skip to content

Configuring Azure AD SSO integration with TLS Protect Cloud

If Azure AD is your SSO solution, this topic shows you how to integrate Azure with TLS Protect Cloud.

TLS Protect Cloud can be integrated with Azure AD to enable SSO for users who are managed by Azure AD (and any on-prem active directory forests that are synchronized with Azure AD). You do this by registering TLS Protect Cloud as an enterprise application in your AzureAD tenant.

To set up this integration, you'll first create an App registration for TLS Protect Cloud within Azure AD.


As an option, you can also configure Azure AD to include user group information in OIDC tokens, and then configure TLS Protect Cloud with the URLs and client ID/secret needed to interface with Azure AD.

Azure AD does not support requesting custom scopes to alter the claims returned in OIDC tokens. So, when using Azure AD, be sure to leave the Scopes field on TLS Protect Cloud's SSO configuration page blank.


Because you'll be making changes in both the Azure AD portal and TLS Protect Cloud, you'll complete the configuration faster if you open both user interfaces side-by-side before proceeding.

To set up this integration, you'll need to

  1. Configure Azure AD and TLS Protect Cloud to work together
  2. Test the connection between TLS Protect Cloud and Azure AD
  3. (Optional) Add a Groups claim

Step 1: Configuring Azure AD to work with TLS Protect Cloud

  1. Log in to your Azure account as a directory administrator or other user with permissions to create application registrations in your Azure AD tenant.

  2. Go to App registrations and click New registration.

  3. Type a name for the application (such as TLS Protect Cloud), and then configure supported account types.

  4. Sign in to Venafi Control Plane.

  5. Click Settings > Single Sign-On.
  6. Copy the Redirect URL from the SSO configuration page and paste it into the Redirect URI in Azure.

    After the registration is complete, you're directed to the App registration page for the TLS Protect Cloud application you just created.

    The next step then is to create a client secret for TLS Protect Cloud to use to authenticate with Azure AD.

  7. Back in TLS Protect Cloud, copy the SSO Login URL from the Single Sign-On page.

  8. In Azure, go to Branding and properties and paste the copied SSO Login URL into Home Page URL.

  9. In Azure, go to Certificates & secrets, click New client secret, and then give your secret a description and specify its lifetime.


    Be sure to give the secret a useful description, such as, Secret used by the TLS Protect Cloud application, which makes it easier to identify later on.

    Also, if you decide to use expiring client secrets, be sure to renew them and update TLS Protect Cloud with the new secrets as soon as possible.

  10. After creating the secret, copy the new secret's value (not the Secret ID), and then in TLS Protect Cloud, paste it into the Client Secret field on the SSO Configuration page.

    Screenshot of the _Certificates and secrets_ page in Azure


    After you leave the App registration blade, the client secret's value won't be visible again. Copy value of the secret ID to a secure password vault if you want to be able to retrieve it later on.

  11. In Azure, go to the Overview section in the App registration blade.

  12. Copy the Application (client) ID and then in TLS Protect Cloud, paste it into the Client ID field on the SSO Configuration page.

  13. In Azure, from the Overview section of the App registration blade, click Endpoints.

    This shows you the set of endpoints on which Azure AD provides OAuth/OIDC services.

  14. From the OpenID Connect metadata document field, select and copy only the following portion of the URL: (excluding /.well-known/openid-configuration).

    For example, if the full URL were, then you select and copy only, and paste it into the Issuer URL field on TLS Protect Cloud's SSO Configuration page.

  15. Back in TLS Protect Cloud, paste the URL portion you copied into the Issuer URL field on SSO Configuration page.

You're now done configuring the TLS Protect Cloud application in Azure AD. The next step is to test your connection.

Step 2: Testing the connection between TLS Protect Cloud and Azure AD

  1. From TLS Protect Cloud's Single Sign-On page, click Test Connection.

  2. When prompted, type your enterprise credentials into Azure AD.

    When the authentication succeeds, you're redirected back to the TLS Protect Cloud SSO Configuration page. From there, you can view the claims that were returned in the OIDC token issued by Azure AD.

  3. Save your SSO configuration.

Your users can now sign in using their SSO credentials.

Step 3: Adding a Groups claim (Optional)

Adding a groups claim in Azure AD allows group membership information to be sent to TLS Protect Cloud. Including group membership information in OIDC tokens allows you to leverage the Teams feature in TLS Protect Cloud to automatically add users to Teams and automatically assign a role to them based on your organization's requirements.

  1. In Azure AD, from the TLS Protect Cloud App registration blade, click Token configuration, and then click Add groups claim.

  2. Select the group types to include in the claim.


    In most cases, All groups is the correct choice. But if you have a large number of groups in Azure AD, you might want to send only those groups that have been assigned to the application specifically. This approach lets you specify the set of groups that are relevant for TLS Protect Cloud at the App registration level so that the set of groups returned in a user's group claims are limited to just those groups that are explicitly assigned to the application.

  3. Select ID from the Customize token properties by type section, and then select one of the options to indicate the format of the group name to be returned.

    For simple Azure AD deployments, sAMAccountName is sufficient.

  4. Click Add.

  5. In TLS Protect Cloud, from the Single Sign-On page, below the Scopes field, click Test Connection to verify that you now have a new claim called groups that returns the user groups to which the user is assigned in Azure AD.