A very simple fix. Uploading CL now

Steps To Reproduce:
(1) Set the LoginAuthenticationBehavior=1 in the DM server to which the test chrome device is enrolled to.
(2) Click on Add a user and add a user.
(3) Sign out and attempt to add another user

Expected Result:
The SAML interstitial should be displayed. Even if a user pod or Public session pod preexists on the login screen.

Actual Result:
The SAML interstitial is not displayed.
The Gaia frame is black and displays the Spinner of death instead.

How frequently does this problem reproduce? (Always, sometimes, hard to
reproduce?)
Always

What is the impact to the user, and is there a workaround? If so, what is
it?
Users will not be able to sign into the device if there's a public sessions pod (or another user pod)  on the Sign in screen

Please provide any additional information below. Attach a screen shot or
log if possible.

I'll put the fix in the same CL of the browser tests.

I also hit a screen yesterday which comes up after you enter a wrong password for 4 consecutive times. It takes you back to an online login. Can we please ensure this is covered by our tests (manual or automated).

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/d63c2d5efb5b8cfd94e910ee3049b1faa3cd30c8

commit d63c2d5efb5b8cfd94e910ee3049b1faa3cd30c8
Author: afakhry <afakhry@chromium.org>
Date: Sat Apr 02 00:07:51 2016

Fix SAML Interstitial not shown when pre-existing user pod exists

This was due to a condition that always evaluated to false, when the
gaia signin in screen has been previously loaded.

BUG= 599723 

Review URL: https://codereview.chromium.org/1845243006

Cr-Commit-Position: refs/heads/master@{#384745}

[modify] https://crrev.com/d63c2d5efb5b8cfd94e910ee3049b1faa3cd30c8/chrome/browser/resources/chromeos/login/screen_gaia_signin.js

Can we please verify that this also works for the case when the password is entered multiple times wrong and that sends the user back to the online login flow?

That flow is slightly different from the "Add person" button in the regular case as it takes the user not to the "Enter email" page, but rather directly to the "Enter password" page. I'm not sure it will make the proper redirection in the SAML case.

I actually have not tried that scenario with a saml user. I doubt that we go directly to password phase for saml users. Can anyone give it a try with a build before the saml interstitial page changes? We might be landing user in Gaia with email pre-filled or show saml idp.

What is the expected behavior with saml interstitial? We probably should skip it and go directly to saml idp.

Just tried it. Sends user directly to SAML page which makes sense because that's the page that comes after email entry.

This should behave the same with the interstitial change i.e. directly to SAML page since we know who the user is.


The real question is what happens if when we land on that page, we authenticate with another user... This is the gap in the current SAML implementation that the email address Google provides the IdP is irrelevant. What would come at the end is an assertion for User B trying to unlock a pod for User A. Xiyuan, any idea what would happen in this case?

Just tried that scenairo as well. It ends up adding a new user instead of unlocking the old one :-)

Good we don't have a massive security hole to worry about!!

Yep, we don't rely on the user email typed in and always uses the email that Gaia returns to us.

Verified on 8172.5.0;51.0.2704.15 that SSO authentication via the SAML interstitial works even when pre-existing user pod exists on the SIgn in Screen. (user pod or Public Session pd)