Project

General

Profile

Actions

Task #3342

closed

SSO tokens are preserved across browser sessions

Added by Guilhem Moulin about 4 years ago. Updated about 4 years ago.

Status:
Rejected
Priority:
High
Category:
Single Sign-On
Target version:
-
Start date:
Due date:
% Done:

0%

Tags:

Description

From André Littoz 's #3341:

I disconnected from the Discourse session by using the menu command associated with "avatar" at top right of screen (labeled Log Out). I was effectively disconnected but some token (cookie?) remained on my computer.

Next time I logged in, I did not need to enter manually my credentials as the token was automatically used (even if my computer was rebooted to make sure I started afresh).

Cookies set by the Single Sign-On system should be deleted when the current session ends. (I.e., expire and max-age attributes needs to be absent in the Set-Cookie header.)

Actions #1

Updated by Guilhem Moulin about 4 years ago

Looking at Set-Cookie header values I don't see any expire and max-age attributes. André Littoz , could it be that your browser doesn't delete so-called session cookies when you close it? Could you please open your browser (new session), visit https://auth.documentfoundation.org and authenticate, visit https://ask.libreoffice.org and authenticate (with username+password), then close your browser, restart it, and visit these two sites again. Are you pre-authenticated or do you land in an anonymous session?

Actions #2

Updated by André Littoz about 4 years ago

Recent versions of Firefox are not as convenient as older ones to examine cookies. You now need to be connected with the site to be able to dump them.

Is the site auth.documentation.org ?

EDIT OK, I figured out. I found "generic" cookies `.documentfoundation.org` plus specific "application" cookies`redmine.…` or `vm22.…`. I think the "critical" ones are those with name `lemonldap` and an apparently random hashed name, both in the "generic" domain and same for all applications. They have Session, HttpOnly and Secure attributes.

I'm beginning to suspect my problem is related to my workflow.

Actions #3

Updated by Guilhem Moulin about 4 years ago

André Littoz wrote:

I'm beginning to suspect my problem is related to my workflow.

Please try the experiment suggested earlier so we can confirm. :-)

Actions #4

Updated by André Littoz about 4 years ago

I confirm that after a full shutdown and restart (not a simple reboot), I still don't need to enter my credentials to log in.

Pressing the login link is enough to connect to Discourse and Redmine.

This means some information is persistent on my computer.

Actions #5

Updated by Guilhem Moulin about 4 years ago

André Littoz wrote:

Pressing the login link is enough to connect to Discourse and Redmine.

These two rely on the Single Sign-On portal (and the same auth protocol) for authentication. Please also check with AskBot (using username+password authentication not OAuth/OpenID) to confirm it's not an issue with our SSO system.

Actions #6

Updated by André Littoz about 4 years ago

AskLO signin with password

No persistent data. After sign-out, I must retype userid/password.

AskLO signin with Google

A click on this icon suffices to be connected. Some persistent data is kept somewhere.

Actions #7

Updated by Guilhem Moulin about 4 years ago

André Littoz wrote:

AskLO signin with password

No persistent data. After sign-out, I must retype userid/password.

Yes of course, but that's not what I was interested in. Quoting msg#1 of the present issue:

Guilhem Moulin wrote:

Could you please open your browser (new session), visit https://auth.documentfoundation.org and authenticate, visit https://ask.libreoffice.org and authenticate (with username+password), then close your browser, restart it, and visit these two sites again. Are you pre-authenticated or do you land in an anonymous session?

So do not log out. Just log in to these sites, close your browser, and start it again please (better not click the “restart” button as it might not completely flush the state).

Actions #8

Updated by Guilhem Moulin about 4 years ago

FWIW it appears AskBot doesn't set session cookies but cookies with a 1 year resp. 14 days lifetime.

$ curl -so/dev/null -D- https://ask.libreoffice.org/en/account/signin/ | grep -i ^Set-Cookie:
set-cookie: ask.libreoffice.org_en_csrf=…; Domain=ask.libreoffice.org; expires=Thu, 02-Sep-2021 20:35:33 GMT; Max-Age=31449600; Path=/
set-cookie: libo-session-pt-br=…; Domain=ask.libreoffice.org; expires=Thu, 17-Sep-2020 20:35:33 GMT; httponly; Max-Age=1209600; Path=/

I'm not familiar enough with the AskBot authentication mechanism to comment on that. OTOH the Single Sign-On portal sets session cookies, and if your browser doesn't delete them when you close it I'm not sure what we can do about that.

André Littoz wrote:

AskLO signin with Google

A click on this icon suffices to be connected. Some persistent data is kept somewhere.

I read the exact opposite at https://vm222.documentfoundation.org/t/custom-log-in-control/115/8 . AFAICT the above 1/ suggests that your browser indeed doesn't close session cookies when you close it; and 2/ the log-out button doesn't act as a single sign-out (which TBH would be rather strange for a third-party Identity Provider).

Actions #9

Updated by André Littoz about 4 years ago

Before making the experiment as precisely described in comments #1 and #7, more information:

I used my laptop to connect to Discourse. Behaviour is totally different. Everything goes as expected. After logout and browser close, credentials are requested anew.

The main difference between my laptop and my desktop is my laptop has not been updated for months (because I want to backup safely works I did on it years ago and make sure data is accepted in newer versions of applications on my desktop; until I'm confident I won't lose data, the laptop is "frozen").

OS (Linux too) is lagging many releases behind my desktop. Firefox is an outdated version.

I disapprove directions taken by Mozilla security-wise. In latest Firefox versions, you can no longer set your own cookie acceptance and lifespan policy. Cookies are always stored and trying to mitigate that is quite cumbersome, needing to explore the local sites store. And even here, you can't selectively delete cookies, you can only enable or disable sites as a whole.

Considering the difference between my laptop and desktop, I think browser configuration/behaviour plays a role in the issue.

Actions #10

Updated by André Littoz about 4 years ago

Trial protocol as requested

Preparatory phase

I went to auth.documentationfoundation.org to logout. Took me several attempts to be really logged out.

Closed browser

Experiment

- open browser
- access auth.documentationfoundation.org to authenticate (leave tab open)
- access ask.libreoffice.org and log in with userid/password (leave tab open)
- close browser
- open browser
- both tabs are restored and show that I'm connected (auth page displays the password change form and AskLO the usual question list)

Technical details

- kernel Linux 5.8.4
- desktop KDE Plasma 5.18.5
- Firefox 80.0.1

Actions #11

Updated by Guilhem Moulin about 4 years ago

Thanks for trying! Based on this I'm tempted to close this as “can't fix”: I don't see what we can do on our end to fix this, but if you know of a cookie attribute to force deletion when the browser closes let us know :-)

Last quick experiment, does the same thing happens if you close the browser by closing all tabs successively?

(For AskBot this is not too surprising since it doesn't set session coookies, however for the the SSO portal the situation is different.)

Actions #12

Updated by André Littoz about 4 years ago

Last experiment

  • log out from documentfoundation.org with explicit argument ?logout=1 (from bookmarks)
  • close browser
  • open browser
  • new tab to auth.…, authenticate
  • new tab to ask.libreoffice.org, log in with userid/password (not through OpenID)
  • close auth tab
  • close ask tab
  • close browser
  • open browser
  • new tab to auth, screen displays page to change password (hence already logged in)
  • new tab to ask, already logged in

Don't close the ticket for the moment. I'll install a VM with basic configuration when I have time. I want to make sure that nothing in my daily configuration is causing the problem.

Meanwhile, I've bookmarked the full sign out URL and this is an acceptable workaround.

Side remark:

For several weeks now, it has been impossible to login into AskLO with Yahoo!. I must use either Google (which I don't like) or userid/password. It already happened in the past and was fixed. Can you do something about that?

Actions #13

Updated by Guilhem Moulin about 4 years ago

  • Status changed from New to Rejected

André Littoz wrote:

Last experiment
I'll install a VM with basic configuration when I have time. I want to make sure that nothing in my daily configuration is causing the problem.

An intermediate step would be to try with a throw-away profile (and disabling all extensions to be sure). I ran MOZILLA_DISABLE_PLUGINS=y firefox-esr -no-remote -Ptransient-rdm3342. This is with Firefox 68 ESR on Debian sid, dunno if some of this is Debian-specific or not.

  • Visit about:addons, disable all extensions, close the tab to close the browser.
  • Start the browser using the same command, open https://auth.documentfoundation.org , authenticate, and close the tab (without logout) to close the browser.
  • Start the browser using the same command, open https://auth.documentfoundation.org . I land on the authentication page (“Authentication required”) so the session did not survive the browser restart.

With Chromium 83 on the same system, started with chromium --user-data-dir="$XDG_RUNTIME_DIR/transient-chromium-rdm3342". ("$XDG_RUNTIME_DIR/transient-chromium-rdm3342" is initially inexistent.)

  • Visit chrome://extensions/, disable all extensions, close the tab to close browser.
  • Start the browser using the same command, open https://auth.documentfoundation.org , authenticate, and close the tab (without logout) to close the browser.
  • Start the browser using the same command, open https://auth.documentfoundation.org . I land on the authentication page (“Authentication required”) so the session did not survive the browser restart.

Closing this for now, will reopen if needs be.

Side remark:

For several weeks now, it has been impossible to login into AskLO with Yahoo!.

This would warrant a separate ticket :-P Note also that https://ask.libreoffice.org is normally managed by upstream not the infra team.

Actions

Also available in: Atom PDF