User management

Antithesis considers the basic unit of isolation to be a tenant. Each tenant receives their own instance of our entire cloud infrastructure, and their data cannot be read by other tenants, even when acting maliciously. In general, each customer gets a single tenant. It is possible, however, to configure multiple tenants for a single customer. This might be necessary if (for example) a customer has two teams, one of whom works on highly sensitive information.

There are four major actions in Antithesis which require authorization. These are:

1. Pushing images to the Antithesis registry
2. Kicking off tests
3. Viewing reports
4. Multiverse debugging

The first two actions should be launched by an automatic process such as a CI server. Consequently, we provide machine credentials for these actions which can be used by your CI process.

The last two actions are performed manually. For user management, we offer single sign-on (SSO) federation with your Identity Provider (IdP). You may elect to skip this integration and have your reports world-readable, but SSO is required for multiverse debugging.

Machine Credentials

Credentials for your CI system are generated by Antithesis and sent to you securely when you sign up. These credentials are used to push images and to run tests. Because these are long-lived credentials, after your initial setup period, you should not use them in manual or interactive processes. If these credentials are compromised, it is straightforward for Antithesis to rotate them and issue you new credentials.

The following credentials are generated for each Antithesis tenant:

$TENANT_NAME.key.json Container image registry credentials. A JSON file for pushing images to the Antithesis image registry created for your tenant. user and password Webhook credentials. Used to kick off Antithesis tests.

If you want us to post results back to your CI service, as in the Antithesis Github Action, you may need to create additional credentials or tokens.

Single Sign-On

Antithesis provides single sign-on (SSO) by integrating with your Identity Provider (IdP). This integration is available for any IdP that implements the OIDC protocol. Identity Providers who implement the OIDC protocol include:

• Okta
• Microsoft Entra
• Google Identity

Please consult your IdP’s documentation for more information on their OIDC support.

The following steps are a general guide to OIDC integration. The exact flow will be IdP specific – consult their documentation for details.

1. Antithesis provides you a login redirect. It will be something like:

   https://${tenant-domain-name}.antithesis.com/oidc/callback.

2. In your Identity Provider, create a new project/application.

3. Under your project/application, generate new OIDC/OAuth2 credentials. You will choose or generate a new client ID and secret.

4. Add your redirect URL from (1) to your project/application settings.

5. Provide Antithesis with the following three pieces of information:

   • Client ID and client secret from your OIDC project/application.
   • Issuer URL or /.well-known endpoint from your OIDC configuration. (If Google is your IdP, we need your Google Workspace domain address instead. E.g. our domain address is antithesis.com.)

Report access

Antithesis reports can be accessed only via a signed URL. This URL is impossible for an attacker to reverse-engineer, even with knowledge of the report ID and the encryption scheme. If the contents of your Antithesis reports are sensitive, take care not to post these report URLs in public. Report signing keys can be rotated, however doing so is a destructive operation that will invalidate all previously-generated reports, not just the one that was accidentally leaked.

For customers concerned about report access, Antithesis supports integration with Identity Providers (IdPs) to further restrict access to reports. If this integration is enabled, all access to reports will require a login through your IdP in addition to a signed URL.

Multiverse debugging

Multiverse debugging requires SSO to be enabled. All users must login through their IdP before they can access a debugging session.