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
@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:
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:
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.
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.
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:
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.
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.
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.
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?
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?