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):
As a researcher finding the MTB website, I want to try out the researcher tools, create a study, and see how it works. I would need to make an account. I expect that to be an MTB account, but it’s actually a Synapse account.
If I want to look at public assessments, I can do that anonymously. However, if I want to create a test study to see how it works, I will need to join an org. If I join an existing org, then I need an org admin to approve and assign roles. Otherwise, I would need to make a new org.
When creating a study, it is related to a Synapse 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?
Issues with the process above:
The researcher does not immediately have access to their Synapse project. They have to be invited to a team (by Alx or Dwayne) and set as a Team Manager.
Adding a new researcher to the study in Bridge does not automatically add them to a team in the Synapse project.
If an administrative user is in Bridge but not added through Synapse, can their Synapse ID be linked after the fact? Can user accounts in different apps in Bridge share a Synapse ID?
Note on current user administration:
When creating a study, Bridge creates a Synapse project with two teams, admin and read-only. The exporter has admin access. Giving another user access requires inviting them to a team and then optionally managing their role on the team. Adding members is a manual process. It’s possible that this could be managed through an API in Bridge.
Option for public release - make the creator of a study an admin of the related Synapse project
If the Synapse user of the actual study creator was used to create the Synapse project, then they would automatically be the admin.
When the study creator then adds other users to their study, Bridge should also be able to add those users to the related Synapse project through an invite to a team.
Problem: Dwayne pointed out that if the study creator is the admin on the project, they will have unlimited access to the data in the project. As in, they can edit the raw data.
Synapse is inaccessible for 1 hour a week. If someone makes user access changes in Bridge during that time, what problems could that cause? Is there a request queue that resolves later or would Synapse reject the call.
Bridge features and changes required:
Ability to ask Synapse for a user’s current permissions.
Ability to update a Synapse user’s project permissions.
Reworking study bootstrapping to use a study creator’s Synapse account.
Likely task - mapping permissions between Bridge roles and Synapse access control lists.
For instance, if someone has the Researcher role and access to studyA and studyB, does that indicate some default access to related projects in Synapse? Would they be expected to have read but not write access? Would a Study Coordinator automatically need read access as well?
Possible refactoring project - splitting the administrative and participant interfaces in Bridge.
Participants will not need access to Synapse at any time. So separating them would help keep the participant accounts from being affecting by changes to administrative account management.
Future option - have Synapse be the user accounts manager for administrative accounts in Bridge
Bridge resources could be included in Synapse’s ACL and Bridge administrative users' permissions could be tracked there. This would make Synapse the source for all access and identity control.
Simplifies user management for administrators using both Synapse and Bridge in tandem.
The most direct route to this would be treating a study/app as a resource and a Bridge Role as an access level. But that would require Synapse to allow that to be set in the first place, which seems like an odd requirement.
Bridge could require a full overhaul of how it manages administrative access in this case.