Modernize MediaWiki authentication system (AuthManager)
Open, NormalPublic

Description

Design and implement a modern authorization system for MediaWiki that allows easier creation of complex authentication configurations. Initial ideas should be taken from the AuthStack RfC and refined to ensure that a variety of user stories can be satisfied by the ultimate design.

What we have now: https://www.mediawiki.org/wiki/Manual:SessionManager_and_AuthManager

Some discussion: https://www.mediawiki.org/wiki/Requests_for_comment/AuthManager

Related Objects

StatusAssignedTask
OpenNone
ResolvedAnomie
OpenNone
ResolvedTgr
ResolvedAnomie
OpenNone
ResolvedAnomie
OpenNone
ResolvedLegoktm
Resolvedbd808
Resolvedbd808
Resolvedcsteipp
ResolvedTgr
Resolvedcsteipp
OpenTgr
ResolvedTgr
OpenNone
ResolvedAnomie
ResolvedAnomie
ResolvedAnomie
ResolvedTgr
ResolvedAnomie
ResolvedTgr
ResolvedTgr
Resolveddemon
DuplicateNone
There are a very large number of changes, so older changes are hidden. Show Older Changes
bd808 set Security to None.
Nemo_bis added a subscriber: Nemo_bis.EditedJul 18 2015, 6:13 PM

The RfC is very abstract and IMHO fails to convey what are the expected benefits. It also did not look related to Wikimedia sites (for instance it talks of logging in with Google credentials), until I found out that it is: T91701.

It would be especially great to have a list of reports filed by end-users (e.g. in MediaWiki-extensions-CentralAuth) which this project may help fixing; there is no shortage of heartfelt issues.

Tgr added a subscriber: Tgr.Aug 26 2015, 4:37 AM

@Nemo_bis: AFAIK the main Wikimedia use case is T107605 (already on the list of blocked tasks). For MediaWiki in general, the three main benefits are clearly outlined in the RfC:

  • allowing multiple authentication plugins simultaneously (e.g. CentralAuth + Facebook login)
  • support for non-password-based authorization systems (which typically involve redirecting the user to the website of some external authentication provider)
  • simplifying authentication logic (which is currently a mess of hacks and one-off hooks), thus making changes easier to review, thus improving security.
Nemo_bis added a comment.EditedAug 26 2015, 7:38 AM

Thanks for the clarification! I meant user benefits, which are not currently extractable from the RfC. Security improvements are quite theoretical and AFAIK "non-password-based authorization systems" already exist, so the summary seems to be:

  • two-factor authentication on Wikimedia wikis;
  • fix a bug in some of those authentication systems which are unable to be provided simultaneously (TwitterLogin seems unaffected?).

As for logic simplification, that's a commendable ideal aim which usually ends up causing more havoc than actual benefits; were the existing extensions surveyed to identify their integration needs?

As for logic simplification, that's a commendable ideal aim which usually ends up causing more havoc than actual benefits; were the existing extensions surveyed to identify their integration needs?

I think it was more anecdotal than a rigorous survey, but yes, we did look though pretty much all of the Auth[nz] extensions to evaluate what they were doing, and how. Along with our experience running stuff like wikitech (LDAP + OATH), and my personal experience with Ex:OAuthAuthentication and Ex:OpenID.

With almost all of those extensions, there were things that were painful to implement (resetting your password on a wiki so you could usurp it via OpenID login, logging in a user with their new username post-rename, 2-factor login as a separate auth step) where the problem wasn't that hard, but MediaWiki's current Authn structure made it really hard to work with.

I'll be honest, I'm not sure we were able to simplify things in the Authn process (although we're still working on it!), but we should be able to reduce code duplication and ugly hoop-jumping in almost all of the Authn extensions after this.

bd808 renamed this task from Modernize MediaWiki authentication system to Modernize MediaWiki authentication system (AuthManager).Aug 26 2015, 5:56 PM
Tgr added a comment.Aug 26 2015, 6:56 PM

I meant user benefits, which are not currently extractable from the RfC.

User benefits generally follow from developer benefits - if it is easier to get stuff done, more stuff gets done. (And if it is easier to do security reviews, there is less chance your account gets stolen.)

Security improvements are quite theoretical and AFAIK "non-password-based authorization systems" already exist

Any improvement is theoretical before it actually gets done so I am not sure what you mean by that. Non-password-based authentication systems can only exist currently by fully reimplementing login; having a single place in core where security-sensitive operations are performed is obviously better than having it redone in half a dozen extensions, which probably get way less code review. E.g. with TwitterLogin you get ejected to the front page after a successful login, because it did not reimplement that part of the authn logic. Also at a glance it doesn't seem to reset the session id on a successful login, which opens up all kinds of fun session hijack possibilities. You don't want those kinds of mistakes to potentially happen in each of the dozens of authn extensions we have - in the best case it is a waste of the author's time to have to think about them, in the worst case they don't and it results in some serious vulnerability.

were the existing extensions surveyed to identify their integration needs?

To the extent of identifying extensions which would be broken by the change (because they are AuthPlugin providers, or they rely on AuthPlugin), in T91303.

Tgr reopened this task as Open.

Uh, wrong button.

devunt added a subscriber: devunt.Oct 1 2015, 1:39 AM
dr0ptp4kt moved this task from Backlog to Current Quarter on the Reading-Admin board.
Meno25 removed a subscriber: Meno25.Feb 19 2016, 5:39 PM
Nemo_bis added a comment.EditedMay 12 2016, 4:34 PM

From T110282#2289376:

Anomie removed a blocking task: T111486: Update Translate to use AuthManager.

I'm not sure what this implies, but to be clear: AuthManager must be rejected by MediaWiki core, if it *worsens* our integration.

I notice with surprise that https://www.mediawiki.org/wiki/Requests_for_comment/AuthManager still doesn't make explicit what the general goals of this exercise are. I'm very sad to see that my comment of one year ago is still valid:

The RfC is very abstract and IMHO fails to convey what are the expected benefits.

On the other hand, the first line of the RfC does state what its goals are *not*, by saying that «current authentication and authorization system is very limited and restricted in terms of the allowed customization, for system administrators, core developers, and extension developers». Clearly, the RfC is about making the system *less* limited and restricted in terms of customization, right?

In contrast, T111486#2289343 seems to imply that AuthManager will make it harder for extensions (like Translate/TwnMainPage) to customise/build upon the authentication/account creation system, or even that things which are now possible for extensions may become impossible. This would mean that the currently proposed implementation goes against the (approved?) RfC.

In contrast, T111486#2289343 seems to imply that AuthManager will make it harder for extensions (like Translate/TwnMainPage) to customise/build upon the authentication/account creation system,

Wrong. If you change that to "write their own authentication/account creation system from low-level functions like User::addToDatabase(), bypassing MediaWiki's code and all other extensions", you'd be closer to the truth.

Tgr added a comment.May 12 2016, 6:06 PM

From T110282#2289376:

Anomie removed a blocking task: T111486: Update Translate to use AuthManager.

I'm not sure what this implies

This implies that someone has to update the extension to use the interfaces provided by AuthManager (or work around them, if your prefer that), and Reading Infrastructure is not committing to be that someone.

I notice with surprise that https://www.mediawiki.org/wiki/Requests_for_comment/AuthManager still doesn't make explicit what the general goals of this exercise are.

The "Current problems" section actually does that.

In contrast, T111486#2289343 seems to imply that AuthManager will make it harder for extensions (like Translate/TwnMainPage) to customise/build upon the authentication/account creation system, or even that things which are now possible for extensions may become impossible.

In general, building on / customizing the auth system is becoming easier; extensions can change the auth forms to be multistep, use redirection (e.g. OAuth) without having to implement their alternative login page, use HTMLForm instead of raw HTML / request data manipulation etc. There is no guarantee that no hack currently in existence is going to become harder, though.

Nemo_bis updated the task description. (Show Details)Nov 19 2016, 9:03 AM

One year and almost two MediaWiki releases later, how do we assess the adoption and impact (both positive and negative) of this change?

For instance, if a significant portion of wikis were stuck on MediaWiki 1.26 for lack of upgrade options, would we notice and what could be done for them?

Tgr added a comment.Nov 19 2016, 7:14 PM

I don't think we have a good measure of how wikis change version.According to https://wikiapiary.com/wiki/Statistics the majority are on 1.26, but that's hard to interpret without having historical data to compare.

On Phabricator and Stackoverflow I haven't seen much activity around authentication extensions. Maybe hosting services could be asked for experiences?