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.

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. (Optional) If you need to support multiple domains, such as mydomain2.com, mydomain3.com, do the following:

   1. Add the additional domains to your IdP.
   2. (Required) Contact Venafi Support to provide them with your additional domains. This is a security measure that allows Venafi to verify the authenticity of the domains before allowing them. This is a one-time requirement when adding any additional domains.

5. Sign in to TLS Protect Cloud.

6. Click Settings > Single Sign-On.

7. 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.

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

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

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

    TIP

    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.

11. 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.

    

    TIP

    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.

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

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

14. 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.

15. From the OpenID Connect metadata document field, select and copy only the following portion of the URL: https://login.domain.com/XXXXX-XXXXX-XXXX-XXXXXXXXX/v2.0 (excluding /.well-known/openid-configuration).

    For example, if the full URL were https://login.microsoftonline.com/XXXXX-XXXXX-XXXX-XXXXXXXXX/v2.0/.well-known/openid-configuration, then you select and copy https://login.microsoftonline.com/XXXXX-XXXXX-XXXX-XXXXXXXXX/v2.0 only, and paste it into the Issuer URL field on TLS Protect Cloud's SSO Configuration page.

16. 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.

   Tip

   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.