dskaram@, you've been working on ChromeOS login recently - can you please route/investigate?

Interesting use case. Thanks for filing the bug.

What happens if the next user wants to go somewhere else? Does the IdP provide a way to go back and choose something else? Do you have a high level of sharing in your environment that students are switching Chromebooks all the time?


Would appreciate some more examples of IdP finders as that's the first time I come across this. Thanks!

An IDP finder (or IDP discovery service) as two primary use cases, it is common to store a cookie to remember the selection in both cases

UC1: Standard Service Provider (SP) needs to know what Identity Provider (IDP) to redirect a user to.  Google uses this on their login pages.  When you type in your email, it filters the domain in the address to determine if SSO is enabled for that domain.  It then redirects the user to the "Sign in URL" (IDP) in that domain's configuration.

UC2: SAML / Federation Proxy.  A SAML proxy (our use case) takes place in the flow after UC1.  A user is redirected to the SAML Proxy after Google's IDP Finder determines where to send the user.  In the case of a SAML proxy there are generally multiple IDP's behind it so an IDP finder (discovery) process is required again.  It is also common to store a cookie so that users do not have to make that selection every time.

The process for IDP discovery its self varies, but the one thing that exists in almost all cases is storing a cookies so the user does not have to select it every time.

In the case you mention with a user wanting to change their selection.  It is up to the IDP finder service to handle that or not.  In our case we do not have that option, because it is generally required in our use cases.  I have seen other IDP Finder services that do have a button on the login screen to go back to the selection screen to change your setting.

Our specifics:
we are a an agency that supports many k12 school districts.  Each one has their own IDP behind our proxy.  We call our IDP Finder our "District Selection Page".  We have roughly 6000 chromebooks we manage and see the adoption roughly doubling annually.  We also find that roughly %50 percent of our chrome devices are used in labs and or "mobile labs".  Meaning they push a cart full of chromebooks into a classroom and pass them out for use for the period / day/ week.  The other %50 is generally used in High School as part of a 1 to 1 initiative where each user has their own device.  All that said in our use cases chromebooks are generally shared within a district so other than in case of error users will not change the district.  If there is an edge case that requires it, we would simple reset the chrome device back to defaults or need the ability to clear the cookies somehow. 

As the product owner for our SSO service, overall the most re-occuring feedback we receive from end users is "Why do I have to select my district every time on a chromebook".  We also realize that storing local profiles (probably not the correct term) can alleviate this issue.  with many users sharing devices, the number of users to select from on the chromebook grows very quickly and becomes difficult for users or fill up to maximum.

As an aside and might be worth noting, cookies are stored in Android / IOS devices when authenticating to google accounts via SSO.  When adding a second account our cookie is preserved.

Rescources:
Two descriptions of IDP discovery services and what they do from a couple different vendors.  This applies to both UC1 and UC2.
https://documentation.pingidentity.com/display/PF610/IdP+Discovery
https://wiki.shibboleth.net/confluence/display/CONCEPT/IdPDiscovery

Reach out to me via e-mail if you would like some real world examples of UC2 (IDP Proxy with IDP finder).  I can provide both urls / public key certificates to test and reproduce.  I can also provide test user accounts if needed.