Page MenuHomePhabricator

Setup central login domain
Closed, ResolvedPublic

Description

To complete bug 46901, we need a single domain where global users will be logged in, and all of the WMF sites can test check to see if the local wiki should allow a user to login.

Because this website will have a session for every logged in user, the site should:

  • Highly restrict the javascript that can run on it
  • Minimize the amount of content and features, to reduce the risk for XSS vulnerabilities
  • Only be accessible over SSL
  • Disallow any iframing

Version: wmf-deployment
Severity: enhancement

Details

Reference
bz46902

Event Timeline

bzimport raised the priority of this task from to High.Nov 22 2014, 1:43 AM
bzimport set Reference to bz46902.

(In reply to comment #0)

To complete bug 46901, we need a single domain where global users will be
logged in, and all of the WMF sites can test check to see if the local wiki
should allow a user to login.

Because this website will have a session for every logged in user, the site
should:

  • Highly restrict the javascript that can run on it

Could take away editinterface away from sysops, But that means they can't edit any message in the mediawiki ns, Which would be bad. But stops any of the edits to js/css that effects all users

  • Minimize the amount of content and features, to reduce the risk for XSS

vulnerabilities

Depending on what context you want it to be used, eg: central place for userpages, You wouldn't need many extensions that are outside the group thats defaultly enabled.

  • Disallow any iframing

We do this by default these days iirc, Or at least tim has coded it.

(In reply to comment #1)

Could take away editinterface away from sysops, But that means they can't
edit
any message in the mediawiki ns, Which would be bad. But stops any of the
edits
to js/css that effects all users

A number of people should have access, but some number less than the thousands that can edit enwiki would be nice ;)

  • Minimize the amount of content and features, to reduce the risk for XSS

vulnerabilities

Depending on what context you want it to be used, eg: central place for
userpages, You wouldn't need many extensions that are outside the group thats
defaultly enabled.

Most of the XSS we've seen have required some input. My preference would be no user controlled data. If it seems best to also use it for global user profiles, we'll need to be extra paranoid about what extensions are enabled.

  • Disallow any iframing

We do this by default these days iirc, Or at least tim has coded it.

There are a lot of pages (e.g., action=view for articles) that override that, unfortunately. We would probably clean those up so we can disable all of them.

pgehres wrote:

The domain has been finalized as login.wikimedia.org.

It has been described as a reverse-fishbowl in that only global accounts are allowed -- there will be no local accounts.

(In reply to comment #3)

The domain has been finalized as login.wikimedia.org.

It has been described as a reverse-fishbowl in that only global accounts are
allowed -- there will be no local accounts.

Is there any other needed initial configuration?

(In reply to comment #2)

(In reply to comment #1)

Could take away editinterface away from sysops, But that means they can't
edit
any message in the mediawiki ns, Which would be bad. But stops any of the
edits
to js/css that effects all users

A number of people should have access, but some number less than the
thousands
that can edit enwiki would be nice ;)

Isn't that just a matter of not giving many people sysop? Or you could do as mentioned in comment #1 (remove editinterface from sysops) and give editinterface to a different, more limited group.

You'd probably also want $wgAllowUserJs and $wgAllowUserCss set to false.

  • Disallow any iframing

We do this by default these days iirc, Or at least tim has coded it.

There are a lot of pages (e.g., action=view for articles) that override that,
unfortunately. We would probably clean those up so we can disable all of
them.

There's already $wgBreakFrames that looks like it would force anything using OutputPage::output() to always set X-Frame-Options: DENY.

But be careful you don't break the iframe-based login check from Gerrit change 58924. Since it doesn't use OutputPage::output(), it should be safe from $wgBreakFrames.

Most of the XSS we've seen have required some input. My preference would be
no user controlled data.

Take away everything except 'read' from *, users, and autoconfirmed? ;)

(does CentralAuth need 'createaccount' and/or 'centralauth-merge' to create the local account during login?)

(In reply to comment #5)

You'd probably also want $wgAllowUserJs and $wgAllowUserCss set to false.

Yes, please.

Take away everything except 'read' from *, users, and autoconfirmed? ;)

I actually do think this is a good idea. If we decide later it's desired, then we can always add rights.

(does CentralAuth need 'createaccount' and/or 'centralauth-merge' to create
the
local account during login?)

Yes, those will be needed.

Might be worth starting a changeset in mediawiki-config for this wiki. Makes it easier to review, and it can be updated collaboratively.. :D

At the same time it might be easier just to put some of these directly into CommonSettings to begin with - we can loop to set all rights not to be kept etc. Might just generally be cleaner than tens of => false on different options

pgehres wrote:

(In reply to comment #7)

At the same time it might be easier just to put some of these directly into
CommonSettings to begin with - we can loop to set all rights not to be kept
etc. Might just generally be cleaner than tens of => false on different
options

I definitely like the idea of explicitly assigning all rights on this wiki as opposed to disabling everything that we can think of (i.e. remove ALL rights and then add back).

Related URL: https://gerrit.wikimedia.org/r/62002 (Gerrit Change Ieef88a12cf396bca66a0f890b0fe4b4e3223751d)

Related URL: https://gerrit.wikimedia.org/r/62020 (Gerrit Change I03b88050bb253fa91240d1797c754d5084392a75)

Related URL: https://gerrit.wikimedia.org/r/62021 (Gerrit Change I3668326cc715708eeb7ff9d8350b67dd03c2a947)

(In reply to comment #6)

(does CentralAuth need 'createaccount' and/or 'centralauth-merge' to create
the
local account during login?)

Yes, those will be needed.

'centralauth-merge' is easy

It would look like from the code that 'createaccount' isn't needed if we have 'centralauth-autoaccount' for *

public function autoCreate() {

		global $wgGroupPermissions;
		// Yes unless account creation is restricted on this wiki
		return !empty( $wgGroupPermissions['*']['createaccount'] )
			|| !empty( $wgGroupPermissions['*']['centralauth-autoaccount'] );

}

Adding createaccount is going to show the registration stuff...