Google Workspace
Configure Google Workspace as a SAML 2.0 identity provider for Safeguard.
Google Workspace
Use this when you want Google Workspace itself to be the SAML identity provider (distinct from the "Sign in with Google" OAuth button — see Social login for that).
Example values
The tenant-specific values below (the sg_ab12cde parts) are examples that show the shape of each value — Safeguard displays your real ones in the Add Provider dialog after you click Save. The point of this table is to make it unambiguous which value goes on which side.
In Google — Service provider details:
| Field | Example value |
|---|---|
| ACS URL | https://api.safeguard.sh/auth/idp/realms/sg_ab12cde/broker/google-workspace/endpoint |
| Entity ID | https://api.safeguard.sh/auth/idp/realms/sg_ab12cde |
| Name ID format | EMAIL |
| Name ID | Basic Information → Primary email |
In Google — Attribute mapping:
| Google directory attribute | App attribute |
|---|---|
Basic Information → Primary email | email |
Basic Information → First name | firstName |
Basic Information → Last name | lastName |
In Safeguard — Add Provider → SAML 2.0:
| Field | Example value |
|---|---|
| Alias | google-workspace |
| Display Name | Sign in with Google Workspace |
| SSO Service URL | https://accounts.google.com/o/saml2/idp?idpid=C0abc1def |
| Entity ID | https://accounts.google.com/o/saml2?idpid=C0abc1def |
| X.509 Certificate | the PEM block below |
-----BEGIN CERTIFICATE-----
MIIDdDCCAlygAwIBAgIGAX...(full cert from your IdP)...P3B/k0SolrFYPo
-----END CERTIFICATE-----Two different "Entity ID" values — don't mix them up. SAML involves two separate fields, both usually labelled "Entity ID", and they must hold different values:
- The IdP Entity ID identifies the identity provider (Google):
https://accounts.google.com/o/saml2?idpid=C0abc1def. This goes into Safeguard — it's the Entity ID field of the Add-Provider form.- The SP Entity ID identifies Safeguard as the service provider:
https://api.safeguard.sh/auth/idp/realms/sg_ab12cde. This goes into Google — Google's Entity ID field on the Service provider details screen, alongside the ACS URL.Putting Google's own entity ID into Google's Entity ID field (echoing Google's value back to Google) makes Google reject the request. They must be the two distinct values above.
Both sign-in directions work. Start at
https://app.safeguard.shand click the Google Workspace button (SP-initiated), or launch from Google's app-launcher tile or Google Admin's Test SAML login button (IdP-initiated) — both log you straight into Safeguard. Because you're already signed in to Google, the IdP-initiated route completes with no second prompt: Safeguard detects the unsolicited SAML response and transparently restarts it as an SP-initiated login.
-
In Google Admin Console, go to Apps → Web and mobile apps → Add app → Add custom SAML app.
-
Name the app (e.g. "Safeguard") and click Continue.
-
On the Google IdP information screen, note the SSO URL, Entity ID, and download the Certificate. Click Continue.
-
On Service provider details, enter:
- ACS URL: the ACS URL Safeguard shows in the dialog after Save, copy-pasted exactly —
https://api.safeguard.sh/auth/idp/realms/<tenantId>/broker/google-workspace/endpoint. Typing this by hand is a common source of errors (wrong domain, missing path segment); if login fails outright with no error reaching Safeguard at all, re-check this field character-by-character against what Safeguard's dialog shows. - Entity ID: the SP Entity ID Safeguard shows after Save —
https://api.safeguard.sh/auth/idp/realms/<tenantId> - Name ID format:
EMAIL - Name ID:
Basic Information → Primary email
- ACS URL: the ACS URL Safeguard shows in the dialog after Save, copy-pasted exactly —
-
On Attribute mapping, Google's form has two columns: Google directory attributes (pick from a dropdown) on the left, App attributes (you type the name) on the right. Add these rows:
Google directory attributes App attributes Basic Information → Primary email email(required — do this even though you already set the Name ID to the same field in step 4; Safeguard reads email from this named attribute, not from the Name ID)Basic Information → First name firstName(optional — only if you want it synced)Basic Information → Last name lastName(optional — only if you want it synced)Do not leave a half-filled row (a Google directory attribute selected with no App attribute name typed, or vice versa) — Google's admin console will reject the whole form with a generic
400 internal_errorreferencingschemaKeyif you do. Delete any empty/incomplete row before saving. -
Click Finish.
-
Back in Safeguard, click Add Provider → SAML 2.0 → Google Workspace, and enter the SSO URL, Entity ID, and Certificate from step 3, plus an alias/display name. Save.
-
In Google Admin Console, turn the app ON for everyone (or the specific org units you want), under User access.
-
Confirm by signing in. Either start from Safeguard — go to
https://app.safeguard.sh, enter your email, and click the Google Workspace SSO button — or use Google Admin's Test SAML login button (or the Gmail app-launcher tile). All three log you directly into Safeguard.
What "User access: ON for everyone" actually controls: this only decides which Google Workspace users are allowed to attempt SAML sign-in through this app — it does not by itself grant them access into Safeguard. A user still needs a Safeguard account: either they already exist in the tenant (they'll be signed into their existing account), or your tenant's provisioning policy allows just-in-time creation on first login. If you restrict this to specific org units, only users in those org units can even reach the SAML redirect; everyone else sees a Google-side "you don't have access to this app" message before Safeguard is ever involved.
Common errors: Google Admin shows 400. Error: internal_error mentioning schemaKey on the Attribute mapping step — see step 5 above (delete any half-filled attribute-mapping row). Users don't see the option to sign in via Google Workspace even after saving the provider in Safeguard — the app hasn't been turned ON for their org unit yet under User access (step 8). Login fails immediately with no request ever reaching Safeguard (blank page, browser can't resolve/connect, or an unrelated 404) — the ACS URL in step 4 has a typo; re-copy it exactly from Safeguard's dialog rather than retyping it.