Skip to content

Organization Users

Requirements

Organization admin's require full control of their users. They want to:

  • Create organization user accounts
  • Modify organization user accounts
  • Destroy/decommission organization user accounts
  • Logout sessions owned by organization user accounts
  • Prevent organization user accounts from working outside their organization and/or control what is accessed outside their organization

These requirements are in essence solved on self managed because the GitLab Instance is the Organization and organization admins have total control.

Saas users require use of gitlab.com that is independent of their professional life. For example, they don't want to lose access to their account when they leave their job.

In terms of cells, we need to be able to move organization users seemlessly across cells despite cells being isolated from each other.

Previous attempts

For SaaS we have tackled this task to some degree already. Specifically, we modelled the MVC on the requirements of a large SaaS customer. These solutions treated the top level group (TLG) as what grouptenant scale today calls the Organization.

Group Managed Accounts (GMA)

First we built the now obsolete Group Managed Accounts (GMA). GMA tied a user account to an organization. It only worked with SSO logins, and only SAML specifically. When you were no longer employed by the organization you could not access that gitlab account.

Read more about GMA.

Enterprise Users (EU)

Then we built Enterprise Users (EU). EU was essentially GMA version 2, that reduced scope to avoid all the product problems now facing grouptenant scale around account sharing, hierarchy isolation, account ownership, etc. This also depends on SAML SSO and/or SCIM.

Read more about EU.
  • From the Enterprise Users epic:

    • This approach is different from Group Managed Accounts because it does not depend on group membership. Existing accounts will not automatically become managed if they join a group. Group administrators will have more flexibility over the level of control they wish to assert on those accounts.

    • The user_details table has the provisioned_by_group_id column to mark an Enterprise User.
    • Does not require SSO Enforcement to be enabled, unlike GMA.
    • Worked as a solution for a customer we were working with at the time.

Enterprise Users was motivated by the need to make SAML SSO integration with GitLab SaaS a better experience. Namely the ability for organization to:

  • Disable two-factor authentication within gitlab.com
  • Prevent users from creating groups and projects outside the corporate group
  • Bypass email confirmation for provisioned users

The problem with previous attempts

GMA gave organizations ownership of user accounts but at the expense of sharing an account with personal work. EU gives users ownership of accounts but at the expense of organizations having total account control.

Furthermore, both GMA and EU depend on the organization having SAML SSO.

Cells face the same challenges that GMA and EU both tried to solve. Cells will physically isolate organizations across cell boundaries but organization users will still need to move across cells.

Potential solutions

Organizations own users

When we bind a user to an Organization (i.e. GMA) we solve for isolation but prevent shared user accounts for personal use. Previous customer discussions and more recent UX research have higlighted the desire for users to exist independent of an organization.

Organizations link to users

When we link a user to an Organization (i.e. EU) we are effectively sharing the account, and we are then faced with the question of how exactly to share the account between the two entities. Who can delete the account? Who can change which settings and to what values? etc.

There is a concept of an Identity in our system that represents a user account's relationship to an identity provider. It's conceivable that we could use the Identity (or something similar) to create an "eclipsing user account" that covers the user's account and is owned by the organization. When would the Identity apply? Only when the user is within the organization? How about if working on an open source project (or client code base) outside of the organization hierarchy?

Sharing the user account may not be a satisfactory solution. User settings and features would probably have to be replicated, or for example an organization may not want any of their users to have the option to delete their accounts by themselves or if hacked.

Multiple user accounts

From a practical perspective, multiple accounts may be the only way forward. We can very clearly delineate ownership of an account, and through mechanisms that already exist, or appear to be reasonable to implement.

A personal account would function as it does today. An organization owned account would be subordinate to the organization administrators, as a self managed user is to a self managed administrator. This would require the creation of an organization admin role, which seems inevitable either way.

I envisage the user provision flow would be similar to how GMA worked. A user would visit gitlab.com/acme-co/login and go through a standard SSO or user/pass account creation process. There would also be a process to either claim users similar to how EU proves domain ownership on matching email address, and/or a reciprocal organization invite process.

The consequence of keeping accounts separate is that there's no single work history, todos, etc. In future it's conceivable that we could link user accounts.

At some point later down the road we could revisit the google style account switcher ( !48641 (diffs), #245220 (closed)) as a quality of life improvement for users.

Edited by Alex Pooley