Enterprise

Set up SSO Illustrative

Single Sign-On (SSO) over SAML 2.0 for Shunya Labs accounts. Designed for Enterprise customers who run their own identity provider (Okta, Microsoft Entra ID / Azure AD, Google Workspace, OneLogin, JumpCloud) and want every employee to sign in to Shunya with their existing corporate credentials.

Illustrative, confirm the exact flow with your account team

The setup steps and identity-provider list below are an example flow based on how Enterprise SSO setups typically work. Shunya Labs does not currently publish a public SSO setup guide, the actual handshake (who sends what, in which order, and which identity-provider details Shunya needs) should be confirmed with your account team before you brief your IdP admin. Use this page as a checklist of what to gather, not as Shunya-prescribed instructions.

Before you start

You must be on an Enterprise plan, SSO is not available on Pay-as-you-go or Volume tiers.
You'll need an admin on your identity provider who can create a new SAML application and share metadata with Shunya.
Decide on the email domain users will use to sign in (e.g. @yourcompany.com). All accounts on that domain will be routed through SSO once it's enabled.

Set up SSO: step by step

Send Shunya your SSO domain

Reach out to your account team with the email domain users will sign in with (e.g. yourcompany.com). If you have multiple domains, send all of them.

Don't have an account team yet? Contact Shunya Labs ↗ and ask to be routed to Enterprise sales.

Receive Shunya's Service Provider configuration

Shunya will reply with the details your identity provider needs to configure the SAML application:

Single sign-on URL, the ACS endpoint that your IdP will POST the SAML response to.
Audience URI / SP Entity ID, identifies Shunya as the service provider in your IdP's configuration.
NameID format, typically EmailAddress.
Required attributes, usually email, firstName, lastName.

Configure your identity provider

In your IdP admin console, create a new SAML 2.0 application. Paste in Shunya's Service Provider details from step 2, and assign the relevant users / groups so they can sign in. Each provider's UI differs slightly; the principles are the same:

Okta, Applications → Create App Integration → SAML 2.0.
Microsoft Entra ID, Enterprise applications → New application → Create your own application → Non-gallery, then SAML.
Google Workspace, Apps → Web and mobile apps → Add custom SAML app.
OneLogin, Applications → Add App → "SAML Custom Connector".

When you save, your IdP will produce a metadata URL (or downloadable XML). Send that to Shunya.

Shunya completes the integration

Shunya ingests your IdP metadata, wires it up on the Shunya side, and enables SSO for your domain. You'll get a confirmation when SSO is live for your organisation.

After SSO is enabled

Users on your SSO domain will see a "Sign in with SSO" option (or be redirected automatically) on the Shunya login page.
Existing accounts on that email domain will be linked to their SSO identity on next login. No data is lost.
You can require SSO for the domain, i.e. reject password-based logins for matching emails, once you've confirmed the flow works for everyone.

Common questions

Do all my users go through SSO automatically?

Anyone whose email matches an SSO-claimed domain will be routed through SSO. Users on other email domains continue with the regular sign-in flow.

What about service accounts and API keys?

API keys are issued at the workspace level and are independent of SSO. SSO controls human sign-in to the dashboard and Playground; programmatic API access continues to use bearer tokens regardless of SSO status.

Can I enforce SCIM provisioning?

SCIM (automatic user provisioning / deprovisioning from your IdP) is typically available alongside SSO on Enterprise plans. Confirm with your account team whether your contract includes it.