MediaWiki + Authentication
Closed, ResolvedPublic

Description

Ben wrote:

i'm suggesting we replace it completely with OAuth2
authentication against Phabricator. The code in the existing plugin is
fairly complex, and even if we do fix it for this time around it'll
probably create more problems down the line. Considering some of the
problems the current Identity system is causing, we're also
considering replacing LDAP with OAuth2 - potentially hosted by
Phabricator - so moving in this direction now is probably a good idea
for future proofing (I believe the recent versions of phpBB also
support OAuth rather well too, so bonus points there...)

Is there anyone who could help sorting out getting the latest version
of Mediawiki and Phabricator chatting over OAuth2?

Answer:

Nicolas wrote:

Would Phabricator become the master user account manager, replacing
identity.kde.org?

Ben:
This would be a step in that direction yes. Whether we will actually
take this step in the long run is another thing altogether.

Nicolas wrote:

What if we make mediawiki, phabricator, etc. login to identity using
OAuth2?

That would require adding OAuth2 Provider, and appropriate API code to
Identity as it stands.
Phabricator already has all of this, so let's leverage it to reduce
our cost of maintenance.

Started working on a custom phabricator login extension, based on oauth2.
Problem with existing solutions:

  • the oauth extension from mediawiki is a server implementation (no)
  • the oauthauthentication extension acts as client indeed, but expects oauth server to be another wiki installation. Additionally, it is based on oauth1 = incompatible, too much to rewrite (no)
  • google login extension as base for a rewrite is not easier either, as it is based on oauth2, but uses a library that is heavily based on google's servers (no)
  • some other code was found that was not in a working state and also, outdated

All in all, no way to circumvent an own extension. I'd be glad if someone with knowledge of php and mediawiki and/or oauth2 jumps in. I can do a scratch repo if needed.
Else i cannot set an estimation of when that will be finished, those 2 areas are clearly not my expertise ;)

From the mail of Ingo:

  1. Test domain => test domain requested with userbase data.
  2. Update to the latest MW code => upstream repo + needed extension (last version available: REL1_26)
  3. Theme: Old theme Neverland not compatible with the new codebase => Rewritten to reflect the changes. Works.
  4. Login: Still to do.

What stopped updates in the past was the use of a hacked version of the openid extension. It was hacked to add the option to login via identity.ko. This worked, somehow, until now.

Some existing solutions of OAuth login were tested:

  • OAuthAuthentication extension does not work, it is based on OAuth1, while Phabricator works with OAuth2. Also, it is written to support OAuth login via another wiki.
  • The google-login extension is indeed OAuth2 based, but uses a library that is specifically written for the google servers, too much to rewrite for our case.
  • Finally we found https://github.com/joostdekeijzer/mw-oauth2-client-extension, which is obviously not that active anymore, and does not work without further hacks. Right now we made it work to talk to phabricator and make it at least seem to be able to login. But that is far from done. It produces a login to a username "2", no matter who is logged in to phabricator and misses a session. So there is still stuff to be done.

I am not yet familiar with OAuth2, but when time permits I am going to attempt writing a proper extension based on top of https://gerrit.wikimedia.org/r/#/c/195297/ and whatever Ingo has learned so far. I believe there will other users of OAuth2 who could help maintaining the extension in the future.

There is also a supported openID extension... Isn't it supported by Phabricator as well?

Relying on Phabricator for the authentication on all websites will force us to stay with it and will create new issues when we will want to change (hopefully not too soon).

Isn't it worth it to move identity to a classical and well supported standard? (I don't know what is powering it now)

identity is a custom yii application. And if i remember correctly, it was planned to move away from it some years back (i was away for a while). Ben might have some input on this.

Thanks Niklas, i try to give it a least a proper form and put it into a repo, so you can give a good mw code. The oauth2 stuff can be easy if the lib i have in use works correctly.

Restricted Application added a subscriber: sysadmin. · View Herald TranscriptFeb 18 2016, 5:24 AM

Please note that OAuth (either 1 or 2) is not a generic protocol for Identity interchange.
It does however describe a process of token exchange, how those tokens are generated and the workflow for using them.

Most implementations tend to use the same endpoint exchange procedure as well.

A generic Extension, which one can then write small customisations to handle the initiation, reception of token, and subsequent user account detail retrieval would be a good idea though.

@ochurlaud unfortunately there isn't anything which is "standard" in the world of authentication.

LDAP is extremely suboptimal, requires you run your own home brewed software to manage the directory, and applies numerous constraints to you if you want to use it. For instance, most applications only support using it as the sole source of authentication data (so if you have been using an application standalone you're stuffed due to username collisions) and they don't pick up changes in the LDAP data at all generally (even if you logout and back in again).

OpenID is also going the way of the dinosaur, and while "standard" is extremely limiting in the information you can exchange using it (groups, custom profile fields, etc are not provided for - often being done with proprietary addons requiring custom implementation yet again on both server and client).

Other "SSO" protocols, like SAML and Shibboleth are extremely resource intensive to implement, complex, and convoluted (Signed XML responses anyone?). simpleSAMLPHP is the only PHP implementation of SAML I am aware of, with most PHP applications implementing SAML by connecting with it to handle the process in some manner or another.

Any protocol which doesn't shift the login process to a single application also means it is technically infeasible to implement Multi-Factor Authentication.

OAuth2 is the most flexible of all the possible options - and Phabricator conveniently has one already built in which we can use, saving us the cost of writing one ourselves (Phabricator Projects also provide groups support approximately as a secondary bonus)

imalchow closed this task as Resolved.Feb 26 2016, 11:51 PM
imalchow claimed this task.

Fixed now, OAuth2 authentication is in place.
Chaka!