MVC: Define the product requirements for 1st iteration

Background

The GitLab Duo add-ons require seat assignment to individual users to use. Today, for Self-managed customers seats can be assigned through the GitLab UI or through a rake task.

Many customers rely on user management protocols to assign GitLab seats. We'd like to extend these protocols to be used for GitLab Duo. Specifically, this issue will be used to define the requirements for Duo seat provisioning through LDAP (Lightweight Directory Access Protocol).

Notes about LDAP

• Once per day, GitLab runs a worker to check and update GitLab users against LDAP.
  • Ensure the user is still present in LDAP.
  • If the LDAP server is Active Directory, ensure the user is active (not blocked/disabled state). This check is performed only if active_directory: true is set in the LDAP configuration.
  • We should use this to check for Duo status having changed

Expected Customer Flows

New User, Duo seat available

1. Customer admin creates account for LDAP user.
2. On LDAP user account, customer admin specifies TBD Duo setting that indicates the user should be assigned a Duo seat.
3. When user is created in GitLab, if TBD Duo setting is enabled and a Duo add-on seat is available, we should create a user_add_on_assignment record for the user.

Requirements

• Customers should be able to assign Duo Add-on seat to LDAP User via LDAP group membership.

Decision

1. LDAP is only available in Self-Hosted instance (Self-managed/Dedicated)

2. We will add new attribute in the config file for LDAP to specify group(s) that will have automatic Duo add-on seat assigned

   gitlab_rails['ldap_servers'] = {
     'main' => {
       'group_base' => 'ou=groups,dc=example,dc=com',
       'admin_group' => 'my_admin_group',
       'duo_add_on_group' => ['my_duo_add_on_group_1'] # array?
       }
   }

   1. Question: Should we support multiple group or only single group to start?
      1. Answer: We can have it as array.

3. When the duo_add_on_group is set, it will be "Single Source of Truth" for "All LDAP enabled user".

4. Whenever a user signs in via LDAP, we check if the user is a member of the duo_add_on_group in LDAP server

   1. If the user, is member of the duo_add_on_group , we assign user a Duo Seat, if not already assigned.
   2. If user is not member of any duo_add_on_group server, we remove the Duo Seat of the user, if any.

5. This approach will not consider any user that is not LDAP enabled or does not use LDAP sign in.

6. The existing "Manual Duo User management" remain as it is, as it can be used to manage any non-LDAP user, if intended.

   1. This will also probably mean no frontend work required, for now.

Design

See Blueprint : Duo Add-on seat assignment via LDAP (#507449 - closed) for technical blueprint.