I'm curious. Wouldn't it make more sense to have this in core so that it can apply to all kind of two-factor auth?

Of course we need some way to handle the case where a plugin doesn't do any management itself (i.e. external Two-Factor Auth provider) but for stuff like U2F this seems also useful.

@ChristophWurst Thoughts?

Yes, that makes sense of course. Otherwise the logic has to be duplicated for other providers.

I also thought about that...

It would be okay in the core if you would be able to assign it to different 2FA Services and Users/Groups.

Imagine:
Group A. External Support Members. Have a TOTP-Device near and are forced to TOTP. Might also use SMS 2FA.
Group B. R&D Dept. No cell phones allowed. Have some sort of dongle for 2FA.
Group C. C?Os. Are barely able to remember their passwords. No sort of 2FA.

So you really have to have a good DB to be able to get that going. Not talking about the UI... ;-)

So you really have to have a good DB to be able to get that going. Not talking about the UI... ;-)

Yes, this might be a tricky. Therefore I suggest we take a look at other projects/platforms and how they designed it before we re-invent it here.

Didnt we want to move TOTP into the Server? 🤔@LukasReschke (...see Projects)

Didnt we want to move TOTP into the Server? 🤔@LukasReschke (...see Projects)

No

Didnt we want to move TOTP into the Server? 🤔@LukasReschke (...see Projects)

We wanted to make it officially supported. That doesn't mean it has to be moved nor installed by default ;-)

Ah ... I see the difference 😜😅

So you really have to have a good DB to be able to get that going. Not talking about the UI... ;-)

Yes, this might be a tricky. Therefore I suggest we take a look at other projects/platforms and how they designed it before we re-invent it here.

After looking around and thinking some time about how to UI that I assume that a table growing on x-axis with every 2fa-interface is one way to get a good overview.

Somehow like that

Basic top-down-inheritance: There's a "default" scope that can be overruled by per-group config that can be overruled by per-user config. If multiple group rules apply the most restrictive is taken into account.

There are 4 operation modes:
INHERIT where the next upper level rule applies
ALLOW where you are free to decide if you want to use that 2fa
DENY where you will not be able to use that 2fa even if you say please quite nicely
FORCE where the login force is only with you if you use that² 2nd factor

² if multiple FORCES apply one is forced to 2fa (in general) but can decide which way to go. You might even select a 2fa that was only ALLOWed to you and you opted in.

In addition the "FORCE" rule can somehow trigger a wizard to set up your second factor on next login while keeping you out of 2fa while none is set up...

See that gist for an idea of the data-structure (close-to-be-JSON) and the implementation (SCSS, JS).

I'm thinking about triggering a select2 after clicking on a table cell to select the mode. As select2 can show Images beside options it's also possible to display the current state with an icon that can be reused in the select.

After all: The overview does not display the resulting rule set as group-rules are not inherited to the user-rules (should they?). Dividing the overview into groups|users might be a solution (as that should be the information stored in DB). 2 tables even seem to be a better idea for bigger installations.

² if multiple FORCES apply one is forced to 2fa (in general) but can decide which way to go. You might even select a 2fa that was only ALLOWed to you and you opted in.

Why would it be allowed in the first place to assign multiple FORCE values to an entity? Wouldn't somehow contradict the spirit of the "2" in 2FA? ALLOW ok, but FORCE?

Why would it be allowed in the first place to assign multiple FORCE values to an entity?

To give the user the choice. It's the same way it works here at github. I can auth with my yubikey, but can also use my authenticator or a recovery code (that are in fact 3 different interfaces). I am forced to use one of these interfaces.

Wouldn't somehow contradict the spirit of the "2" in 2FA? ALLOW ok, but FORCE?

No. The 2 in 2FA is about a "second point-of-knowledge". As written: If you have multiple FORCED states you are free to take one of the available 2FA - you are not (even able) to use all FORCED 2FA.

To be clear: If you have only "allowed" options, you MIGHT use 2FA but are not forced to do so. You ARE forced if you opted in in one 2FA or (at least) one is configured to be forced on you.

I see, then it gives a somewhat sloppy feel when you can have different configurations (say config A=2xFORCE and 2xALLOW, config B=3xFORCE 1xALLOW) that actually don't make any difference in user experience.

Instead I for example would see a checkbox on the right site of each row saying "Force" that indicates that one of the ALLOW 2FA providers must be chosen during login. When ticked, at least one of the providers must be set to ALLOW. The FORCE mode can then be scrapped. This is just an example, maybe someone has another idea.

@boppy 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.

In any case, this should be discussed and implemented in the nc server repo, github.com/nextcloud/server. Could you please open an issue/PR there? Ideally we should discuss the design/architecture in an issue first. There we can also gather some feedback from the design team in regards to the user interface design.

@boppy ping ^ :-)

@ChristophWurst pong :-P
That's what I call a lag. 17h for a pong. Shame on my (also for taking more than a week to get back to that) ^^

Should we (💔) close this one in favor of nextcloud/server#2348?

no worries :-)

Thanks for opening that issue. Yes, let's continue the discussion there 🚀