Use cases to be addressed by public release (May 2022):
Use case 1:
A researcher finds the MTB website and wants to try out the study building tools.
They need to register a Synapse account.
They should be able to create and design a study.
There should be a project in Synapse for that study.
They cannot access the Synapse project because their account is not validated.
They cannot add collaborators to their Synapse project (because they can’t see it).
They cannot launch their study because their account is not validate.
Use case 2:
The same researcher from use case 1 has already created a study and wants to access their Synapse data during design.
They need to validate their Synapse account.
After validation, they should be able to access the Synapse project.
They should be able to add collaborators to their Synapse project.
They can launch their study once validated.
Use case 3:
A researcher with a validated Synapse account wants to create a new study.
They should be able to create, design, and launch a study.
There should be a project in Synapse for that study.
They should be able to add collaborators to their Synapse project.
They should have access to the study data in Synapse.
Use case 4:
A researcher with a validated Synapse account and existing study wants to edit raw data in their Synapse project.
They should be able to edit the raw data. (This needs to be checked)
Use case 5:
A researcher with a validated Synapse account and existing study wants to add collaborators to their Synapse project.
They should be able to add collaborators with any level of permissions.
All collaborators need to be validated accounts.
Synapse allows permissions to be set at the project level. These permissions are summarized to view, download, edit, edit/delete, and administrator. Each level includes all access granted by the level before it. Notably, the administrator level is the only point where a user can adjust others' (or their own) permissions to the project. And the account that creates the project is automatically set as an administrator.
In use case 1, the researcher creates a study but can’t access the project. That means the researcher’s Synapse account can’t be used to create the project because it would be given administrator permissions. So the project will have to be created by a Bridge account (I’m going to call it BridgeAdmin, though there may be an existing account that would work).
An advantage of having BridgeAdmin act as the project creator is easier access for Bridge to update project permissions later. That covers use case 2, where the researcher has later validated their account and needs to be added to the project. And use case 3 is just cases 1 and 2 happening consecutively.
Checking Account Tiers
An issue in use cases 1 and 2 is how to check the researcher’s Synapse account tier (validated or not). It appears the Synapse Access and Compliance Team holds the keys. If BridgeAdmin were a member, it could query the verification submission endpoint for the researcher’s state history.
Granting Direct Project Permissions vs Using Teams
Use cases 4 and 5 are covered if the researcher is given administrator access to their project. They would have the ability to edit/delete data and they would be able to change other users' access to the project. There are two issues here. The researcher could bypass the Bridge and Synapse data change request processes. And the researcher could remove access from Bridge accounts like BridgeAdmin or BridgeExporter.
It’s possible to dodge both of these issues by using Synapse Teams. By creating a “Download Team” and making the researcher a manager of that team, the researcher would be able to grant other users download access through team invites. The researcher would not be able to give edit access to themselves or anyone. And they wouldn’t be able to remove BridgeAdmin or BridgeExporter permissions.
The downside to this method is it requires call and response steps to get the researcher into the team. This can still be automated, but it would require Bridge to be able to act on behalf of the researcher. Bridge would need authorization through OAuth to request team membership for the researcher. Then BridgeAdmin would grant that request and update the researcher’s role to manager.
Options for initial project permissions structure in Synapse:
Study Creator is a registered (or certified) Synapse user. When they create the study in Bridge, they do not have access to the project. No teams are automatically used.
Permission Level | Accounts |
|---|---|
Administrator | BridgeAdmin |
Edit/Delete | BridgeExporter |
Notes:
Project exists but prevents exploratory user in MTB from accessing test data while they are experimenting with the product.
Requires that the Study Creator can be added once they validate their Synapse account. Bridge would need to check for their account status before adding them to the project. This could be triggered through an API to grant access to study data.
This does not require Bridge to act on the Study Creator’s behalf.
Study Creator is already a validated Synapse user. When they create the study in Bridge, they can be added as a project administrator immediately. No teams are automatically used.
Permission Level | Accounts |
|---|---|
Administrator | BridgeAdmin Study Creator |
Edit/Delete | BridgeExporter |
Notes:
The study creator can make Teams to invite other users if they want.
The study creator can remove permissions from accounts that we need to retain access, like the exporter.
The study creator automatically has the ability to edit raw data.
This does not require Bridge to act on the Study Creator’s behalf through OAuth.
Study Creator is already a validated Synapse user. When they create the study in Bridge, they are added as a manager on a read access team.
Permission Level | Accounts |
|---|---|
Administrator | BridgeAdmin |
Edit/Delete | BridgeExporter |
Download Access Team | Study Creator (team manager) |
Notes:
Adding direct permissions (like Edit/Delete for BridgeExporter) is an easy, single step API call. Adding team members/managers is not.
Using the BridgeAdmin account, Bridge would create the Team with itself as a manager.
Bridge would have to gain permission to act on the Study Creator’s behalf using OAuth.
On the Study Creator’s behalf, Bridge would request access to the Download Access Team.
Bridge then grants access using BridgeAdmin.
Bridge updates Study Creator’s role on the team to Manager.
Bridge removes BridgeAdmin from the team. This is optional, but it seems cleaner in that the Study Creator is more clearly responsible for team management. If BridgeAdmin wanted to add more collaborators with download access, it can do it directly to project permissions instead of through the team invite mechanism.
This has the advantage of limiting the access the Study Creator has. They can view/download data and add collaborators through the team. But they cannot edit/delete data or remove permissions from Bridge accounts.
Earlier Draft:
Use case to be addressed by public release (May 2022):
...
When creating a study, it is related to a Synapse project (Is this currently a new project only for this study? Or is it a general MTB project?). As the researcher, I should have access to just my study’s data, but not all of MTB’s data. And I want the ability to add collaborators to my study.
Note that as a registered user in Synapse, the researcher can only create studies but not launch them at this point. But do they need to add other administrative users to their study at this point? And would those users need controlled access to Synapse?
How aware of Synapse account status (registered vs certified) do we need to be in Bridge?What roles can currently create studies in Bridge?
Issues with the process above:
...