So we have a long established MediaWiki installation with a pretty big user base. We are now trying to develop a small PHP-based application, unrelated to the wiki (that will live on the same server but not exist within the MediaWiki installation), that we want to implement SSO for. Basically the users of the wiki should be able to use their MediaWiki login to sign into this new application. I prefer to NOT give the new app access to the MediaWiki database directly if possible, so I have been reading up in the API ClientLogin. At the moment I have been using their "API Sandbox" built into MediaWiki to test some basic functions and calls. When I run a test URL, for example:
http://127.0.0.1/wiki/api.php?action=clientlogin&username=example&password=12345678&logintoken=1234567&loginreturnurl=http://123.com
I get return status fail, stating "the supplied credentials could not be authenticated." "Authmanager-authn-no-primary". I’m kinda lost as to what MediaWiki is asking for. I will admit, MediaWiki is not something I’m well versed in on the development side, and a lot of what I can find documentation wise to accomplish what I am looking to do is from pre 1.27 versions, where login management was handled differently. Am I going down the right path here, or would direct database connection be smarter? Or is there another whole method that makes even more sense?
2
Answers
There are many options, depending on what exactly you are after and what your requirements are. If you want proper SSO (single sign-on), asking the user for their password again doesn’t really cut it. If you want to connect a less secure website to a more secure MediaWiki installation, having the passwords go through the less secure site is again not a great idea. OTOH it is fairly simple in most cases – but note that the clientlogin API replicates the login experience. If the user gets needs to provide extra information during login (e.g. they need to change their password because it is too simple), the same information needs to be provided to the clientlogin API as well. (The login API is slightly simpler to use but only works for the basic username+password workflow.)
A direct DB request is possible but messy – you’ll have to replicate the exact password hashing MediaWiki does, which might change without warning, you might need to duplicate site secrets, DB credentials etc. Plus it makes an exploit of the other website even easier to convert into an exploit of the wiki. You are very likely going to be better off using the API.
You could check whether the user is logged in on the wiki, via the userinfo API (if the other website is less secure, this is again a bad idea, but also fairly simple). You could set up the wiki as an identity provider, e.g. install the OAuth extension, and use OAuth login (which is not simple, but there are plenty of libraries).
Or may be change the way you see the issue :
For the migration, or you replicate your database and the hash mechanism, without duplicating it as Tgr also nicely mentioned disadvantages. Or you steward your users to create a new account on the new system, allowing them to temporary login with both backends.