Authentication and Authorization for real-time IDE SAST Service

To authenticate users against the SAST service we have to implement authentication using the best-practices that are already in place for comparable service architectures such as the AI Gateway.

In addition to authentication we also have to realize authorization so that the SAST service is only available to GitLab Ultimate customers.

We can base our implementation on the Authentication & Authorization implementation that is used by the AI Gateway.

client details

backend details

The AI Gateway is implemented as a Runway service behind a cloud connector feature. Clients do not currently connect directly to the AI Gateway Runway deployment, but there are plans underway to do so after initial authentication to decrease latency, see https://docs.gitlab.com/ee/architecture/blueprints/ai_gateway/#authentication--authorization and https://docs.gitlab.com/ee/development/cloud_connector.

All initial authentication requests are going to the GitLab API before they are passed onto the CloudConnector which handles all subsequent requests, see https://docs.gitlab.com/ee/development/cloud_connector/architecture.html.

It is advisable to implement both, the GitLab API for real-time SAST scanning as the 'proxied' variant through CloudConnector for compatibility reasons.

Related

Implementation plan

Note: as of 8/1/2024, cloud-connector does not support Ultimate-only, non add-on features. To help time box our effort, we may consider other solutions.

A. using cloud connector via a GitLab API

This solution would be ideal, as the CC framework is a good fit to our purpose. It includes a license based security model and implementation in our backend (in the scanner service), the frontend (gitlab-org/gitlab), and CC configuration are minimal.

Our solution would be analogous to Code suggestions implementation.

  1. Connect a new feature using Cloud Connector The new feature is introduced through a new backend service so ...
    1. Set up JWT validation. To accomplish this, a backend service must:
      1. to embed the customer's tier in the access token, follow the optional step by contacting #g_cloud_connector on slack to add an additional claim
      2. Maintain a JSON Web Key Set (JWKS).
      3. Validate JWTs with keys in this set.
    2. Make it available at cloud.gitlab.com by adding a new route.

B. re-implement CC authorization and routing for our purpose

Without using cloud-connector, we could implement authorization and routing for our API endpoints directly.

This solution isn't preferred for a number of reasons

  1. our team is unfamiliar with the code, and so our work would be slow and
  2. the result would demand a high level of scrutiny from gitlab-org/gitlab maintainers
  3. it would be largely redundant, as in the opposite of DRY
  4. our special case would be deprecated assuming CC implements Ultimate / non-addon feature support

B'. Route from the extension

Instead of routing from the GL instance, we could implement the routing in the extension itself by passing the direct connection data post-auth, similar to code_suggestions/direct_access.

This solution suffers from the same issues as B, but the complexity would be in the extension/language server instead. It also complicates the API.

C. skip the GL API, and authenticate directly with the scanner service

Bypassing the GitLab instance entirely, we could implement authentication and authorization in our backend by relaying credentials to an instance.

We're actually doing this now, but only for developers. It would be relatively easy to generalize our relayed check from "SAST-IDE devs only". The downside is that this solution does not advance the wider objective of security scanning as a consolidated GL service.

  1. update extension to use custom authentication
    1. on credential change, call scanner service authenticate method to set a cookie authenticating the user with the GL instance
    2. on scan, pass the project, setting a cookie to authorize scans of the project
  2. update the scanner service to relay credentials to instance
    1. for SaaS (only gitlab.com?), check that the given project is Ultimate licensed
    2. for self-managed instances, check that the instance is Ultimate licensed
Edited by Jason Leasure