Bridge v2 authorization model

Use Cases

Use Case
New admin account created with a sandbox in which studies can be created/edited that are not visible to others
“Sandbox” can be converted to real study, with additional users in specific roles for that study
Study is extended by creating a new study
Study recruits from existing user pool into a new study
Add someone to a study’s administration team
Remove someone from a study’s administration team
Create similar authorization model for assessments	We should be able to expand it to other things than studies, because it seems likely we’ll encounter something else that needs finer-grained authorization.

Organizations. “Teams” in Synapse impart an identical set of permissions to a project for a set of users. “Organizations” in Bridge are a scope for manipulating users, since our app is multi-tenanted. The roles related to organizations:

Role	Scope
Administrator	Organization	Can list, view, add and remove people from an organization. Can change any of the user ↔︎ study permissions of an account in the organization when the study is sponsored by the organization Can they edit an account in the organization?
Member	Organization	Can list people in the organization

Studies. Individuals can be given specific roles vis-a-vis a study.

Roles	Scope
Developer	Study	Can edit the configuration of the study and its schedule.
Researcher	Study	Can list, view, edit, delete, enroll and unenroll accounts in the study.
Governance	Study	Can move the study into a production stage, and can view the data being exported to a project in Synapse. User must be a validated Synapse user.
Admin	Study	Can do anything related to a study or its participants, and they can change users associated to the study or their roles in that association.

Other. These are legacy roles but there are still many APIs that require one of these roles, particularly around configuring an app:

Roles	Scope
Developer	App	Can access many APIs for the configuration of an app and related resources like app configs.
Researcher	App	Can see all accounts in the system regardless of organization or study boundaries.
Admin	App	Can call any API in the scope of the account’s app.
Worker	Global	Can access APIs that specifically allow the worker to call across app boundaries without switching applications first.
Superadmin	Global	Can do anything in any app, study, or organization.

Implementation Considerations

We’re reimplementing a lot of the functionality of Spring Security’s authorization support. It might be desirable to switch over rather than further implementing a custom solution. We need a table of permissions that can be used to answer the framework’s authorization questions.

class Permission {
  String userId;
  String role;
  String objectType;
  String objectId; 
  
  // Object ID may need to be compound
  void setStudyObjectId(String appId, String studyId) {
    this.objectId = appId + ":" + studyId;
  }
}

Migration

Existing roles can be expressed in the new permissions table in order to make the same kind of authorization checks. This can be done independently of allowing users to be in multiple organizations. For every administrative account in the system, we’d want to create entries based on their current roles:

Old role	New role
DEVELOPER	APP DEVELOPER
RESEARCHER	APP RESEARCHER
STUDY_DESIGNER	STUDY DEVELOPER
STUDY_COORDINATOR	STUDY RESEARCHER
ORG_ADMIN	ORGANIZATION ADMIN
ADMIN	APP ADMIN
SUPERADMIN	SYSTEM ADMIN
WORKER	SYSTEM WORKER

We’d need to update both representations of roles in both places (as part of accounts and part of permissions), move over to authorizing requests using the permissions table, and then remove the bridge code and finally, delete the AccountRoles table.