Merge v1 introduced the notion of an “Organization” to the Merge portal API. The intent is that organization maintainers can manage users as well as projects of their organization.
Perhaps the primary driver behind this feature is the educational use case. Consider, for example, a graduate networking course at USC. The idea is that the organization owner and/or maintainers (Professor/TAs) will create an organization for their class and then directly verify identities and initialize user accounts for students that are enrolled in the class. This is preferable to having a Merge portal operator in charge of approving student accounts for obvious reasons:
- Merge operators don’t typically know students or have access to course enrollee lists
- Students don’t know Merge operators or how to contact them
- If the number of classes is large, having a small number of Merge operators in charge of this presents a scalability problem
Organizations solve this by delegating authority to initialize accounts to organization maintainers. However, they present one possible complication which pertains to how the portal currently implements role based access control (RBAC) to testbed resource usage. Currently, resources can be divvied up into pools, and projects can be added to those pools allowing any experiments created in that project to be realized using resources from the pool. This model works well in the current portal implementation where organizations are not yet in use. The question is, how does the addition of organizations change (or does it change) how RBAC is implemented in Merge v1?
The current proposal is the following:
Each user account is a member of
any number of organizations (including 0)exactly 0 or 1 organization. When a user account is created, they may optionally specify a governing organization they are a member of. If an organization is listed, maintainers of that organization have ability to initialize the account and subsequently freeze should a need arise.
Each project will be owned by exactly 1 or 0 organizations.
- Projects may have members that are part of that organization, part of a different organization, or part of no organization at all.
- If a project is owned by an organization, maintainers of that organization are automatically set as maintainers of the project.
Experiments have no direct relationship to organizations. Experiments continue to be associated with exactly 1 project, and access to that experiment (including the ability to realize/materialize it) is based on membership in the project. Because organization maintainers are also project maintainers (for projects that indicate organization membership), organization maintainers will be able to access all projects. This may be useful for educational use cases, such as giving a professor/TA access to all projects created under the organization.
Pools will continue to operate in (mostly) the current fashion:
- All users can create pools, but only a facility commissioner can add resources from their facility to a pool
- All projects have exactly 0 or 1 pool.
- All pools can have any number of projects assigned to them. To add a project to a pool, a project owner needs to contact a facility operator to have them add the project to the pool.
- Projects with no pool use the portal’s default pool at realization time, which may or may not have any resources in it.
The one change pertaining to pools: Organizations may specify an organization pool for all projects created under that organization. The intent is to support this workflow:
- TA creates organization EC (“EduClass”)
- TA creates pool EP (“EduPool”)
- TA acquires resources for EP through out-of-band communication with testbed facility commissioner
- TA sets EP as the organization pool for EC
- For all projects created that list EC as the owning organization, those projects will automatically have EP set as the project pool. This will not require explicit approval from the facility commissioner.
Proposal P1 Updates (07/29/2022)
Each user account is a member of exactly 1 or 0 organizations. That is, a user account is either:
- a personal account (current accounts in Merge)
- an organizational account
There are differences between organizational and personal accounts:
- Personal accounts:
- can create projects with no governing organization
- can only be activated/frozen by Merge ops
- Organization accounts:
- can create projects, but all projects are “owned” by the governing organization
- can be activated/frozen by organization maintainers (as well as Merge ops)
- personal projects owned by organizational accounts are also owned by the governing organization
Having accounts in exactly one category prevents organizational users from breaking out of the isolating boundaries that organizations are meant to provide. Specifically, projects created by organizational members are owned by the organization (both personal projects and named projects), which means those projects use the organization’s pool.
It will still be possible for projects to manually specify a different pool, but gaining access to such a pool requires approval through the typical route (pool owner adds your project ID)
- Personal accounts: