BetaTesting supports Single Sign-On with any identity provider (IdP) that supports the SAML 2.0 standard. This guide covers the general setup process that works with providers like Microsoft Entra ID (Azure AD), OneLogin, Google Workspace, Ping Identity, JumpCloud, and others.
Using Okta? See our dedicated guide: Set Up SSO with Okta.
Prerequisites
Administrator access to your identity provider
An Enterprise plan on BetaTesting
Your BetaTesting account manager's contact information
Overview
The setup is a back-and-forth process between your IT team and BetaTesting:
You create a SAML application in your IdP
You share your IdP metadata with BetaTesting
BetaTesting configures the connection and provides you with the final SAML values
You update your IdP with the values from BetaTesting
Both sides test the login
Step 1: Create a SAML Application in Your Identity Provider
Sign in to your identity provider's admin console and create a new SAML 2.0 application. The exact steps vary by provider, but you'll typically need to:
Create a new application or app integration
Select SAML 2.0 as the sign-on method
Give the app a descriptive name (e.g.,
BetaTestingorBetaTesting SSO)
Initial SAML Configuration
Your IdP will ask for two values that BetaTesting provides after Step 2. For now, use placeholder values so you can complete the initial app creation:
Setting | Temporary Value | Final Value (from Step 3) |
Single Sign-On URL (ACS URL) | Provided by BetaTesting | |
Audience URI (SP Entity ID) | Provided by BetaTesting |
Additional SAML Settings
Configure these settings in your IdP:
Setting | Value |
Name ID format | Unspecified or Email |
Application username / Name ID | User's email address |
Protocol Binding | HTTP-POST |
Signature Algorithm | RSA-SHA256 |
Attribute Statements
Configure your SAML app to send the following attributes in the assertion:
Attribute Name | Value | Required? |
| User's email address | Yes |
| User's full display name | Yes |
Group Attribute Statements (optional, for role mapping)
If you want BetaTesting to automatically assign roles based on your IdP groups, configure a group attribute:
Attribute Name | Value |
| All groups the user belongs to (or a filtered subset relevant to BetaTesting) |
The exact configuration for group attributes varies by provider. Consult your IdP's documentation on sending group memberships in SAML assertions.
Step 2: Collect and Share Your IdP Metadata
After creating the SAML app, collect the following from your identity provider:
IdP SSO URL - The URL where BetaTesting sends SAML authentication requests (sometimes called "Login URL" or "SAML Endpoint")
IdP Issuer / Entity ID - A unique identifier for your identity provider
X.509 Signing Certificate - The certificate your IdP uses to sign SAML assertions (download the
.ceror.pemfile)
Tip: Many identity providers offer a Metadata URL that bundles all three values into a single XML document. If your IdP provides one, sharing the Metadata URL is the easiest option.
Send these values to your BetaTesting account manager through a secure channel. Your account manager will provide instructions for secure transfer.
Step 3: Update Your IdP with BetaTesting's Values
Once BetaTesting configures the connection, your account manager will provide you with:
Assertion Consumer Service (ACS) URL - The URL where your IdP sends SAML responses after authentication
Entity ID (SP Entity ID / Audience URI) - BetaTesting's unique identifier as a service provider
Go back to your SAML application in your IdP and replace the placeholder values:
Update the Single Sign-On URL / ACS URL with the value from BetaTesting
Update the Audience URI / SP Entity ID with the value from BetaTesting
Save your changes
Step 4: Assign Users
Assign users (or groups of users) to the BetaTesting application in your identity provider. Only assigned users will be able to log in via SSO.
Step 5: Test SSO Login
Coordinate with your BetaTesting account manager to test:
Your account manager will provide an SSO login link for your organization
Open the link in an incognito/private browser window
You should be redirected to your identity provider's login page
Authenticate with a user who is assigned to the BetaTesting app
After authentication, you should be redirected back to BetaTesting
What to verify:
Successful redirect back to BetaTesting after IdP authentication
User account is created (for new users) or matched (for existing users)
If group attributes are configured, the assigned role is correct
What BetaTesting Configures
Here's what the BetaTesting team handles during this process:
Enterprise SAML connection -- Using your IdP metadata (SSO URL, certificate, issuer), BetaTesting creates a SAML connection that establishes the trust relationship between your IdP and BetaTesting
SSO connection record -- Links the connection to your company account with your allowed email domain(s) and a default role for new users
Role mappings (if requested) -- Maps your IdP group names to BetaTesting roles. See SSO Role Mapping & Permissions
Validation and testing -- BetaTesting verifies the connection works before confirming setup is complete
Provider-Specific Notes
Microsoft Entra ID (Azure AD)
When creating the Enterprise Application, choose "Non-gallery application"
The Identifier (Entity ID) and Reply URL (ACS URL) are configured under Single sign-on > Basic SAML Configuration
Group claims can be configured under Single sign-on > Attributes & Claims
OneLogin
Create a SAML Custom Connector (Advanced) app
The ACS URL goes in the ACS (Consumer) URL field
The Entity ID goes in the Audience field
Google Workspace
Go to Apps > Web and mobile apps > Add app > Add custom SAML app
Google provides the IdP metadata on the second screen of the wizard
The ACS URL and Entity ID are entered on the "Service provider details" screen
Next Steps
SCIM provisioning: For automated user provisioning, see SCIM Provisioning Overview
Role mapping: To map IdP groups to BetaTesting roles, see SSO Role Mapping & Permissions
Troubleshooting: See SSO/SCIM FAQ & Troubleshooting