Resetting two-factor authentication (2FA - sometimes known as multi-factor authentication or MFA) on GitLab.com today involves opening a ticket with GitLab support, and having a validated member of the customer's userbase "vouch" for the identity of the requestor. For our customers with large numbers of users, this can be a fairly common need.
Allowing group owners the ability to reset 2FA for members of the group would speed up this process and remove some of the ticket load from support.
NOTE: Since GMA is not a concept we're investing in at the moment an alternative approach to this issue will be covered here: #225767
When a Group Managed Account is locked-out due to a loss of their second-factor device, a Group Owner should be able to "reset" 2FA and provide the locked-out user with a way to re-pair with their second-factor device.
We could add a Disable button only visible to Group Owners on the members list, which is similar to how we handle it for Self-Managed Administrators:
Permissions and Security
Group Owners should be the role with access to this feature.
What is the type of buyer?
All .com customers that enable Group Managed Accounts (Silver/Gold).
Due to the security ramifications of this operation, it's probably a good idea to present new group members (just owners?) with a policy notice that they explicitly accept or authorize.
I think we'd actually want this as part of the process of accepting an invitation to a group for all users that's big and bold.
By joining this group, you're granting Owners in this group the ability to reset MFA on your account. Under the right conditions this could mean that an Owner in this group could take over your GitLab account, locking you out from any contributions you might have outside of this project.
Yes, I think the challenge here is doing this in a way that doesn't jeopardize the security of our users. I could belong to multiple groups, and it seems inadvisable that all the Owners of those groups have the ability to reset my 2FA.
I wouldn't want to make this generally available across any group. Group managed accounts seems like a way of accomplishing this, but the best approach here would be Spaces (cc @tipyn).
What if we limited this to only SCIM provisioned accounts? In that case it would really only be company provided accounts, and it would be unlikely that you'd be joining other types of groups.
Due to the potential security risk, I'd prefer to hold off on this until we implement a better administrative experience for SaaS customers. This is one of my priority admin functions to include in the first few iterations though as I understand the significant pain this causes both our customers and GitLab support.
Picking this back up. I feel more comfortable scheduling this now that we're getting closer to enabling Group Managed Accounts. We could consider implementing this for Groups with GMA enabled.
In terms of frontend/backend integration we will need an endpoint similar to disable_two_factor with a route something like /groups/{group_slug}/-/group_members/{user_id}/disable_two_factor. How does that sound @asubramanian1?
@tipyn Notice within the screenshot below, there is a tag "It's you". Do we really need to point this out to the user? It seems unnecessary to me, but I'd love to hear your thoughts.
@lmcandrew As for Group Managed accounts end user has a dedicated user account in this group and as group owner can be considered administrator, it sounds OK to me from a security point of view
(only in the GMA case). We must make sure that this event is audited and an email notification is sent to the end user (making aware in case of abuse). Ideally we also want to force the end user to reconfigure 2FA before being able to access anything else.