Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/gatling/gatling.io-doc/llms.txt

Use this file to discover all available pages before exploring further.

Custom Single Sign-On (SSO) lets your users authenticate to Gatling Enterprise Edition using your organization’s existing identity provider instead of Gatling-managed credentials. Once configured, users navigate to the Gatling Enterprise login page, click your organization’s SSO option, and are redirected through your identity provider’s standard authentication flow. This simplifies user lifecycle management—account creation, deactivation, and MFA enforcement are all handled by your IdP.
Custom SSO is only available on the Gatling Enterprise enterprise plan and must be configured with assistance from the Gatling support team. Open a ticket via the support portal before starting any configuration on your identity provider.
Currently, Gatling Enterprise only supports SSO systems that are accessible on the public internet. On-premises identity providers that are not publicly reachable are not supported.

​
Before you start

If your organization already has users on Gatling Enterprise, switching to SSO requires re-inviting all users—their accounts are linked to your new SSO after they accept the re-invitation. Your existing data (teams, tests, reports, API tokens) is not affected by the SSO configuration.

​
Information required by Gatling support

Provide the following to the support team when opening a ticket:
  • Organization name and slug — visible in Organization Settings
  • SSO-specific configuration — see the relevant section below for your identity provider
  • A user to designate as the initial global administrator — this user will sign in first after SSO is enabled to bootstrap the re-invitation process

​
Supported protocols

OIDC v1.0 is the recommended protocol. Most modern identity providers support it. Your IdP typically publishes its metadata at a well-known URL:
https://my-sso-server.com/.well-known/openid-configuration
Information Gatling needs from you:
  • OIDC metadata URL
  • Client authentication method (client secret as POST, Basic Auth, or JWT)
  • Client ID and client secret
Redirect URI to configure in your IdP:
https://auth.gatling.io/auth/realms/<your-org-slug>/broker/oidc/endpoint
For example, if your organization slug is acme-corp:
https://auth.gatling.io/auth/realms/acme-corp/broker/oidc/endpoint

​
Azure Active Directory (Azure AD) via OIDC

  1. In Azure AD, create an App Registration for Gatling Enterprise Edition
  2. Configure which accounts are permitted to connect (e.g., accounts in your tenant only)
  3. Locate the metadata URL: Overview → Endpoints → OpenID Connect metadata document
  4. Generate a client secret: Certificates & secrets → Client secrets → New client secret
  5. Configure the redirect URI: Overview → Add a redirect URI
  6. Send Gatling support the metadata URL, client ID, and client secret

​
Okta via OIDC

  1. In Okta, create a new App Integration with sign-in method OIDC and application type Web Application
  2. Copy the client ID, client secret, and Okta domain (the metadata URL derives from the domain)
  3. Configure the redirect URI in the app integration settings
  4. Send Gatling support the metadata URL, client ID, and client secret

​
SSO group mapping

SSO group mapping lets you automatically assign Gatling Enterprise roles based on a user’s group memberships in your identity provider. This eliminates the need to manually manage role assignments whenever your team structure changes.
SSO group mapping is only available with the OIDC protocol.

​
Configuring the IdP

Add a gatling-groups claim to your OIDC token that returns the complete list of groups to map. You can attach this claim to the standard openid scope—no custom scope is required.

​
Defining group mappings via API

Use the Gatling Enterprise Public API to define how SSO groups map to roles. Three mapping patterns are supported: 
{
  "group": "Administrators",
  "type": "sso-group-mapping",
  "globalRole": "Administrator"
}
When a user belongs to multiple SSO groups, they receive the highest level of access from all applicable mappings.
For all available roles, see the Users reference.

Build docs developers (and LLMs) love

Get started for freeTalk to us