I can't judge what the problem is here. Is this an urgent customer ask?

Basically, it means a school / enterprise can't use Chrome devices with SSO *and* an SSL-inspecting web filter. Today, those are mutually exclusive.

Are we sure about that? We have north of 1000 schools using SSO, could it be that none of them are using SSL inspection as well?

I would need to get exact data on how many schools have SSO=true AND Use ONC-pushed cert as HTTPS CA=true. The hostname whitelist on our Help Center (https://support.google.com/chrome/a/answer/6334001?hl=en&ref_topic=3504941) does not specify exempting www.google.com from filtering, and that's the endpoint for SAML assertion. So if the SSL certificate / root CA for the web filter isn't available at the login screen, how can a www.google.com SAML assertion work?

It probably cannot. We want to do CAs on login screen for some other reasons. Let's better understand if this is indeed the case here.

I did test this and could find no way to do both Google search term inspection via SSL interception and Chrome OS SAML login.

The proper fix here in my opinion would to get the SAML ACS URL off www.google.com (use acs.google.com or such). Then customers can whitelist that domain without impacting Google search.

One alternative is to point the SAML assertion endpoint to https://accounts.google.com/a/domain.com/acs which has the same function as the ACS endpoint on https://www.google.com. However, accounts.google.com is exempt from SSL inspection based on the prescriptive advice in this Help Center article:
https://support.google.com/chrome/a/answer/6334001?hl=en&ref_topic=3504941

FYI filed internal bug 33378317 to see about fixing ACS url.

We would be happy to test in January if need be. Let us know.

Also is there another way to do Google search term inspection at the network-wide level other than SSL interception?

What is the latest on this bug? I do not see any comments past Dec. 21.

Just to +1 this issue, we at Clever operate a SAML IdP against Google for our Badges in to Chromebooks Login feature (see https://medium.com/@clever/logging-into-chromebooks-with-clever-badges-10d8ec3e4e73). We've seen several districts with transparent proxies unable to support Badges into Chromebooks without allowing all Google traffic (*.google.com).

I think that an alternate SAML endpoint hosted on a subdomain of Google (e.g. accounts.google.com, or acs.google.com) should help fix the issue and help several districts to use both Badges into Chromebooks and transparent-proxy-based web filters concurrently.

We have a 700 device deployment impacted by this.

We have the same problem here trying to use Clever badges and SSO.

FYI that this issue can now be worked around by POSTing SAML assertions to accounts.google.com instead of www.google.com as part of the SAML flow. I believe Clever has already implemented this workaround. Other IDPs like ADFS may or may not support replacing accounts.google.com automatically and we're working on a larger fix for them. If you are not the IDP developer, please reach out to the developer for help.

This bug has an owner, thus, it's been triaged. Changing status to "assigned".

Another user has been affected by this. For future users that are seeing this issue a whitelisting request will need to be filed with Support.