LGTM Enterprise 1.22

Restricting access to LGTM

By default, when you add an authentication provider (for example, Azure DevOps, Bitbucket Cloud, GitHub.com, or GitLab.com) anyone who has an account with that provider, and who can reach your LGTM Enterprise instance in a browser, can access your system.

You can use a whitelist to restrict who can log in successfully, based on their email address.

Whitelists only control whether someone can gain access to LGTM or not. For information on how to restrict what data logged in users can access, see Controlling access to content.

Global or per-provider whitelists

You can create whitelists at two levels:

  • Global

    Configured from the General settings tab, this applies to all logins.

  • Provider specific

    Configured from the settings page for an authentication provider, this whitelist only restricts logins from this third-party system.

Generally it is not advisable to create a whitelist at both levels, as this is can become cumbersome to maintain. For more information, see Using two levels of whitelists below.

Adding a login whitelist

The process is very similar whether you are adding a global whitelist or a provider-specific whitelist:

  1. For a global whitelist:

    Go to the Settings page and scroll down the General settings tab to the Access section.

    For a provider-specific whitelist:

    Go to the Integrations page and double-click the authentication provider for which you want to add a whitelist.

  2. In the Login whitelist field, enter a comma-separated list of domains and/or specific email addresses.

    To log in successfully a user's email address must match at least one entry in this list. For example, if you enter:

    example.com, johndoe@example.org

    only people logging in with an account that uses a <name>@example.com email address—or the address johndoe@example.org—will gain access to LGTM. This restriction will apply either across all logins, or just for one authentication provider, depending on which type of whitelist you are adding.

    Wildcards are not permitted in whitelists.

  3. Click Update, or Update access settings, to apply the whitelist.

Affects on LGTM-managed accounts

The global whitelist affects all login accounts, including LGTM-managed accounts, where users log in to LGTM using an email/password combination maintained in LGTM.

If you add a global whitelist, LGTM prevents the creation of an LGTM-managed account if the email address does not match at least one entry in the whitelist.

Where the addition of a global whitelist invalidates existing LGTM-managed accounts—meaning they can no longer be used to log in to LGTM Enterprise—it is the administrator's responsibility to delete those redundant accounts.

Using two levels of whitelists

Generally it is advisable to decide whether you want to define a global whitelist, or a separate whitelist for some/all of the authorization providers you have set up. Defining whitelists at both levels increases the complexity of your system's setup.

If you define a global whitelist and a whitelist for a specific authorization provider, a user attempting to log in using an account from that provider will only gain access if their email address matches at least one entry in both whitelists: the global list and the provider's list. The effective whitelist is the intersection between the two whitelists. You can therefore use a provider-specific whitelist to tighten the restrictions imposed by the global whitelist.

Example

In this example, the system has three authorization providers configured and whitelists have been added to two of these providers. A global whitelist has also been defined, perhaps to apply restrictions to LGTM-managed accounts. The effective whitelist (that is the list in which an email address must match at least one entry) is shown for each of the three providers. LGTM-managed accounts use the global whitelist only.

  • Global whitelist

    Applies to all logins:

    example.com, example.net, johndoe@example.org
  • Authentication provider A

    No provider-specific whitelist configured.

    Effective whitelist for people logging in using an account from this provider:

    example.com, example.net, johndoe@example.org
  • Authentication provider B

    The whitelist for this provider is a subset of the domains/addresses in the global list:

    example.net, johndoe@example.org

    Effective whitelist for people logging in using an account from this provider:

    example.net, johndoe@example.org

    Note that people with accounts with this provider who have example.com email addresses will not be able to log in despite example.com being included in the global whitelist.

  • Authentication provider C

    The whitelist for this provider contains entries (gmail.com, joesoap@example.net) that are not included in the global whitelist and therefore serve no purpose:

    example.com, gmail.com, joesoap@example.net

    Effective whitelist for people logging in using an account from this provider:

    example.com

    Only people with an account that uses an example.com email address will be able to use this provider to log in.

Related topicsRelated topics