Page MenuHomePhabricator

SO878 Step 4: Bind permissions to 2FA
Closed, ResolvedPublic

Description

Objective: Certain permissions shall only be granted when the user logs in using 2FA
The following functions are the result of this project phase
The implementation of this functionality must be assessed and coordinated with MediaWiki
architects. We propose one of the following mechanisms:

  • Users are added to an implicit group with additional rights when using 2FA

or

  • Users are prevented from executing a list of rights when not using 2FA

Event Timeline

Osnard created this task.Mar 13 2019, 2:10 PM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptMar 13 2019, 2:10 PM
Osnard added a subscriber: Bawolff.May 9 2019, 9:15 AM

Meeting minutes from 2019-05-08:

  • Certain permissions should be suppressed if user is not 2FA
  • @Bawolff suggests usage of new UserGetRightsRemove hook.
    • We should check if a precise error message in case a user looses the permission due to not having 2FA is possible. If not, it's no show stopper.
  • List of permissions to supress should be defined by a configuration variable
    • Permission editinterface should be default
Restricted Application added a subscriber: Urbanecm. · View Herald TranscriptJul 5 2019, 4:54 PM
Urbanecm removed a subscriber: Urbanecm.Jul 5 2019, 5:04 PM
Nirmos added a subscriber: Nirmos.Jul 6 2019, 9:06 AM
Tgr added a subscriber: Tgr.Jul 14 2019, 6:13 PM

We should check if a precise error message in case a user looses the permission due to not having 2FA is possible. If not, it's no show stopper.

It's not. The related task is T180888: All permission checks should be able to return a custom error message.

I think a somewhat hacky workaround would be possible, where PermissionManager tracks user right revocations (ie. instead of the cache looking like $username => [ $right, ... ] it would be something like $username => [ 'rights' => [ $right, ... ], 'revocations' => [ $right => $message, ... ] ]) and add an output parameter to PermissionManager::userHasRight and the like for the case where the right is available but revoked. UserGetRightsRemove would have to be changed but it's a new hook and not used much yet so that's not too bad.
(See T227975: Grant permission errors where the user has the right but the app does not have the grant are unclear for another use case for this.)

Thanks four you input @Tgr

Reedy closed this task as Resolved.Jul 31 2019, 2:22 PM