Set up single sign-on
Connect your identity provider over SAML 2.0 or OpenID Connect, verify your email domain, test the connection, then require SSO for everyone at that domain.
Who can do this: the Owners of the account that holds the workspace, on the Enterprise plan. Admins cannot: identity configuration decides who may enter the workspace at all, and an admin who could change it could give themselves a way back in after being removed.
The page puts it this way: "Configure it yourself: no support ticket, no engineering call. Verify your domain, test the connection, then enforce."
Before you start
- Admin access to your identity provider, to create an application for transglot.
- Control of your email domain's DNS, to publish a TXT record.
- Choose the protocol. It "cannot be changed once the connection is saved."
| Protocol | Use it for | What you enter in transglot |
|---|---|---|
| SAML 2.0 (self-managed) | Any SAML 2.0 identity provider, such as Okta, Microsoft Entra ID, Google Workspace or JumpCloud | IdP entity ID, SSO URL, Signing certificate |
| OpenID Connect | Any OpenID Connect provider, such as Microsoft Entra ID, Google Workspace, Okta, Auth0 or Keycloak | Issuer URL, Client ID, Client secret |
Open Single sign-on & SCIM
Open Settings, choose the Workspace tab, then Single sign-on & SCIM.
Describe your identity provider
Under 1. Your identity provider, choose the Protocol and enter your Email domain, for example acme.com. Then fill in the protocol's fields (see below) and select Save configuration.
Prove you own the domain
Under 2. Prove you own your domain, publish the TXT record shown on your domain's DNS. Its value starts with transglot-domain-verification=. Then select Verify domain. "Until the domain is verified, SSO cannot be enforced."
Give your provider transglot's values
Copy the values under Values for your identity provider into the application you created at your provider (see below). Copy them rather than typing them: a value that differs by one character fails at sign-in with an error from your provider.
Test the connection
Under 3. Test the connection, select Test connection. The result lists each check that passed, or the first one that failed.
Require SSO
Once the domain is verified and the test passes, turn on Require SSO for everyone in your workspace, read the confirmation, then select Require SSO.
SAML 2.0 fields
In transglot:
| Field | What to enter |
|---|---|
| IdP entity ID | "The issuer / entity ID your identity provider publishes, e.g. http://www.okta.com/exk1a2b3c." |
| SSO URL | "The IdP's HTTP-POST single-sign-on endpoint. Must be a public https URL." |
| Signing certificate | "The IdP's X.509 public certificate (PEM). Write-only: once saved, we only ever tell you whether it is present." |
At your identity provider, from Values for your identity provider:
| Value | Pattern |
|---|---|
| Assertion consumer service (ACS) URL | https://app.transglot.ai/sso/<connection>/acs |
| Service provider entity ID (audience) | shown on the page |
| SP metadata URL | https://app.transglot.ai/sso/<connection>/metadata |
<connection> is specific to your workspace's connection. The values appear once the configuration is saved.
transglot reads the person's email address from the SAML NameID, or from an email, mail or emailaddress attribute. It reads their name from displayName or name, or givenName and sn, and an optional role from a role or roles attribute.
OpenID Connect fields
In transglot:
| Field | What to enter |
|---|---|
| Issuer URL | Your provider's issuer. For Microsoft Entra ID, https://login.microsoftonline.com/<tenant-id>/v2.0, using the tenant ID rather than common. For Google Workspace, https://accounts.google.com. transglot reads the provider's /.well-known/openid-configuration from it. |
| Client ID | "The application (client) ID your provider issued for transglot." |
| Client secret | "Write-only: once saved, we only ever tell you whether it is present." |
At your identity provider, register the Redirect URI (callback) shown on the page. Its pattern is https://app.transglot.ai/sso/<connection>/oidc/callback.
transglot asks for the openid email profile scopes, and reads the person's email address, their name, and an optional role or roles claim.
What happens when SSO is required
"Everyone with an email address ending in @" your domain "is sent to your identity provider when they sign in with a password or a passkey, and signing in with Google or GitHub stops working for them." People with an address at any other domain sign in as they do now.
The Owners of the account keep their password and passkey sign-in, so a broken connection cannot lock you out. Someone has to be able to get in and turn enforcement off if the identity provider is unreachable.
Who gets in, and with what role
- Existing members sign in as they are. An SSO sign-in never changes an existing member's role.
- New people at your verified domain are added to the workspace the first time they sign in through your identity provider, as long as the workspace can take new members. They arrive as Translator.
- A role sent by your provider (
roleorroles) is honoured up to Admin, and only when the person is first added. "owner", an unknown value or no value gives Translator. - What SSO can never grant: it never makes anyone an Owner of the account. Account Owners are set on the account's Owners & billing members page.
The sign-in only works for an email address at the connection's verified domain, which is what stops one workspace's identity provider signing people into another.
To keep roles in step with your directory after people join, set up SCIM. See Set up SCIM provisioning.
Change or remove the connection
- Changing the Email domain resets its verification and its connection test, so enforcement stays off until both pass again.
- Pointing the connection at a different identity provider resets the test and enforcement until you test the new one.
- To stop requiring SSO, turn off Require SSO for everyone in your workspace and select Stop requiring SSO. People at your domain can then sign in with a password, a passkey, Google or GitHub again.
- Remove SSO deletes the connection and its SCIM token. "Everyone keeps their login and signs in with a password again, so make sure they have one set before you do this." Select Remove connection to confirm.
Every configuration change, connection test and SSO sign-in is recorded in the audit log.
If it doesn't work
- "Verify the domain and pass a connection test to unlock enforcement.": the switch stays locked until both are done. Enforcing an untested connection could lock everyone out at once.
- "No matching TXT record found on ... DNS can take a few minutes to propagate.": wait, then select Verify domain again.
- "... is already verified by another workspace.": a domain can be verified by one workspace only.
- "The signing certificate could not be parsed." or "That does not look like a PEM-encoded X.509 certificate.": paste the full PEM certificate, including its BEGIN and END lines.
- "The signing certificate expired on ...": download the current certificate from your provider.
- "The issuer URL must use https.": use your provider's https issuer.
- "The issuer has changed, so the stored client secret no longer applies. Enter the secret from the new provider."
- "Enforcement is configured. It activates once an SSO provider with a login flow is connected. Until then, password login is not refused.": finish the protocol's fields and verify the domain.
- People cannot sign in: see My single sign-on login fails.