Super Administrators cannot log into any Google Services using Okta Single Sign-on.

• Okta Integration Network (OIN)
• Google Workspace SAML Integration
• Single Sign-On (SSO)

The recent Google Workspace update that transitioned from a Legacy SSO profile to newer SSO profiles has introduced a limitation where Single Sign-On is not supported for Super Administrators. This is because the SAML assertions for Super Administrators are not redirected to Okta.

Admins can still enable Super Administrators to access Google services via SSO using the Legacy SSO profile. For this to work as intended, the following conditions must be met:

1. The RPID value in Okta should be left blank.

NOTE: Leaving the RPID field empty ensures that users can only authenticate using the IdP-initiated flow and it comes with a significant caution: this change can break the SSO functionality for every user that is currently managed by the Google Workspace SSO Profile corresponding to the RPID removed.

To prevent this disruption and ensure seamless access for all users, the best solution involves setting up two separate Google Workspace applications:

• • Application 1: For Super Administrators
    • This application can be a new integration that should have the RPID field left empty.
    • It will be connected to the Legacy SSO Profile. This setup ensures that Super Administrators can still authenticate without issue, using the IdP-initiated flow.
  • Application 2: For All Other Users
    • This application can be the existing one and will use an RPID value.
    • This RPID value should be taken from a separate SSO profile within Google Workspace. This distinct profile will apply to all users except Super Administrators, maintaining their SSO functionality without conflict.

This dual-application approach allows the desired IdP-initiated flow for Super Administrators while preserving the existing SSO experience for the general user base.

2. The Legacy SSO Profile should be enabled under Third-party SSO profiles.
3. 1. To do so, go into Security > Authentication > SSO with third-party IdP, then select the Legacy SSO profile option and check the box that reads Enable legacy SSO profile.

Once this is enabled, assign the SSO profile to the organizational units or groups where the Super Administrators are.

3. Verify that the domain-specific Service URL's setting is configured to redirect users to the third-party IDP automatically.
4. Ensure that the Super Administrator initiates their sign-in process through the IdP that is, via the Okta dashboard and not directly through accounts.google.com.
5. If a super administrator initially signs in to Google using a non-super administrator account and then authenticates with their super-administrator credentials when redirected to Okta, Google will accept the super admin identity assertion from the IdP.

NOTE: Even when using the legacy SSO profile, Super Administrators cannot sign in with SSO in the following scenarios:

• When signing in to an SSO-enabled domain directly via admin.google.com.
  • In this case, the admin will be prompted to use their Google Workspace credentials (not SSO username and password) and will not be redirected to Okta.
• When signing in to the Google Drive synchronization client.
  • In this case, the admin will bypass SSO, regardless of the device or browser being used.

Related References

• Google: Signing in with SSO