LGTM Enterprise 1.23.1

Controlling access to content

The content in LGTM is derived from code repositories. You specify how LGTM should access repositories by defining one or more integrations, and then add code repositories to LGTM for analysis. Any successfully analyzed codebases are added as LGTM projects. For more information, see Defining integrations with external systems.

Controlling the default access for projects

The default access to each LGTM project is controlled by the authorization mechanism defined by the integration:

  • Public—all users can view all the information for projects created using this integration.

    For public projects, the full authorization level is used by default.

  • Private—no users can view the projects created using this integration. This can then be paired with manual authorization to give access to selected users.

    For private projects, the restricted authorization level is used by default.

  • External system—the project is treated as: public for users with access to the underlying repository, and private for users with no access. This uses authorization information from the external system. 

While you may want to restrict access to a few critical codebases, we recommend that you think carefully before routinely restricting access. LGTM Enterprise is designed to improve the development process by providing all users with the data they need to make decisions. Every time you restrict access to a resource, you reduce the pool of data available for decision making.

Overriding the default access for specific users

You can override the default access for an LGTM project by defining user-specific authorization rules using the Users administration page. This is particularly useful for managers and other users who don't have an account for an external system, but who need to see the related projects.

User-specific rules act on one of the following scopes:

  • Global—overrides the authorization for all projects, from all integrations.
  • Integration-level—overrides the authorization for all projects generated from repositories hosted by one integration.
  • Project-level—overrides the authorization for one project.

You define rules and specify the level of authorization to apply to that scope, one of: full, restricted or hidden. When you define a user-specific rule, it overrides the default access for that user for the specified scope. For more information, see Managing user-specific rules.

Overriding the behavior for private projects

For users without full access to a project, the restricted authorization level is suitable for all but the most sensitive codebases. However, in some systems you might need to hide all information about private projects from users who don't normally have access to those codebases. If this is required, you can override the behavior for private projects globally using the Settings administration page.

To hide all information about private projects from unauthorized users, display the Settings administration page and enable the Completely hide private projects option. For an example of how this affects the data displayed to users, see About authorization levels.

Example

Company X uses GitHub Enterprise to host most of their repositories. They also have a few Subversion repositories. All developers have accounts for GitHub Enterprise and they have read-access to most repositories. The only GitHub Enterprise repository with restricted access is the Security project, which is visible only to Jane and John.

Initial set up

On the Integrations page, you (the LGTM application administrator) create:

  1. An integration with GitHub Enterprise which allows developers to access LGTM using their existing GitHub Enterprise accounts. This uses the default authorization mechanism, and uses GitHub data to ensure that LGTM respects the read permissions defined in GitHub Enterprise.
  2. An integration with Subversion which they configure to use the Public authorization mechanism.

This setup configures LGTM access for all of Company X's repositories. It results in the following permissions being granted, based on the information LGTM receives from the integrations:

User Project Authorization level Reason
Jane and John All GitHub Enterprise projects Full Settings in GitHub Enterprise give Jane and John read access for all projects
Any developer (apart from Jane and John) Security project Restricted These users don't have read access for this project in GitHub Enterprise
Any developer Any GitHub Enterprise project except Security Full Settings in GitHub Enterprise give all developers read access for these projects
Other employees All GitHub Enterprise projects Restricted They have no accounts for GitHub Enterprise, and so have no read access
All users All Subversion projects Full Access is defined as public.

This assumes that you have created LGTM login accounts for the users described in the table above as "other employees," or that your have set up LGTM Enterprise to allow users to access content without logging in (see Unauthenticated access to lgtm).

Fine-tuning the access

With the default configuration, most LGTM users can view the full data for the codebases that they're interested in. However, the CTO needs to see the full data for all projects.

To configure this:

  1. On the Users page, find the CTO's LGTM user account.

  2. In the Authorizations column, click the Update link to display this user's authorizations page.
  3. For the "global authorization" rule, click FULL to apply the Full authorization level across all projects for this user.

This rule overrides the CTO's default access so that they can now see all the data for all projects, even the Security project.

Related topicsRelated topics