...
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 and possibly also for viewing studies created by others in the organization. “Membership” in an organization could be modeled as a role that can list studies and users for the organization. You could then have more than one of these records and we could adjust what “being a member of an organization” means through the use of other roles in an organization. An organization admin for example as an ADMIN role that can do more with the organization itself, since our app is multi-tenanted. The roles related to organizations:
Role | Scope | |
|---|---|---|
Administrator | 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. |
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.
| Code Block | ||
|---|---|---|
| ||
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 roleFor object | |
|---|---|---|
DEVELOPER | APP DEVELOPERAPP | |
RESEARCHER | APP RESEARCHER | APP |
STUDY_DESIGNER | DEVELOPER | STUDY (one for every study sponsored by user’s organization; every admin user must be in an organization)STUDY DEVELOPER |
STUDY_COORDINATOR | STUDY RESEARCHER | STUDY (one for every study sponsored by user’s organization; every admin user must be in an organization) |
ORG_ADMINADMIN | ORGANIZATION ADMIN | |
ADMIN | APP ADMIN | |
SUPERADMIN | SYSTEM ADMIN | SYSTEM |
WORKER | SUPERADMIN | 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.
New roles
...
Role
...
For object
...
Description
...
MEMBER
...
Organization
...