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?
Proposal P1
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)
Proposal P1 Updates (09/08/2022)
Reverting back to users having possible membership in more one organization.
A few possible use cases:
A single user could be a maintainer of multiple organizations (e.g., multiple courses)
A single user could be a maintainer of one organization and a regular member of another
A single user could be a regular member of multiple organizations (e.g., again, multiple courses)
When a user leaves (or is removed from) an organization:
Their account remains in the same activation state, but they are no longer a member
This means that accounts that were initially approved by an org maintainer will remain active even after they leave the org (or the org is deleted). While this sounds like a loss of isolation due to the lack of organizational oversight, as long as the portal makes use of pools, those accounts will not be able to use testbed resources
I no longer think there should be a distinction between organization and personal accounts, based on the previous bullet
I have been updating the Identity server that Merge uses. It has the concept of, oddly, an identity associated with users. We could use this to add a few things to this proposal.
Create a new Organization Member identity. This ID would contain the name of the organization at account creation time. When a user registers an identity they will have a choice of an Organization account or a standard account. If they are a student they must choose Organization and fill in the class name.
The organization field will show up in the portal when a user account is being initialized. I propose that the portal initialize these identities in a different way than a standard identity. When the portal sees an Organization Member account, it automatically adds this user as a member of the organization given. And the user does not get a personal account. These accounts can be treated as organization only. If we update the policy for creating projects to Project Creators then, I think, the Org Member could not easily break out of the set of projects included in the organization. Non Org Members would still get a personal project and thus would be Project Creators and get the ability to create new projects.
The organization creator or maintainer role can access a list of organization accounts that are not initialized or activated. Policy will enforce that only an organization creator or maintainer is able to initialize and activate accounts that match their organization. (Maybe this is plumbed to mrg list users --organization <name>… and is shown in the Organization Launch page (TBD)).
If we update the policy for creating projects to Project Creators then, I think, the Org Member could not easily break out of the set of projects included in the organization.
Did you mean: set the policy for creating projects to “Organization Creators” (or Maintainers)?
I had envisioned projects still being created by organization members in the same way that non-org members create them. The reason being: if org members cannot themselves create projects, where would their experiments live? Do they live directly in the organization? Or does the org maintainer have to create projects for each individual user/use case that arises?
In my proposal, I don’t necessarily see an issue with org users being able to create projects. Their projects would only have access to whatever pool of resources is set as the Organization Pool. And if no such pool is set by the Org maintainer, projects in the Org will fall back to the default pool, which can be limited to a few resources or no resources at all.
The benefit is that there’s really very little change needed outside of (1) specifying an organization pool, and (2) adding the new identity type for Org Users.
By the way, I do like the idea of having separate identity types for Org users. That sounds nice and clean.
My thought was to set policy such that project creators could create projects. The idea was that non-org users would get a personal project created by the system and thus be Project Creators with respect to policy. Org users would not get a personal project and thus would not be Project Creators. This was not thought out, really. Limiting project creation is probably not a good idea.
I’ll work on the different classes of identities at account creation though. Any more we want to add? One wrench that may be thrown into the plan of different identity types may be third party identiies. A Google account will not have an “Organization” field. So we’ll have to shoe-horn this in elsewhere. Not sure how this will be done, but I’ll take a look.
Thinking through this again, my understanding is that the 3rd party services aren’t going to themselves provide portal membership types. The first time a user signs up, they’ll login through CILogon, Google, or whatever 3rd party service, but once they’ve logged in as such they will still be prompted to register an account on the portal.
So maybe it’s better not to have a notion of an Organization identity, but rather an Organization User. How that user is identified (Kratos, 3rd party, etc.) shouldn’t affect their status as a member of an org or not
3rd party services do provide membership types in a way. The information associated with an account is made available to kratos when a user authenticates against that service. The information usally includes first name, last name, email, username, maybe addess or phone number. They will not generally include an organization field - and certainly not “CS201” as an organization. So yeah, maybe all Org membership should be done within the portal. Org creators will be able to init/activate arbitrary accounts. Then add them as members via the same interface that members are added to projects.
Perhaps we can update the onboarding process. First time a user logs in after an init, we give an option to request to join Orgs and Projects. The Org/Project maintainers will then get prompted or notified about new member prospects. The API does have a State field (active/pending) on Member which we’ve not used yet. This could be used for this. If a user chooses to request Org/Project access they are added with pending state until Org/Project maintainers can activate them.
Yes, so separate steps for account registration and approval like we have now. Registration entails adding an identity to the portal (3rd party or local kratos). Once registered, an account can add itself to an organization and would be placed in the Pending state. Once approved by maintainer, it moves from Pending to Active in the org. And any time a member is set to active in an organization, their global UserState also moves to Active
Even without notifications this is something that org/project leaders should be able to see via mrg list users [--organization] [--project]
I guess we could follow the same process for projects, but this gives project leaders the ability to “approve” accounts and I haven’t thought through the implications of doing that. Merge ops retain authority to approve orgs, so having org maintainers approving is only delegating controls to orgs we’ve already approved. We don’t really have an equivalent process for projects.
Edit: Clarification, requesting project membership sounds fine and placing oneself in a project as Pending sounds fine. Also notifying project leaders about this would be good. Concern is only regarding the effect this has on a user’s global activation status
I like the idea of explicitly prompting users to request either an Organization account or a Personal account. I am guessing that in the majority of cases users will select an Organization. This is pretty much the only thing they should be able to do on the portal when their UserState is Pending (maybe a few other things like listing public projects)