Migrating from legacy SSO to SSO profiles

Google Workspace offers two ways to set up Single Sign-On (SSO) with Google as a Relying Party to your Identity Provider:

Legacy SSO profile — Allows you to configure only one IdP for your organization.
SSO profiles — The newer, recommended way to set up SSO. Lets you apply different SSO settings to different users in your organization, supports both SAML and OIDC, has more modern APIs, and will be Google's focus for new features.

We advise all customers to migrate to SSO profiles to take advantage of these benefits. SSO profiles can coexist with the SSO profile for your organization, so you can test new SSO profiles before transitioning your whole organization.

Overview of the migration process

In the Admin console, create an SSO profile for your IdP and register the new profile with your IdP.
Assign test users to use the new profile to confirm that it works.
Assign your top organizational unit to the new profile.
Update domain-specific URLs to use the new profile.
Clean up: unregister your old Service provider, verify that automatic user provisioning still works.

Step 1: Create an SSO profile

Follow these steps to create a new SAML SSO profile. Your new profile should use the same IdP as your existing SSO profile for your organization.
Register the new SSO profile with your IdP as a new Service Provider.
Your IdP will see the new profile as a distinct Service Provider (it may call these "Apps" or "Relying Parties"). How you register the new Service Provider will vary with your IdP, but it typically requires configuring the Entity ID and Assertion Consumer Service (ACS) URL for the new profile.

Notes for API users

If you use the SSO profile for your organization, you can only use the Google Workspace Admin Settings API to manage SSO settings.
The Cloud Identity API can manage SSO profiles as inboundSamlSsoProfiles, and assign them to groups or organizational units using inboundSsoAssignments.

Differences between SSO profiles and the legacy SSO profile

Super admin assertions

SSO profiles don't accept assertions about superadmins. When using the SSO profile for your organization, assertions are accepted, but super admins are not redirected to the IdP. For example, the following assertions would be accepted:

The user follows an app-launcher link from your IdP (IdP-initiated SAML)
The user navigates to a domain-specific service URL (for example, https://drive.google.com/a/your_domain.com)
The user signs in to a Chromebook configured to navigate directly to your IdP. Learn more.

Post-SSO verification settings

Settings which control post-SSO verification (such as login challenges or 2-Step Verification) are different for SSO profiles than for the SSO profile for your organization. To avoid confusion, we recommend setting both settings to the same value. Learn more.

Step 2: Assign test users to the profile

It's a good idea to initially test your new SSO profile on users in a single group or organizational unit before switching over all users. Use an existing group or organizational unit, or create a new one as needed.

If you have managed ChromeOS devices, we recommend organizational unit-based testing, as you can assign ChromeOS devices to organizational units, but not to groups.

(Optional) Create a new organizational unit or configuration group and assign test users to it.
Follow these steps to assign users to the new SSO profile.

Notes for organizations with managed ChromeOS devices

If you've configured SSO for ChromeOS devices so that users navigate directly to your IdP, you'll want to test SSO behavior separately for these users.

Note that for sign-in to succeed, the SSO profile assigned to the device's organizational unit must match the SSO profile assigned to the device user's organizational unit.

For example if you currently have a Sales organizational unit for employees who use managed Chromebooks and sign in directly to your IdP, create an organizational unit such as "sales_sso_testing", assign it to use the new profile, and move some users and the Chromebooks they use into that organizational unit.

Step 3: Assign your top organizational unit and update service URLs

After successfully testing the new SSO profile on a test group or organizational unit, you're ready to switch other users.

Go to SecuritySSO with third-party IDPsManage SSO profile assignments.
Click Manage.
Select your top-level organizational unit and assign it to the new SSO profile.
(Optional) If other organizational units or groups are assigned to the SSO profile for your organization, assign those to the new SSO profile.

Step 4: Update domain-specific URLs

If your organization uses domain-specific URLs (for example, https://mail.google.com/a/your_domain.com), update that setting to use the new SSO profile:

Go to SecuritySSO with third-party IDPsDomain-specific service URLs.
Under Automatically redirect users to the third-party IdP in the following SSO profile, select the new SSO profile from the dropdown list.

Step 5: Clean up

At SecuritySSO with third-party IDPsSSO profiles, click the Legacy SSO profile to open profile settings.
Uncheck Enable legacy SSO profile to disable the legacy profile.
Confirm that automatic user provisioning set up with your IdP functions correctly with your new SSO profile.
Unregister the old Service Provider from your IdP.

Was this helpful?

How can we improve it?