Extend group managed accounts to all groups

Overview

We introduced the concept of group managed accounts in 12.1. This is a useful tool that essentially creates a "group-level user", which requires that a person use a particular user account to interact with a specific group. This is very useful for organizations who want to require a separate account for work in the group - this is a typical use case for GitLab.com, where a top-level group may represent a company.

Problem

The problem, however, is that we introduced the first iteration of this as a concept specific to SAML SSO. We should consider extending this "group-level user" idea to other groups without requiring the use of this authentication strategy.

The most glaring need for organizations using GitLab.com is to be able to assert more control over the users who are working within the company's group. Currently, users belong to the instance and companies don't have control over what they do:

• They're able to mix personal contributions/projects with their work,
• The actions they take aren't auditable (I have some visibility over their activity in my group, but I can't see everything they're doing on GitLab.com and have no control over projects in their personal namespace),
• I can't modify anything at the user level (standardize their name, email address, delete/block them as a user, etc).

Group managed accounts is essentially a "group-level user" that ties a user to a group, which would allow us to start allowing the owner of that group to do some/all of the above. At the moment, GMAs are used only with SAML SSO enforcement - but there's no compelling reason why they can't be used with groups regardless of their authentication strategy.

Proposal

• Allow any top-level group to require the use of a group managed account for work in the group.