Skip to main content

Set Up SAML SSO with Any Identity Provider

How to set up Single Sign-On with an SAML Provider

BetaTesting works with any identity provider that supports SAML 2.0, including Microsoft Entra ID (Azure AD), Google Workspace, OneLogin, Ping Identity, and JumpCloud. This guide covers the shape of that setup: create an application in your provider, run the BetaTesting setup wizard yourself, exchange two values with our team, then turn the connection on.

Using Okta? Follow Set up SAML SSO with Okta instead. It covers the same flow against Okta's exact screens.

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:

  1. You create a SAML application in your IdP

  2. You share your IdP metadata with BetaTesting

  3. BetaTesting configures the connection and provides you with the final SAML values

  4. You update your IdP with the values from BetaTesting

  5. 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:

  1. Create a new application or app integration

  2. Select SAML 2.0 as the sign-on method

  3. Give the app a descriptive name (e.g., BetaTesting or BetaTesting 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)

https://placeholder.betatesting.com

Provided by BetaTesting

Audience URI (SP Entity ID)

https://placeholder.betatesting.com

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?

email

User's email address

Yes

displayName

User's full display name

Yes

Group Attribute Statements (optional, for role mapping)

If you want BetaTesting to assign roles from your provider's groups, send group memberships as an attribute too. Most providers name that attribute groups. Microsoft Entra usually uses roles. Whatever you name it, write it down, because you type the same name into the wizard in step 3.

Send only the groups that matter to BetaTesting rather than every group a person belongs to. Many providers let you filter, for example to group names starting with BetaTesting.

Attribute Name

Value

groups

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:

  1. IdP SSO URL - The URL where BetaTesting sends SAML authentication requests (sometimes called "Login URL" or "SAML Endpoint")

  2. IdP Issuer / Entity ID - A unique identifier for your identity provider

  3. X.509 Signing Certificate - The certificate your IdP uses to sign SAML assertions (download the .cer or .pem file)

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: Set up the connection in BetaTesting

In BetaTesting, open Integrations from your company menu, then the Single Sign-On tab, and click Set up your first connection. If you already have a connection, click Add a connection instead.

The wizard has four steps.

1. Provider

  • Identity provider: pick yours from Okta, Microsoft Entra ID (Azure AD), Google Workspace, OneLogin, and JumpCloud, or pick Something else and type the name.

  • IdP Sign-On URL: paste the sign-on URL you collected in step 2. This field is optional. If you leave it blank, we email you for it.

  • Group claim name: the attribute name from your group attribute statement. It defaults to groups. Change it to roles for Microsoft Entra, or to whatever you named yours.

2. Access

  • Allowed email domains: the domains your team signs in with, separated by commas, for example acme.com, eu.acme.com. This is optional, but setting it is what lets your subdomain sign-in page route people to your provider. Each domain has to share a root with your company subdomain.

  • Default role for new members: the role someone gets when no role mapping matches them. Choose Tester, Read only, Support only, or Full admin.

3. Roles

This step is optional. To add a mapping, type the group value your provider sends, choose the BetaTesting role it should grant, and click Add. Repeat for each group. You can skip the step entirely and add mappings later from the connection page. See SSO Role Mapping & Permissions for what each role can do and how mappings are applied.

4. Review

Check the summary and click Submit setup. Your connection appears with the status Awaiting setup, which means we have your details and are building the connection on our side, usually within one business day. You can keep editing your access settings and role mappings while you wait.

Your account manager gets in touch to collect the X.509 signing certificate you downloaded in step 2, through a secure channel.

Step 4: 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:

  1. Update the Single Sign-On URL / ACS URL with the value from BetaTesting

  2. Update the Audience URI / SP Entity ID with the value from BetaTesting

  3. Save your changes

Step 5: Assign Users

Assign the users or groups who should have BetaTesting access to the application in your provider. Only assigned people can sign in. If you are using group based role mapping, assign the mapped groups here so their membership travels in the assertion.

Step 6: Enable the connection in BetaTesting

  1. Go back to Integrations, open the Single Sign-On tab, and open your connection.

  2. Turn on the toggle so it reads Single Sign-On is enabled.

The status changes from Awaiting setup or Draft to Live, and Single sign-on overview explains what each status means. The toggle only appears once our team has finished provisioning, so if you cannot see it yet, the connection is not ready.

Step 7: Test the sign-in

  1. Open a private or incognito browser window.

  2. Go to your company sign-in page at your subdomain, for example acme.betatesting.com/login.

  3. Enter the email address of a user assigned to the application. You should be sent to your provider's sign-in page.

  4. Authenticate. You should land back in BetaTesting, signed in.

Then check that a brand new user got a BetaTesting account automatically, and that someone in a mapped group got the role you expect. The connection page shows how many members have signed in through SSO and when the last sign-in happened.

Provider-Specific Notes

Microsoft Entra ID (Azure AD)

  • Create the enterprise application as a non-gallery application.

  • Set the identifier (Entity ID) and reply URL (ACS URL) under Single sign-on, Basic SAML Configuration.

  • Configure group claims under Single sign-on, Attributes & Claims. Entra usually names that claim roles, so set the wizard's Group claim name to match.

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 shows its IdP metadata on the second screen of its own wizard.

  • Enter the ACS URL and Entity ID on the Service provider details screen.

Things to know

  • Nothing you enter in the wizard is locked in. Display name, allowed domains, default role, group claim attribute, and every role mapping stay editable on the connection page.

  • Claim values are matched exactly, including capitalization, and when someone matches more than one mapping the one nearest the top of the list wins. Drag rows to change that order.

  • You can run more than one connection on the same company, for example one per business unit or one per provider.

  • Each allowed domain has to share a root with your company subdomain. With the subdomain acme, both acme.com and eu.acme.com are accepted, and acmegroup.com is not.

Next steps

Related Articles
Did this answer your question?