<!-- llms-explorer concept facts · https://llms-explorer.com/tree/google-workspace-saml-federation/ · pack 2026-10-23 · ~1359 tokens -->

# Google Workspace SAML Federation

> Source-anchored research for Google Workspace SAML Federation. Run status: COMPLETED.

Parent: [MongoDB Atlas on GCP](https://llms-explorer.com/tree/mongodb-atlas-on-gcp/) · 4 facets · 16 facts · page: https://llms-explorer.com/tree/google-workspace-saml-federation/

## How-to and procedures

- Configure a custom SAML app in Google Admin. Exchange Google SSO URL, Entity ID and signing certificate for Atlas ACS URL and Audience URI; Atlas supplies the Start/Login URL. (high confidence) — [source](https://www.mongodb.com/docs/atlas/security/federated-auth-google-ws.md)
- Enable the SAML app for everyone or selected organizational units/access groups, and test the login flow. App assignment is a separate setup step from creating the SAML metadata. (high confidence) — [source](https://www.mongodb.com/docs/atlas/security/federated-auth-google-ws.md)
- Enable Signed Response for the Atlas custom app. Google otherwise signs only the assertion by default, while the MongoDB setup explicitly requires a signed response. (high confidence) — [source](https://www.mongodb.com/docs/atlas/security/federated-auth-google-ws.md)

## Problems, failure modes and limitations

- Google documents a maximum of 75 groups in a custom SAML app group-membership mapping. This is a Google app configuration limit, not evidence of an Atlas-wide group limit. (low confidence) (verified as of 2026-10-22) — [source](https://knowledge.workspace.google.com/admin/apps/set-up-your-own-custom-saml-app)

## Comparisons and alternatives

- StrongDM describes its G Suite SSO–MongoDB Atlas connection as a custom StrongDM integration for unified access. Its page is evidence for an intermediary access product, rather than instructions for configuring native Atlas SAML federation. (low confidence) — [source](https://www.strongdm.com/connect/g-suite-sso-mongodb-atlas)

## Facts and statements

- Google Workspace can act as the SAML identity provider for Atlas UI access, letting assigned users sign in with corporate credentials; this configuration does not itself establish database authentication. (high confidence) — [source](https://www.mongodb.com/docs/atlas/security/federated-auth-google-ws.md)
- MongoDB specifies HTTP POST request binding, SHA-256 response signature algorithm, Signed Response enabled, Name ID format UNSPECIFIED and Primary Email as Name ID for the Workspace integration. (low confidence) — [source](https://www.mongodb.com/docs/atlas/security/federated-auth-google-ws.md)
- Map Google first and last name fields to case-sensitive firstName and lastName. A Workspace user reported that missing these mappings caused new-user SSO failures at okta/hooks/acserror even while existing users could log in. (medium confidence) — [source](https://www.mongodb.com/docs/atlas/security/federated-auth-google-ws.md)
- Optional Atlas role mapping uses a single Google group-membership mapping row containing all selected groups and the app attribute memberOf. Google includes only the selected groups to which the user belongs, directly or indirectly. (high confidence) — [source](https://www.mongodb.com/docs/atlas/security/federated-auth-google-ws.md)
- Verify and associate an email domain in Atlas to route matching sign-ins to Google Workspace. If multiple SAML identity providers share that domain, MongoDB says the cloud console routes to the first configured one; use a specific SP- or IdP-initiated URL for an alternative. (low confidence) — [source](https://www.mongodb.com/docs/atlas/security/federated-auth-google-ws.md)
- Before testing domain routing, MongoDB recommends saving the Bypass SAML Mode URL, retaining the Federation Management Console session, and testing in a private browser window. (low confidence) — [source](https://www.mongodb.com/docs/atlas/security/federated-auth-google-ws.md)
- MongoDB documents Google Workspace as a SAML identity provider for signing in to Atlas and other MongoDB cloud services; Google supports custom SAML applications using managed Google Account credentials. (high confidence) — [source](https://www.mongodb.com/docs/atlas/security/federated-auth-google-ws.md)
- MongoDB specifies HTTP POST binding and SHA-256, Name ID format UNSPECIFIED with Primary Email, and case-sensitive firstName and lastName attribute mappings. (low confidence) — [source](https://www.mongodb.com/docs/atlas/security/federated-auth-google-ws.md)
- Users need the Google SAML application enabled for them. Google supports enabling access for everyone, organizational units or access groups; its guide also requires matching sign-in email addresses. (high confidence) — [source](https://www.mongodb.com/docs/atlas/security/federated-auth-google-ws.md)
- Apono advertises Google Workspace-driven granular permissions and access-request workflows as capabilities of connecting Apono with Google Workspace. That page does not establish equivalent native Atlas SAML database-permission automation. (low confidence) — [source](https://www.apono.io/wiki/connecting-idps-with-databases/google-workspace/connect-google-workspace-with-mongo-atlas/)
- Google requires a super administrator for the documented custom SAML app setup. MongoDB separately requires Atlas Organization Owner access and describes the Google prerequisite more broadly as administrative privileges. (medium confidence) — [source](https://www.mongodb.com/docs/atlas/security/federated-auth-google-ws.md)
