Page MenuHomePhabricator

Determine the best way to handle REMOTE_USER authentication
Open, Needs TriagePublic


During the talk he gave in the MediaWiki-Stakeholders-Group meeting today, @Osnard said that there were some problems with MediaWiki-extensions-Auth_remoteuser and its use with VisualEditor.

Specifically, there was some conflict between the way MediaWiki-extensions-Auth_remoteuser created new sessions on every request instead of using cookies.

I noted that I don't have the same problem with PluggableSSO which relies on MediaWiki-extensions-Pluggable-Auth for much of its plumbing.

Since we need some sort of authentication piece for the LDAP stack (since we're hoping to replace the old monolithic extension) we need to figure out a way to do this.

From what I can see, we have at least the following two options options:

(I'm not happy with the session bits that I have in PluggableSSO. I managed to kludge something together, but I don't understand it very well and it hasn't gotten a lot of review.)

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptDec 7 2018, 5:06 PM
Tgr added a comment.Dec 7 2018, 5:20 PM

Parsoid needs to call the MediaWiki API and I guess the authentication for that process is the problematic part? It can forward cookies but that's no help with most SSO systems.

The simplest solution might be to create a new auth method (as a separate extension) that just uses some secret only known to MediaWiki and Parsoid to sign Parsoid requests. It could be allowed to impersonate any user (so that view permission checks work as expected) and it could use some grants-like mechanism to prevent write access for extra paranoia (since Parsoid does not need that).

I just ran into this problem with a client today. I'm wondering if @Osnard has a better solution, but I just commented out the bit in Auth_remoteuser that munges the cookie name.

Osnard added a comment.EditedApr 23 2020, 9:35 AM

For our customers, we use "Extension:Auth_remoteuser" with LDAPStack.
So this it how we handle it:

  1. Enable kerberos authentication for all incoming requests (mod_auth_kerb for Apache; "NTML/Kerberos authentication setting" for IIS)
  2. Create a bypass for calls coming from Parsoid (In IIS this must be a dedicated "Website" that allows anonymous access on a custom port, as one can not add exceptions to the authentication rule). This bypass must be configured in a way that only Parsoid can call it!
  3. Parsoid gets configured to forwardCookies
  4. In the wiki settings we add a special configuration that sets the $wgAuthRemoteuserUserName


$wgAuthRemoteuserUserName = function() {
	global $wgDBname;
	$user = '';
	if( isset( $_SERVER[ 'REMOTE_USER' ] ) ) {
		$user = $_SERVER[ 'REMOTE_USER' ];

	//Bypass for Parsoid calls
	if( isset( $_SERVER[ 'REMOTE_ADDR' ] ) && substr( $_SERVER[ 'REMOTE_ADDR' ], 0, 4 ) == '127.' ) {
		if( empty( $user ) ) {
			// check the "304f3058RemoteToken" name of your cookies in your browser!
			$user = $_COOKIE[$wgDBname.'304f3058RemoteToken'] . '@DOMAIN OF CUSTOMER'; 
                        //$user = 'DOMAIN OF CUSTOMER\\' . $_COOKIE[$wgDBname.'304f3058RemoteToken']; //If `domain-backslash-username` is configured in `$LDAPAuthorizationAutoAuthRemoteUserStringParser`

	return $user;

That's it. So we basically set the "remote user" from the value in the cookie send by Parsoid. The important thing is, that this bypass must only be callable by the Parsoid service!