Custom SSO configuration

    A custom Single Sign-On (SSO) configuration allows your users to sign into Gatling Enterprise Cloud using your organization's authentication system.

    Configuring a custom Single Sign-On (SSO) solution is only available on corporate plan and must be requested through our support portal.

    At the moment, we only support integration with SSO systems which are accessible on the Internet, and user roles are still administered within Gatling Enterprise.

    If you already have an organization on Gatling Enterprise Cloud, after configuring a custom SSO, you will need to re-invite your users and configure their roles. You will, however, keep all other existing data, such as your teams, simulations, reports, API tokens, etc.

    Required information

    To handle your support request, we will need to know:

    • the name and slug for your organization, visible on the organization settings page
    • relevant information depending on the type of SSO system used (see below)
    • a way to configure one of your users as a global admin, so that they can invite back your other users - in most cases, we will ask them to sign in once, after we have configured the SSO, to link their account

    OpenID Connect (OIDC) v1.0

    If your SSO system offers OIDC v1.0 integration, it will typically publish its metadata at a well known URL, often of the form https://my-sso-server.com/.well-known/openid-configuration. To configure the SSO integration, we will need:

    • the metadata URL
    • the client authentications which are supported by your OIDC implementation (client secret sent as POST, Basic Auth, or JWT)
    • the client ID and secret we should use to connect to the SSO

    Azure Active Directory (Azure AD) using OIDC

    We recommend using OIDC to integrate with Azure AD. You will need to create an app registration for Gatling Enterprise, and configure which accounts are allowed to connect. You will then find the metadata URL in Overview > Endpoints > OpenID Connect metadata document, and you can generate a new client secret in Certificates & secrets > Client secrets.

    You will need to configure the redirect URI in Overview > Add a redirect URI.

    Okta using OIDC

    We recommend using OIDC to integrate with Okta. You will need to create a new app integration, with the sign-in method “OIDC” and application type “Web Application”. You can then copy the client ID, client secret and Okta domain (you can find the metadata URL from the domain) for the application integration you just created.

    You will need to edit in the application integration you created to configure the redirect URI.

    SAML v2.0

    If your SSO system provides SAML v2.0 integration, the Identity Provider entity (IdP) is usually published on a particular URL. If that URL is not publicly accessible, export the metadata containing the information necessary to integrate with the IdP and forward it.

    To configure the SSO integration, we will need:

    • the SAML entity descriptor for your Identity Provider
    • the attributes for a user’s first name, last name, and email address (they should appear as ClaimTypes in your IdP’s entity descriptor)

    We can then give you our Service Provider (SP) descriptor if you need to import it into your SSO system.

    Google

    See Google’s guide on setting up an oAuth 2.0 app. Make sure to:

    • select the user type “internal” to only allow users from your organization
    • add gatling.io as an authorized domain

    You will need to create a client ID of the type “web application” with the authorized redirect URI, then send us the client ID and client secret.

    GitHub

    See GitHub’s guide on setting up an oAuth 2.0 app for an organization. Make sure to:

    • configure https://cloud.gatling.io as the Homepage URL
    • configure the Authorization callback URL we will provide you

    You will need to generate a new client secret, then send us the client ID and client secret. We will also need your GitHub organization’s name to restrict access to users from your organization.

    GitLab

    See GitLab’s guide on setting up an oAuth 2.0 app for a group. Make sure to:

    • configure the redirect URI
    • enable the following scopes: api, read_user, read_api

    We will need the application ID and secret. We will also need your GitLab group ID to restrict access to users from your group.

    Edit this page on GitHub

    ← Private packages
    Introduction →