mirror of
https://github.com/nextcloud/twofactor_gateway.git
synced 2026-04-25 09:05:55 +03:00
[GH-ISSUE #273] RFE: Admin settings to choose 2FA system #58
Labels
No labels
0. to triage
1. to develop
3. to review
blocked
bug
discussion
duplicate
enhancement
enhancement
gateway:signal
gateway:signal
gateway:signal
gateway:sms
gateway:telegram
hacktoberfest
help wanted
invalid
needs info
php
pull-request
question
technical debt
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/twofactor_gateway-nextcloud#58
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @putt1ck on GitHub (Aug 28, 2019).
Original GitHub issue: https://github.com/nextcloud/twofactor_gateway/issues/273
In an organisational deployment 2FA may be mandatory, and almost certainly the organisation will have a preferred (required!) 2FA solution. At that point it doesn't make sense to let the user have the choice of 2FA systems and the user settings section should have only the backup code.
So feature would be an admin section for the 2FA, where the admin chooses the 2FA solution, with some warnings as relevant to check that users have phone numbers, or whatever the dependency is, configured in the user's account.
Ideally the user account admin side will be extended to allow admins to add the related information on user creation.
@putt1ck commented on GitHub (Aug 28, 2019):
Had first go at upstream RFE to support this:
https://github.com/nextcloud/server/issues/16908
@ChristophWurst commented on GitHub (Aug 29, 2019):
Is this a request specifically for the gateway provider in general? Because in general admins choose which 2FA providers to enable.
@putt1ck commented on GitHub (Aug 29, 2019):
Enabled/not enabled still leaves the item listed in the user settings, so would be good for the ones not enabled to not be visible to avoid user confusion. But the main enhancement would be for the admin to be able to make the 2FA "just work" for the user; assumed in an org that the required user info is already available e.g. phone number.
So in the Signal scenario we're currently preferring we would have a user phone number in the user settings (right now that would have to be populated by DB query, but that's workable), then we enable Signal gateway and any user it's enabled for (by group) would already have the phone number set i.e. they go to log in next time and without any further effort on their part they get the Signal code request and it sent to their phone
@ChristophWurst commented on GitHub (Aug 29, 2019):
My concern with this is that one would have to assume that the phone/email/whatever info is correct. That's why we also use confirmation when a provider is enabled. We had a similar problem in the early days of TOTP. People enabled it but for various reasons the login afterwards never worked, hence people got locked out.
@putt1ck commented on GitHub (Aug 29, 2019):
In an org setting we have to assume that the info is correct, and it's a support issue (IT/admin) to resolve if not. Just like when users forget their username and password. So if the user is created with a believed correct 2FA ID and then can't login, it's no different than if they got their user details wrong in a non-2FA environment.
Maybe to facilitate setups where there's no support team involved in that way the verification requirement could be available as a config option "enable user verification" (enabled by default, tech support can always disable)?
@ChristophWurst commented on GitHub (Sep 10, 2019):
These are all very valid arguments. I'll therefore keep the ticket open in case someone wants to contribute the necessary features/code or a customer would like to have this feature implemented.