Skip to content
Snippets Groups Projects

Provisioned Accounts

    • Closed (promoted) Issue created by Melissa Ushakov @mushakov

    Problem to solve

    Enterprise customers on Gitlab.com want to be able to fully manage the entire lifecycle of users in their groups. This desire is both for efficiency and to protect their intellectual property. Typically, these customers will have centralized user management for their enterprise through an IdP like Okta or Azure and use GitLab SSO/SCIM.

    There are three ways that users can join a SAML enabled group today:

    1. Users are provisioned using SCIM and join the group when they follow a GitLab SAML URL
    2. Users create an account after following a GitLab SAML URL. The user links this new account to their SAML identity.
    3. Users already have a GitLab account and link it to their SAML identity when they follow a GitLab SAML URL

    Accounts that are newly provisioned for a group (scenarios 1 and 2 above) can be used to participate in any group/project in GitLab.com. Over time, they can collect intellectual property that doesn't belong to the organization they were provisioned for. Accounts that existed and were invited into a group (scenario 3) may have participated in other groups and contain intellectual property from another organization. This dynamic prevents us from allowing administrators for a SAML enabled group from fully managing users that are part of their group.

    Intended users

    User experience goal

    Proposal

    We draw a distinction between newly provisioned accounts (scenarios 1 and 2 above) and allow administrators additional rights to manage those users' accounts. In order to prevent accidental disclosure of intellectual property, those accounts cannot participate in other groups. They also should not be able to use personal namespace. When a user leaves their group, they should not be able to use the account anymore.

    Users that provision accounts for use with a group will have very clear messaging that this account is only for use with that group. Their welcome email will clearly state this. Since users will not be able to use the account with any other projects/groups the probability that they use this account for personal work is low.

    This approach is different from Group Managed Accounts because ONLY accounts that were newly provisioned in the context of a group can be administered by a group. Existing accounts CANNOT become managed.

    Questions

    • Why are we not pursuing Personas?
      • After spending time investigating the concept of profiles within an account, we discovered that the effort to make that solution is too high. We also heard a need from customers that accounts that were exclusive to their group was a hard requirement.
    • Can we iterate here with Group Managed Acccounts?
      • We'll need the SAML provisioning capabilities. This should be a stand-alone feature.
      • We don't need the workflow to make an account managed.
      • We don't need the special outer forks toggle. We already built this for all groups in this issue.
      • We'll need to make all SCIM created accounts also be marked as managed. Maybe this happens when they join the group?
      • A nice bonus will be the credential inventory!
    • What functionality needs to be there for an MVC?
      • Tying a provisioned account to their group.
      • Custom email notification explaining intended account usage.
      • In-app messaging on the first log in explaining intended account usage.
      • Prevent the newly provisioned account from creating projects/groups outside of the top-level namespace.
    • What's the transition for a group that starts account provisioning?
    • How do we resolve conflicts in account creation? Example: Someone created an account with their work email and now the enterprises SCIM system wants to create an account with that same email.

    Further details

    Permissions and Security

    Documentation

    Availability & Testing

    What does success look like, and how can we measure that?

    What is the type of buyer?

    Is this a cross-stage feature?

    Links / references

    Edited by Melissa Ushakov

    Designs

      Child items ...

      2. Activity

      Please register or sign in to reply