Page MenuHomePhabricator

Be able to force OATHAuth for certain user groups
Open, Needs TriagePublic

Description

We need a way, for certain wikis to force certain users to use OATHAuth.

There are two (somewhat complimentary) possible approaches:

  • Refactor OATHAuth to use AuthManager for enabling/disabling (T137471), then write a SecondaryAuthenticationProvider that asks for 2FA to be set up after a successful login. (ResetPasswordSecondaryAuthenticationProvider is an example.) This is good when we want to completely lock users out of the wiki until they have set up 2FA but is less effective for already logged-in users who get promoted into a new user group (although the system could log them out when the promotion happens if they do not have 2FA set up).
  • Use the UserGetRights hook to disable sensitive permissions until 2FA is set up, and find some way to communicate to the user what is going on. This is good when we only want to require users with access to a certain permission to use 2FA, but the communication part seems messy (see T180888: All permission checks should be able to return a custom error message).

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptNov 12 2016, 1:25 AM

Maybe involving wgPasswordPolicy?

Luke081515 added a subscriber: Luke081515.EditedNov 14 2016, 7:37 PM

You just want to have it, or to plan use it later (at wikimedia)? If so, just for Stew/OS/CU or for crat, sysops and normal users?

Reedy added a comment.Nov 14 2016, 7:52 PM

We need to have it (support adding to the extension) so we can eventually roll it out to wmf wikis

Reedy renamed this task from Force OATHAuth for all users to Force OATHAuth for user groups.Nov 16 2016, 8:56 PM
Jdforrester-WMF renamed this task from Force OATHAuth for user groups to Be able to force OATHAuth for certain user groups.Nov 16 2016, 9:22 PM
Anomie added a subscriber: Anomie.Nov 16 2016, 10:16 PM

For this to happen, we'd probably need to have OATH's SecondaryAuthenticationProvider be able to force the user to set it up during login and (maybe) account creation. Or figure out some other way to prevent "user gets promoted, suddenly they're locked out because they have to log in to set up 2FA but can't log in until they set up 2FA."

Maybe involving wgPasswordPolicy?

That's not likely to be the right place to do it, since that's all about checking the validity of a password rather than arbitrary other auth plugins.

For this to happen, we'd probably need to have OATH's SecondaryAuthenticationProvider be able to force the user to set it up during login and (maybe) account creation. Or figure out some other way to prevent "user gets promoted, suddenly they're locked out because they have to log in to set up 2FA but can't log in until they set up 2FA."

It could just be done by education; Tell 'crats not to promote people until they confirm they've enabled it.

However, having it enforceable at login, or at signup for where it's compulsory for all users would be a nicer workflow experience

Tgr added a subscriber: Tgr.Nov 17 2016, 4:40 AM

Some options:

  • copy PasswordPolicy workflow: a dialog at the end of a successful login which asks you to set up 2FA (and possibly blocks login if you don't, although I don't think we want that)
  • some nagging message (bar of doom, undismissible echo notification) that does not go away until 2FA is set up
  • certain permissions simply do not work as long as 2FA is not activated (easy to do via UserGetRights hook, less easy to explain user what's going on)

It could just be done by education; Tell 'crats not to promote people until they confirm they've enabled it.

Seems risky to me.

or at signup for where it's compulsory for all users

We'd want to allow bypassing it during workflows where the creator isn't going to be immediately signed in as the new user.

Some options:

  • copy PasswordPolicy workflow: a dialog at the end of a successful login which asks you to set up 2FA (and possibly blocks login if you don't, although I don't think we want that)

In other words, the SecondaryAuthenticationProvider described above. Note that not blocking the login wouldn't actually force it as this task requests.

  • some nagging message (bar of doom, undismissible echo notification) that does not go away until 2FA is set up

That doesn't actually force it, though.

  • certain permissions simply do not work as long as 2FA is not activated (easy to do via UserGetRights hook, less easy to explain user what's going on)

Combine this one with the nagging message?

It could just be done by education; Tell 'crats not to promote people until they confirm they've enabled it.

That would be a way, but additionally, it shouldn't be possible to give the right if it's not enabled.

  • copy PasswordPolicy workflow: a dialog at the end of a successful login which asks you to set up 2FA (and possibly blocks login if you don't, although I don't think we want that)

+1: this would be a good solution in 3rd party use of MediaWiki. See also this request by someone: https://www.mediawiki.org/wiki/Topic:U1khgcljizyav0it

Tgr updated the task description. (Show Details)Nov 18 2017, 11:13 PM
Tgr updated the task description. (Show Details)Nov 18 2017, 11:18 PM
Tgr added a comment.Nov 18 2017, 11:31 PM

From an email thread:

[Disabling sensitive permissions and communicating to the user what is going on] is easy to do in a half-baked way. You could use UserRetrieveNewTalks or ArticleViewHeader or a continuously regenerated Echo message or something equally inadequate to notify the user (not something we'd want to happen on Wikimedia wikis though).
Undismissable Echo notifications would be a nicer approach UX-wise but probably requires adding that capability to Echo (does not sound super hard); plus, doesn't handle the issue Echo-less MediaWiki.
Custom permission errors would be a nice approach but they are not properly supported by core; you'd need to change the order of things in Title::checkPermissionHooks, and that still leaves non-title-specific checks like User::isAllowed. Making sure every permission check can return a customizable error message would be a significant refactoring.

Filed T180888: All permission checks should be able to return a custom error message about that last issue.

Maltfield added a subscriber: Maltfield.EditedFeb 27 2018, 10:27 PM

+1 We'd really like this feature to force all Administrators to use 2FA on our org's wiki (Open Source Ecology).

fwiw, wordpress has a similar issue. The best wp plugin I've found for 2FA also doesn't include the ability to require users to use it, but there is another plugin that does this:

When set to "Force the user [to use 2FA]", it allows the user to login, but it immediately redirects you to the "User Profile" page and, until the user checks the box to activate 2FA, they are demoted to the "Subscriber" role. So the only page they can actually access in the wp dashboard is their own User Profile page--where the 2FA options reside.

Maybe Mediawiki could similarly strip a user's groups (ie: Administrator) until 2FA were activated--with a 301 redirect to the relevant Special page immediately after login, including a banner message explaining what's happening?

Nirmos added a subscriber: Nirmos.Apr 13 2018, 7:29 AM
jrbs added a subscriber: jrbs.May 9 2018, 1:42 AM

Adding T&S since resetting these is presently a responsibility we've been taking on.

jrbs moved this task from Backlog to Support on the Trust-and-Safety board.Jun 17 2018, 9:39 PM
jrbs moved this task from Support to Radar on the Trust-and-Safety board.
Teles added a subscriber: Teles.Jul 10 2018, 6:52 PM
Framawiki added a project: Security.
Framawiki added a subscriber: Framawiki.

Change 452020 had a related patch set uploaded (by MR70; owner: MR70):
[mediawiki/extensions/OATHAuth@master] Permissions of a specific groups should be removed if Two-Factor-Auth isn't enabled for a user

https://gerrit.wikimedia.org/r/452020

RP88 added a subscriber: RP88.Aug 20 2018, 4:59 PM
Reedy added a parent task: Restricted Task.Oct 27 2018, 8:56 AM
DStrine changed the visibility from "Public (No Login Required)" to "WMF-NDA (Project)".Oct 30 2018, 4:46 PM
Reedy added a comment.Oct 30 2018, 5:05 PM

@DStrine Why have you made the visibility restricted to WMF-NDA? I really cannot see any good reason for that

@Reedy it was previously set at a very restricted visibility setting. Are you suggesting restoring that?

Reedy added a comment.Oct 30 2018, 5:13 PM

DStrine changed the visibility from "Public (No Login Required)" to "WMF-NDA (Project)".

No it wasn't?

Reedy changed the visibility from "WMF-NDA (Project)" to "Public (No Login Required)".Oct 30 2018, 5:13 PM

After changing it back, I can view this task in incognito mode. We can't get much more open than that

It previously had the *custom policy at the top and was not visible my several WMF managers.

According to Phabricator it was Public, then you hid it:

DStrine changed the visibility from "Public (No Login Required)" to "WMF-NDA (Project)".Tue, Oct 30, 16:46

This task blocks multiple ones with restricted visibility, maybe this was causing confusion?

Meno25 added a subscriber: Meno25.Dec 9 2018, 3:55 AM
Tgr updated the task description. (Show Details)Dec 10 2018, 7:16 AM