...
The permission model will be permission-based, assigning a role vis-a-vis a specific target model (aka a “permission”);
These new permissions will still be assigned to a user (not modeled as an association between an Account record and any other record in the system…this is easier to implement but it means that permissions won’t be cascade deleted when the target objects are deleted, only when the account is deleted);
Organizations will principally be a means to communicate who can see whom in a multi-tenanted application. Accounts will be assignable to multiple organizations. Migrated accounts will be given permissions to the sponsored studies of that organization, and then going forward, a user further permissions will at least have the auditor role for all studies sponsored by all of their organizations (this is the only transitively assigned role we’ve identified at this time and even that is optional)have to be added on a case-by-case basis;
Bridge roles are hierarchical. Generally a user should have only one role vis-a-vis a model object. For example, being a
STUDY_DESIGNERimplies that you can read information about studies, like the auditor role. Every study designer does not also have to be an auditor.PI_AGENTcould be an example of an exception to this.Currently an app-scoped developer, researcher, or admin can operate on any model in the app that requires that role (or its scoped counterpart, like study designer). DO WE WANT TO AXE IS IT TIME TO REMOVE THIS?
Use Cases
Use Case | |
|---|---|
Permissions changes should register for users without them having to sign out and sign back in again | If cached they need to be separate from the session in Redis. Otherwise, reading them on each request would meet this requirement. |
New admin account created with a sandbox in which studies can be created/edited that are not visible to others | When an account creates a study, it will be made the admin of that study. Searching for lists of studies will only return studies for which the caller has a role (which might be transitively assigned through an organization, effectively saying that organization membership grants visibility to studies as well)at least the AUDITOR role. |
“Sandbox” can be converted to real study, with additional users in specific roles for that study | Admin of a study can add additional users. We have not specified how we will make a study an “evaluation” study but that would need to be removable. |
Study is extended by creating a new study | Admin of the new study would need to copy over all the permissions from the old study. Bridge’s APIs should make this straightforward to do. |
Add someone to a study’s administration team | Add a permission (a role vis-a-vis the study) to that study. |
Remove someone from a study’s administration team | Remove a permission (a role vis-a-vis the study) from that study. |
Create similar authorization model for assessments | We should be able to expand this approach to any other model object we want to secure. |
...
Model | Role | |
|---|---|---|
Organization | Administrator |
|
Organization | Member |
|
Study | Auditor | Can read information about the study and its schedule. Cannot edit anything and can’t see people. |
Study | Developer | Can read and edit the configuration of the study and its schedule. |
Study | Researcher | Can list, view, edit, delete, enroll and unenroll accounts in the study. |
Study | PI_Agent | 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. Can delete a study. |
Study | Admin | 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. |
App | Developer | Can access many APIs for the configuration of an app and related resources like app configs. |
App | Researcher | Can see all accounts in the system regardless of organization or study boundaries. |
App | Admin | Can call any API in the scope of the account’s app. |
Global | Worker | Can access APIs that specifically allow the worker to call across app boundaries without switching applications first. |
Global | Admin | Can do anything in any app, study, or organization (superadmin) |
...
| Code Block | ||
|---|---|---|
| ||
public class Permission {
String guid; // synthetic key makes create/add/update APIs easier
String appId; // this always has to be part of the query
String userId;
String role; // "admin", "developer"
String objectType; // "study", "organization", "app", "system"
String objectId; // "studyId", "orgId", "appId"
boolean transitive; // e.g. true if permission comes from org membership
// Suggested toString() descriptor (implicitly scoped to an app):
// "2rkp3nU7p8fjUTDVIgjT6T ∈ {organization:sage-bionetworks admin}"
} |
...