Automatic start of authentication workflow for link provider (if it's the only available one)
Open, Needs TriagePublic


Consider the following scenario:
A wiki sysadmin disables all authentication providers except one. This last available provider is a so called "Link provider", which needs to redirect the user to another, external authentication page, e.g. Google. Now, while the login form could probably look something like:

The sysadmin would maybe want to bypass this confusing and nearly useless form and start the authentication workflow right after the user clicks the "Login" button (in the top right section of the page), or navigates to Special:UserLogin. Renaming the message key used for the login link could indicate, that it will return the user to an external site (e.g. renaming it to "Login with Google").

For this, the UserLogin page would need to check, if there's only one available primary authentication provider and if it's a link provider, that needs a redirect to an external site. It also should be configurable with a feature flag (defaults to false, means disabled).

GoogleLogin provided a similar function in an earlier version (before AuthManager) with the following implementation:

  1. User clicks the link in the top right, which redirects to Special:GoogleLogin
  2. Special:GoogleLogin starts the users session (this would, for AuthManager mean to start an authentication workflow?)
  3. Try to get the user data from Google (will fail, as there's no valid access token)
  4. Redirect the user to Google to authenticate
  5. Redirect back to Special:GoogleLogin -> anything else is the same as if this feature would be disabled

Can we implement such a feature into the AuthManager UI? :)

Florian created this task.Jul 27 2016, 7:17 PM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptJul 27 2016, 7:17 PM
Tgr added a comment.Jul 27 2016, 7:34 PM

I had some plans to turn GET into POST when the CSRF token is present and then ran into difficulties (which I don't quite remember anymore). The old code is at line 200.

"link provider" is not accurate here. For example, a generic OpenID-based link provider might need the user to select which of several OpenID services to link to.

What you really mean is "If the only AuthenticationRequest needed contains only a button, don't make the user manually click that button" with some sort of consideration for RememberMeAuthenticationRequest.

Tgr added a comment.Sep 20 2016, 1:19 AM

Some problems that would have to be considered:

  • do we still require the user to click on the login link, or can login be fully automatic (and triggered by a session provider, or some new mechanism added to AuthManager)? Autologin (if it works by redirecting an arbitrary page, as discussed in T110464) has some usability warts (e.g. the user might lose data if the session times out while they are editing a page). CentralAuth has some nice mechanics (load a special page as a JS file, use that request to log in, use the returned JS script to update the page so that it looks logged in) but that seems a bit too complex for core.
  • do we care about CSRF attacks? Especially if the provider also does autocreation, an attacker can just send the visitor to a wiki and see what user is autocreated to identify them. An alternative would be that autologin only works with a CSRF token in the URL, but that would make logged-out pageviews uncacheable since the login link would have to be manipulated on every page. (Alternatively it could be done from Javascript but eww.)
  • how do you set "remember me" if you don't show it to the user? We must disable it since they might be on a shared computer, but that's annoying for people who use the wiki a lot from their home computer. We might want to find some way to change the session to remembered after login is finished.
  • we are generally trying to do DB writes on POST, to be multi-datacenter-friendly. This is not terribly important because 1) login usually does not write to the DB (but might, if the user token is missing, or a provider decides to update user details from a remote source) and 2) Wikimedia probably won't use auto-login and other sites probably won't use multi-DC. Still, would be nice to do if it's not hard.

Change 312865 had a related patch set uploaded (by Cicalese):
Bypass login page if no user input is required.

@dpatrick, @Bawolff: the patch above will make a visit to Special:UserLogin result in automatic login if none of the configured authentication providers require user interaction (this typically means that there is a single primary provider and it uses redirect flow). As far as I see there is no way to do this in a CSRF-safe fashion. That seems to be a limited concern in practice; CentralAuth already makes it possible to log someone in on a given wiki via CSRF when they are logged in globally, and although there were some complaints (T21161) we don't plan to do anything about that. So it seems OK to me but I'd like a nod from someone from Security. (Note, this doesn't affect Wikimedia as one would have to disable all password-based login for it to happen.)

As there's no feedback so far, I add the Security tag (hopefully that is the security team) to bring this up to all security team members :)

dpatrick edited projects, added Security-Reviews; removed Security.Nov 8 2016, 9:39 PM

Change 312865 merged by jenkins-bot:
Bypass login page if no user input is required.

Change 323644 had a related patch set uploaded (by Cicalese):
Bypass login page if no user input is required.

Change 323644 merged by jenkins-bot:
Bypass login page if no user input is required.

Change 323645 had a related patch set uploaded (by Gergő Tisza):
Filter GET data when bypassing the login form

Change 323646 had a related patch set uploaded (by Cicalese):
Bypass login page if no user input is required.

Change 323646 merged by jenkins-bot:
Bypass login page if no user input is required.

Change 323786 had a related patch set uploaded (by Gergő Tisza):
Show already logged in / security reauth message at the right time