SSO is configured per organization by an Owner or Admin. This guide walks through Google Workspace; the same fields work for Okta, Azure AD, OneLogin, and any SAML 2.0 IdP — see Other identity providers.
How it works
- Domain-routed. You claim your email domains (e.g.
acme.com). A login from that domain is routed to your org’s IdP. - Both directions. SP-initiated (the Sign in with SSO button on the login page) and IdP-initiated (the TigerGate tile in your IdP’s app launcher) both work.
- Just-in-time (JIT) provisioning. On first successful login, TigerGate creates the user and adds them to your org with a default role — no pre-invite needed.
- Isolated. Your IdP can only sign in emails in the domains you claimed, so one tenant can never assert accounts into another org.
Set up Google Workspace
You’ll copy two values from TigerGate into Google, then three values from Google back into TigerGate.1. Get your Service Provider details from TigerGate
Open the SSO settings
In the dashboard go to Organization Settings → Single Sign-On. The Service Provider details panel shows your org’s values. Keep this tab open.
Copy the ACS URL and Entity ID
- ACS URL (Assertion Consumer Service) —
https://<api-host>/api/auth/saml/acs/<org-id> - Entity ID (Audience) —
https://<api-host>/api/auth/saml/metadata/<org-id>
<api-host> is the API host of the region your organization is in — api.tigergate.dev on us1, the default. Copy the values from the panel rather than assembling them: they carry both your org ID and the right region, and an assertion posted to another region’s ACS URL will not sign anyone in.2. Create the SAML app in Google
Add a custom SAML app
In the Google Admin console go to Apps → Web and mobile apps → Add app → Add custom SAML app. Name it
TigerGate and continue.Copy Google's IdP details
On the Google Identity Provider details screen, copy the SSO URL and Entity ID, and Download the Certificate (a
.pem/.crt X.509 file). You’ll paste these into TigerGate in step 3. Continue.Enter TigerGate's Service Provider details
On the Service provider details screen:
- ACS URL → the ACS URL you copied from TigerGate
- Entity ID → the Entity ID you copied from TigerGate
- Name ID format → EMAIL
- Name ID → Basic Information → Primary email
First name and Last name so TigerGate can populate names. Finish, then turn the app ON for the users/OUs who should have access.3. Finish in TigerGate
Paste Google's IdP details
Back in Organization Settings → Single Sign-On, fill in:
- Identity Provider SSO URL → Google’s SSO URL
- Identity Provider Entity ID → Google’s Entity ID
- X.509 Certificate → paste the certificate text, or use Upload certificate to select the file you downloaded
Set domains and provisioning
- Allowed email domains → your domain(s), e.g.
acme.com(comma-separated) - Default role for new members → the role JIT-provisioned users get (Member by default)
- Leave Auto-create users on first SSO login (JIT) on unless you want invite-only access
Identity attributes
TigerGate reads the user’s email, and when present their first and last name, from the SAML assertion automatically — there is no attribute-mapping step to configure. It checks the common attribute names each IdP uses, and falls back to the NameID for the email (Google Workspace sets the NameID to the user’s email). Set your IdP’s Name ID to the user’s primary email and provisioning works out of the box.| TigerGate field | Looked up from (in order) |
|---|---|
email / mail attribute → NameID (if it’s an email address) | |
| First name | firstName / givenName attribute |
| Last name | lastName / surname / sn attribute |
Require SSO (enforcement)
Turn on Require SSO to block password login for your allowed domains — everyone must go through the IdP.Require SSO is per region. Like every other setting, it applies only to the organization you set it on. If your company has organizations in more than one region, enable it in each — otherwise password login stays open in the ones you missed. Each region also needs its own SAML application in your IdP, because the ACS URL and Entity ID are region-specific.
Other identity providers
The three fields TigerGate needs — SSO URL, Entity ID, and X.509 Certificate — exist in every SAML IdP under different names. Configure your IdP with TigerGate’s ACS URL and Entity ID (from the Single Sign-On tab), set the Name ID to the user’s email, then paste these back:- Okta
- Azure AD / Entra ID
- Generic SAML 2.0
Create a SAML 2.0 app. Use TigerGate’s ACS URL as the Single sign-on URL and Entity ID as the Audience URI (SP Entity ID). From View SAML setup instructions, copy the Identity Provider Single Sign-On URL (→ SSO URL), Identity Provider Issuer (→ Entity ID), and X.509 Certificate.
Troubleshooting
| Message | Cause & fix |
|---|---|
SSO is not configured for <domain> | The domain isn’t in Allowed email domains, or SSO isn’t enabled. Add the domain and enable. |
SSO sign-in failed: the response could not be verified | Wrong/expired certificate, the SSO URL points at a different app, or large clock skew. Re-copy Google’s certificate and SSO URL. |
The SSO response did not include an email address | Name ID isn’t set to the primary email, and no email/mail attribute was sent. Set Name ID format = EMAIL. |
email domain "…" is not allowed for this organization | The signed-in user’s email domain isn’t claimed by this org. Add it to Allowed email domains. |
no account exists … and just-in-time provisioning is disabled | JIT is off and the user was never invited. Enable JIT, or invite the user first. |
| The IdP reports a delivery failure, or sign-in never returns to TigerGate | The ACS URL points at a different region than the one your organization is in. Re-copy the ACS URL and Entity ID from Service Provider details — they’re region-specific. |
Under the hood: TigerGate validates the assertion’s signature, time window, and audience, then issues a normal session — SSO logins behave exactly like password logins everywhere else in the product.