Skip to content

Interface to configure 2FA for users/groups (aka forcing/require 2FA) #2348

@boppy

Description

@boppy

DISCUSSION
There are some discussions (see references) on "forced 2FA" inside the TOTP-2FA-Repo that should be continued here in "core".

What's it about?

There should be a GUI (with some backend logic) to...

  1. Force a user/group to do 2FA
  2. Reset a forced-2FA (~= occ twofactor:disable user)
  3. Get your 2FA code(s) at first login (just like the first-run-wizard, but not to be canceled)
    1. Problem: You sould not really been logged in. You should stay in a state where you cannnot access files (nor admin) before having at least one 2FA being set up.
    2. In my PR (regarding TOTP) I just echoed the QR to get scanned by the user.
    3. There might be a better place since that might not be suitable (nor possible) for other 2FA.

Ideas and discussions

My initial idea on that is to provide a table (just like user admin) with a list of all configured 2FA endpoints like so:
2fa-admin-interface

I made a gist with the (very-early-super-basic) idea of the GUI.

@GitHubUser4234 (correctly) objected that the force-state I was thinking about can be skipped if there is a checkbox like "force" for an entity.

More Ideas

@ChristophWurst wrote

to me, the grid view looks complex and overwhelming. Also I'm worried about real-world setups where you have thousands of users and numerous groups. The grid would be really long then.

No, it should not. The list will only contain entities that differ from the default state.

  • The GUI might be an exact copy of the user admin GUI - only with title's rotated by 90° to keep a nice look for multiple 2FAs. And the left panel showing "All", "Users", and "Groups".
  • Might be a good idea to provide an input for a username in admin to get the real config for a user (since there is a defaul conf, 0-n group confs and the user config itself; see below).
  • Perhaps there should also be an admin interface to see the enabled 2FA for a user.
  • About inheritance: It should be discussed how that should work (can a factor once beeing denied been reactivated? How about more than one group?). I would prefer a simple top-down inheritance but since we can have multiple groups for one user a simple "user overrides group overrides default" will not work. Might be suitable to get the strictest rule (that might contain configs from multiple groups).

References


What do you think? ;)

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions