Assigning to Xiyuan for M52.

Many thanks, afakhry.

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

commit f20568fcd6d73c9468b359f2ccd043c257e3c53b
Author: afakhry <afakhry@chromium.org>
Date: Wed May 04 21:26:29 2016

Skip the SAML confirm password screen when a single password is scraped

When the SAML handler scrapes exactly a single password, we verify it and
complete the authentication and login. This shaves off one extra password
the user has to type.

BUG= 604309 
TEST=browser_tests --gtest_filter=(SamlTest|SAMLEnrollmentTest|SAMLPolicyTest).*
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:closure_compilation

Review-Url: https://codereview.chromium.org/1954453002
Cr-Commit-Position: refs/heads/master@{#391646}

[modify] https://crrev.com/f20568fcd6d73c9468b359f2ccd043c257e3c53b/chrome/browser/chromeos/login/saml/saml_browsertest.cc
[modify] https://crrev.com/f20568fcd6d73c9468b359f2ccd043c257e3c53b/chrome/browser/resources/gaia_auth_host/authenticator.js
[modify] https://crrev.com/f20568fcd6d73c9468b359f2ccd043c257e3c53b/chrome/browser/resources/gaia_auth_host/saml_handler.js

This should be fixed now. 

Deleted previous comment and re-attaching the reasoning.


Today
Detected password matches: We let the user in.
Detected password does not match: User is blocked on login screen.

So even today the user is blocked if we are somehow finding the wrong match in the detection flow. As this was never escalated in the field, we don't believe we have a single instance of this out there.


Suggested Minor Modification
When we detect exactly 1 password, we use it without getting any confirmation from the user. This would result in the following

Detected password matches: We let the user in. User is able to use lock and pod screen.
Detected password does not match: We let the user in. User is blocked at lock and pods screen.



Upside For all cases where N=1 (i.e. most cases), we shave off one extra password the user has to type.

Downside User used to be blocked on login screen. Now user is blocked at lock and pod screen. So the user is blocked either way.

Verified on R52	8344.0.0;52.0.2739.0, that if one password is scraped from the IdP screen , 

NOte: User cannot use the password to Unlock the device on the Lock screen or on the Cached User Signed pod screen. The user has to go through the Sign in flow again. 

On the Cached user Sign in pod if the wrong password is entered more that 4 times an online Signin is triggered. But on the Locked out screen if the wrong password is entered more than 4 times the online Sign in is not being triggered which could be very confusing to users. 
 

we are testing this here. I too can verify that the locked screen does not work. Only option is to restart or sign out. I would prefer saml sign in flow again

Re #13: This is a bug that has been fixed yesterday. The fix will be merged to M52 soon once verified.

Josh, can we get a confirmation from your side that this is working again on beta branch?