Skip to main content

Set up Enterprise SSO with Google Workspace

This guide connects Google Workspace to Devs.ai using SAML 2.0, with Google acting as your identity provider. When you are done, anyone with an email address at your domain signs in with their Google work account instead of a Devs.ai password.

📝 Note: Enterprise SSO is an enterprise feature and is not enabled by default. To turn it on for your organization, reach out to your Devs.ai representative.

📝 Not the same as "Sign in with Google": This is a full SAML connection managed by your Workspace administrators, with domain-based routing and centrally controlled access. It is different from a member choosing Google as a personal sign-in option.

You will need: edit access to Organization Settings in Devs.ai, a Google Workspace super administrator account, and the list of email domains to route through Google. See the overview for the full prerequisites.

Step 1 — Create the connection in Devs.ai​

  1. Go to Organization Settings and select Enterprise SSO (https://devs.ai/org-enterprise-sso).
  2. Select Add Connection.
  3. Enter a Connection Name, for example Google Workspace SSO.
  4. Set Identity Provider to Google Workspace. This cannot be changed later.
  5. Under Domains, add each email domain you want routed through Google, for example acme.com. Press Enter or type a comma after each one.
  6. Leave the identity provider fields empty for now — you will fill them in at Step 5 — and select Create Connection.

Step 2 — Copy the service provider values​

Open the connection you just created and find the Service Provider Configuration section. Copy these two values; each has a copy button:

  • ACS URL
  • SP Entity ID

Keep this page open in a second tab.

Step 3 — Create the custom SAML app in Google​

  1. In the Google Admin console, go to Menu → Apps → Web and mobile apps.
  2. Select Add app → Add custom SAML app.
  3. Enter an App name, for example Devs.ai. Optionally upload an icon, then select Continue.
  4. On the Google Identity Provider details page, select Download metadata and save the XML file. You will upload it to Devs.ai in Step 5. Select Continue.
  5. On the Service Provider Details page, enter:
Google fieldValue
ACS URLThe ACS URL from Step 2
Entity IDThe SP Entity ID from Step 2
Name ID formatEMAIL
Name IDBasic Information → Primary email

Leave Start URL empty. Select Continue.

  1. On the Attributes page, select Add mapping once per row and create these four mappings. The app attribute names must match exactly — they are the claim names Devs.ai expects by default.
Google directory attributeApp attribute
Basic Information → Primary emailmail
Basic Information → Primary emailid
Basic Information → First namefirstName
Basic Information → Last namelastName

Google's custom SAML wizard does not expose an internal directory identifier, so mapping Primary email to id is the usual pattern. If your organization populates Employee ID for every user, you can map that to id instead for an identifier that survives an email change.

  1. Select Finish.

Step 4 — Turn the app on for your users​

In the Google Admin console, open your new SAML app and set User access to ON for everyone, or turn it on for the specific organizational units or groups that should have access. Anyone the app is off for cannot sign in, even if their email domain matches your connection.

Google notes that access changes can take up to 24 hours to propagate, though they are usually much faster.

Step 5 — Send the Google details back to Devs.ai​

Google provides its metadata as a downloadable file rather than a hosted URL, so use the XML upload:

  1. On the Devs.ai connection page, under Identity Provider Configuration, find Federation Metadata XML.
  2. Select Upload file and choose the metadata XML you downloaded in Step 3.
  3. Select Save Changes.

If you prefer to enter the values manually, select Use manual configuration and take these from the Google Identity Provider details page — you can reopen it from the app's Service provider details screen:

Devs.ai fieldGoogle value
Login URLSSO URL
IssuerEntity ID
Certificate (Base64)Certificate — download it from Google and use Upload file

Step 6 — Test and enable​

  1. On the Devs.ai connection page, confirm the header shows the Active badge. If it shows Inactive, select Enable.
  2. Have one administrator sign out and sign back in with their work email address. They should be redirected to Google.
  3. After signing in, check that their name and email are correct in Devs.ai. If a name is missing, revisit the attribute mappings in Step 3.
  4. Once the test passes, announce the change and roll out to the rest of your organization.

Google-specific troubleshooting​

"App not found" or Google says the app is not enabled for the user The SAML app is off for that user's organizational unit. Turn it on under User access, then wait for the change to propagate.

Google rejects the ACS URL Google requires the ACS URL to start with https://. Copy it again from the connection page with the copy button rather than retyping it.

Sign-in works but names are missing The attribute mappings were not saved, or the app attribute names do not match. Reopen Attribute mapping in Google and confirm mail, id, firstName, and lastName are all present, spelled exactly that way. Names are case-sensitive.

A member's email address does not match their Devs.ai account Google sends the primary email address. If members use an alias to sign in elsewhere, they still need to use their Google primary email here.

Sign-in broke after rotating the Google certificate If you configured the connection manually, upload the new certificate to Certificate (Base64). If you used the metadata XML, download the new metadata from Google and upload it again — a file upload is a snapshot, so it does not update on its own.

⌘J