please take a look

Ligi, cold you please try to repro and bisect if possible. Thank you.

This is affecting thousands of our users daily. Any closer to finding a fix for this? The only temporary fix is to wipe out their Chrome profile (which will also force them to reconfigure any extension that stores it's settings locally). Not a solution at all. 

This is affecting thousands of our users daily. Any closer to finding a fix for this? The only temporary fix is to wipe out their Chrome profile (which will also force them to reconfigure any extension that stores it's settings locally). Not a solution at all. 

@Ligi, Could you please try to repro and bisect if possible 

We don't have a third party trusted IdP configuration setup for triaging the issue.

Looping to few enterprise experts who can chime in for further updates.

Note: Please tag enterprise related issues with Components:Enterprise, which will be monitored on a daily basis.

@ligi, 
I have sent a set of test third party IdP credentials to you via email. 
You could use those to try to repro this bug, lemme know if you have any questions. 

Reproduced it QD5 on windows and mac also using idp:  https://saml-sso-rsa.appspot.com/
video: https://drive.google.com/open?id=0B-g52zibXA02ajJnbTNoUWpDU1U

Steps: 
1. configure SSO on domain.
2. In chrome go to Manage people, add person.
3. Log in, click on mail link, everything works.
4. Log out mail (not from people), close browser.
5. Open browser again, log in again, close browser.
6. Open browser
Expected to be automatically logged-in here, but it asks for sso login each time.

Workaround (refused by customer) -- in page settings "set  where you left off".

No issue on non-sso domain.

Able to reproduce the issue on the latest stable(58.0.3029.110) and the latest canary(60.0.3100.0) on Windows-10, Mac OS 10.12.4 and Linux Ubuntu 14.04.

This is non-regression issue seeing the similar behavior on older chrome version(35.0.1868.0) as well.(screen-cast attached)

Test steps followed:

1. Launched Chrome and signed into chrome using SSO credential.
2. Once signed into chrome, went to gmail and signed out of that. Exit Chrome.
3. Relaunched Chrome and observed Gmail is signed out(working as intended).
4. Signed into Gmail which auto signs into Drive and other Google Apps. Exit Chrome again.
5. Launched Chrome and observed Gmail/Drive are signed out even when these were signed in before browser exit at step-4.(Bug)

Deleted: 709477.mp4 5.0 MB

	709477.mp4 5.0 MB View Download

Reproduced on old versions as well, like 48, 55, 56

HAving this issue also.  For an enterprise not a good thing for our users.

In the video of the original post, I see that the "remember me" check box is left blank on the okta sign in page.  What happens if that is checked?

Original post also says: "Policy to keep cookies for the duration of the session is not set."  Could this have been turned off locally?  This can be checked at:

chrome://settings/content/cookies

What is the value of "Keep local data only until you quit your browsers"?

Is it possible chrome is crashing on shutdown?  This might not be evident since the user is closing chrome anyway.  Go to chrome://crashes/ and check the date/time of the most recent crash, if any.

rogerta@, I've tried with that option checked, and the settings have not been turned OFF locally, I tried with 2 different test SSO accounts (different IdP, one is OKTA, and the other one is a local one running with SimpleSAML PHP). Currently I only have access to 1 test account with OKTA, but I can provide more details if needed.

Chrome has not crashed. On my side, I've tried in 2 different OS, Windows Server 2008 R2 and Windows 7 pro 64 bit. I'll gather the details you requested and update the thread here.

Marking as archived since there have been no further reports in past few releases. Please comment if you are still seeing this.

Going back to this bug, have another use case (a little different, for ChromeOS chromebooks now), if needed will create a separate bug, so steps are:

1. Setup any SSO (I used microsoft azure, have customers used adfs).
2. In Device Management->Chrome Management->Device Settings enable "Allow users to go directly to SMAL SSO IdP page", "Enable transfer of SAML SSO Cookies into user session during login".
3. On chromebook startup, add non-admin user (sso is disabled for admins), it redirects to SAML IdP page interface, asks for SSO password and successfully adds a user.
4. Open in browser SAML SSO IdP page (login.microsoftonline.com in our use case), page opens without asking login and password.
5 Power off, power on, login (it uses google interface already, but accepts SSO password, it's also expected).
4. Open in browser SAML SSO IdP page again (login.microsoftonline.com in our use case).

Expected: Page opens like in step 4 without asking password.
Actual: SAML SSO IdP page asks for a password after reboot.

Workaround, same as in windows/macos use cases -- In user's local browser configuration set "Continue where you left off" on startup.

rogerta@, please help to triage.

+xiyuan@

It is hard for me to parse this bug - is this ChromeOS only or is this still happening on desktop?

This would help us triage - if this is desktop then I should take it, otherwise it should be assigned to xiyuan@.

for comment #18, It's chrome OS only as it's specific to the way chrome os transfer sso cookies to user seesions, XiYuan can you please help with this?

When we transfer SAML IdP cookies from sign-in profile into user profile. We copy it as-is without any change. [1]

So this sounds like the IdP issues session cookies that are lost after browser shuts down. Can we check whether that is the case here? e.g. use a tab to login the IdP, then close the browser (make sure the browser process exits), then visit the IdP page again to see whether it is still signed-in or not.

[1]: https://cs.chromium.org/chromium/src/chrome/browser/chromeos/login/profile_auth_data.cc?rcl=e535de89cb7f32fe90da6039b399d7716368af6f&l=41

re: #24
It is still signed-in while opening and closing the browser. 

It only keeps IdP sign-in only once, when created a user and signed-in to chromebook for first time (#18, step 4), all other times it always lost signing-in to Idp (but still always remains signed-in to google services, e.g gmail, drive, etc) when signing-out and signing-in chromebook with or without reboot.

WAI, many IdPs are using session cookies, so they are not stored when user logs off.