Table of Contents

Auth0: Overview

Kristen Fiddes Updated by Kristen Fiddes

Read Time: 10 mins

What is Auth0?

Auth0 offers a way to add authentication services to your applications. With it integrated into your Sonar instance, users would select Continue With Single Sign On rather than inputting their Sonar credentials. Implementing Auth0 in your Sonar instance provides multiple, customizable, Single Sign-On options. The following authentication services are available:

  1. Google, including personal and Google Workspace accounts
  2. Microsoft social, limited only to personal email accounts.
For more information, refer to the “Setting up Auth0 with Microsoft” section
  1. Active Directory services
  2. SAML Authentication Providers
Different providers have different requirements for setting up SAML. If your provider setup differs from what's documented here, please refer to your provider's documentation before contacting support.

Configuring Auth0

Before fully configuring Auth0 with your Sonar instance, you must first integrate it with your Google or Microsoft system. Following this, you'll be provided a Client ID and Client Secret, which will be used during the integration with your instance.

For both options, the following information will be utilized:

  • sonar.software and auth0.com will be required for the authorized domains
  • /auth/userinfo.email and /auth/userinfo.profile will be the options selected when choosing from the list of scopes
  • https://sonarsoftware-prod.eu.auth0.com/login/callback?connection={connection_name} is to be used as the application home page

During the setup process, you'll be given the option of whether you want to restrict use to your domain or include external domains too. Which option you select depends on your business use, but any will work with the Sonar integration.

Setting Up Auth0 with Google

For details on integrating Auth0 with your Google dashboard, read this instead.

When configuring Sonar with Auth0 using Google, it generally means you are setting up authentication using Google accounts. The limitation mentioned here likely means that you can only authenticate users who have Google accounts. This typically includes accounts registered with Google services like Gmail or Google Workspace (formerly G Suite). It may not support authentication for users with accounts from other identity providers.

Setting Up Auth0 with Microsoft

For details on integrating Auth0 with Microsoft Azure, read this instead.

When configuring Sonar for Auth0 authentication using Microsoft, it typically means you are setting up authentication using Microsoft accounts. However, there will be a limitation with Microsoft authentication in that it will be limited to personal Microsoft accounts (e.g., outlook.com, live.com) and not support organizational accounts (e.g., accounts associated with a company's Microsoft Azure AD).

Permissions

To make use of the Auth0 feature, the corresponding role permissions must be enabled first. Please take a moment to review these new permissions, and ensure that the relevant roles have them added before proceeding with any walkthrough steps below.

If you're a Super-Admin of your Sonar instance, no permission changes are required for your account. For more information on Roles and Permissions overall, please review this linked article.

Navigate to Settings → Security → Roles and either choose to edit an existing Role or create a new Role. When the next page populates, locate the permissions reflected in the screenshots below and enable whichever ones are applicable to that Role.

The above permissions must be enabled to view the Identity Provider settings page.

Configuring Auth0 in your Instance

Before your users can take advantage of SSO (Single Sign On) with Auth0, you must enable and configure the feature within your instance. You can add up to 5 IDPs (identity providers) at a time, but for our example, we'll just be adding one:

  1. Navigate to SettingsSecurityLogin Options, toggle the Auth0 option, and then click on Save.
  2. Once Auth0 is enabled, click on Create Identity Provider and select your provider type
  3. A modal will appear where you will input the configuration settings.
    Google Provider example
    For our example below, Create Google Identity Provider was selected:


    1. Enabled allows you to toggle the IDP on and off. If you were to disable an active one, it would prevent users from logging in via that method.

    2. The Display Name, which must be unique within your instance to facilitate multiple providers.

    3. The Client ID field is where you'll input the one provided by your identity provider host.

    4. Similarly, the Client Secret section is for the secret provided by your identity provider host.

    Note
    There is no validation for the Client ID and Client Secret you add here; if the information is incorrect, then users will be unable to sign in via SSO.
    Microsoft Provider example
    For the example below, Create Microsoft Identity Provider is selected:


    1. Enabled allows you to toggle the IDP on and off. If you were to disable an active one, it would prevent users from logging in via that method.

    2. The Display Name, which must be unique within your instance to facilitate multiple providers.

    3. The Client ID field is where you'll input the one provided by your identity provider host.

    4. Similarly, the Client Secret section is for the secret provided by your identity provider host.

    Note
    There is no validation for the Client ID and Client Secret you add here; if the information is incorrect, then users will be unable to sign in via SSO.
    Active Directory Provider example
    For this example, Create Active Directory Identity Provider was selected:



    1. Enabled allows you to toggle the IDP on and off. If you were to disable an active one, it would prevent users from logging in via that method.

    2. The Display Name, which must be unique within your instance to facilitate multiple providers.

    3. Cert Auth must be enabled if your Active Directory server uses Client SSL certificate authentication.

    4. Disable Cache will affect your Active Directory login cache. For more information, refer to your Active Directory documentation.

    5. Kerberos must be enabled if your Active Directory server uses Windows Integrated Auth

    6. The Icon URL can be set to add a custom URL to the Universal Login button when a user selects it in Sonar.

    7. Setting Domain Aliases determine which domains users can belong to when logging in using Auth0. Users belonging to domains that have not been added will be unable to use Universal Login.

    8. Setting IPs controls the IP ranges users can be connected through in order to authenticate with Auth0. This function can only be used when Kerberos is enabled.

    Unlike Google IDP or Microsoft IDP, connecting Active Directory as an Identity Provider requires both the Sonar configuration to complete, and Active Directory middleware in place, which you can get here. Once your IDP information is filled in, a Ticket URL will be generated for use with Active Directory.

    To access the ticket URL, and other IDP details, click on the AD Identity Provider that's been added, and select “View Details”. From the side panel that opens, copy the ticket URL, and add it the the connector.

    SAML Provider example
    For more information on setting up SAML with Auth0, check out the dedicated article here: Auth0 | Setting Up SAML
  4. When all the fields are filled out, click Create.
Deleting or disabling an Identity Provider will not log out users utilizing that login method; if you want to prevent users from accessing your instance via SSO, then you must either disable Auth0 or disable their individual users.

Configuring Auth0 for your Users

Any email addresses intended to be used via Auth0 must be associated with an existing user in their Sonar instance. If someone were to attempt to log in when a user does not yet exist, they'll be met with the following error message:

Our Users: Overview article details how you can create a user. Once the user is set up, it must remain “enabled” for that person to continue to be able to log in.

If a user is ever “disabled” and they attempt to use SSO, they'll be met with a 401 error. If a user is disabled, their Sonar user will be automatically disabled during the next authentication check. For best results, disable the user manually in Sonar after deactivation their SSO account.

If a new user is created with the intention of solely utilizing the Auth0 feature, they will not have to follow through with the initial setup email that is automatically sent out via the instance. Instead, once they've successfully logged in for the first time using Auth0, you'll notice “Yes” underneath the “Completed Setup” column header.

Auth0 in Use

Once Auth0 has been set up and enabled, existing users can take advantage of the Auth0 feature. This option is visible on the login screen to access their instance.

When a user clicks Continue With Single Sign On, a new page will populate that lists the options available to log in with. In our example, we've set up an instance to utilize Google only, and therefore we see the following page:

From here, we will select Continue with Google IDP and be directed to the Google login page, then we'll be prompted to accept permission to pair the app.

If you are using Google Chrome and logged in with a Google account already, SSO will continue with those credentials automatically. If you intend to utilize an alternate account, you must either sign out of your account or open a new window with an alternate Google profile and continue from there.
If a user unintentionally clicks on Decline, the option will be presented again the next time they attempt to access the instance via the Auth0 feature.

As long as an account exists — and is enabled — with the email address you are attempting to log in with, you'll be able to successfully access the instance.

If you are logging in on a shared device, it is recommended that you use a browser that does not save your cache data, such as Chrome Incognito.

Field Tech App Consideration

SSO is not possible via the Sonar Field Tech App; any user intending to use the app will need to ensure they have a password set within their Sonar instance. Existing users should already have a password attached to their login that can be used, and new users should either continue with the initial account setup email they received or, alternatively, can request a password reset on their login screen.

Require SSO for Login

We recommend that you confirm SSO is working with your instance correctly before enabling the “Require Single Sign On” option within your instance.

Once you have Auth0 setup within your instance, you can force your users to use SSO only and remove the ability to log into Sonar with their user credentials. By forcing your users to use SSO, Sonar will hide the Sonar Login form from the web app, preventing your users from utilizing that as an option to bypass the SSO option enabled.

To enable this option, navigate to SettingsSecurityLogin OptionsRequire SSO for Login.

If you are unable to login using SSO and you need to disable the “Require SSO for Login” option from your instance, you must reach out to our Support team.

Enforce MFA with Directory Services and Identity Providers

If you have required SSO login for your instance, you may have the option to further enhance your security by enforcing Multi-Factor Authentication (MFA) through your active directory or identity provider. Below are some of the common providers along with their help articles for setting up MFA.

  1. Google Workspace (Link
  2. Microsoft Entra ID Multi-Factor Authentication (Link)
  3. AWS Directory Service
    1. AWS Managed Microsoft AD (Link)
    2. AD Connector (Link)
  4. Okta Workforce Identity (Link)
  5. JumpCloud (Link)

How did we do?

Application Firewall: General Overview and Best Practices

Password Policy In Depth

Contact