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.
- Work is behind the
group_managed_accounts
feature flag. - The
saml_providers
table has theenforced_group_managed_accounts
column to enable/disable GMA. - The
users
table has themanaging_group_id
column to tie a user account to the managing group (Organization). - GMA depended on SSO Enforcement which is a current mechanism that "organization admins" can use to prevent unknown users in to their group/project hierarchy.
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 theprovisioned_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.