...
The authorization model will be permissions-based, assigning list, view, and/or edit permissions vis-a-vis a specific target model;
These new permissions will be a separate table, not an association to an Account or any other record in the system…this is easier to graft onto the existing system. With some Hibernate sorcery, we can ensure that foreign key relationships are maintained and permissions are deleted when users and objects are deleted;
Permissions can be on objects (LIST, VIEW, or EDIT assessments, studies, organizations) but also on associations (VIEW or EDIT study sponsors, organization members) and rarely, on verbs (EDIT allowing for study launch). For example, the owner of an organization would have EDIT permission for the Organization and EDIT permission for the organization members. A member could have VIEW permissions over an organization’s sponsored studies. The permission to launch a study is very specific to that transformation of the state of the study.
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, further permissions will have to be added on a case-by-case basis;
We may need to will maintain ADMIN, WORKER, DEVELOPER, and RESEARCHER roles for our older APIs that are role-based (these will NOT be modeled in the new permissions table), but all newer v2 APIs should use this new permission structure, and the Roles STUDY_DESIGNER, STUDY_COORDINATOR, and ORG_ADMIN should be removed as part of this refactor. In addition:
Workers have their own APIs which bypass most security constraints and will continue to be implemented with the worker role;
Superadmins pass all security checks in both security systems;
App-scoped developer and researcher will no longer have study-scoped permissions;
App-scoped admins can still probably do anything within their app ;
System-scoped admins and workers can still do anything in any app. (Workers are always system-scoped.)
(so somewhat similar to super admins).
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 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. |
Secured objects/scopes
* = this is an association
Model/Association/Verb | Permission | Meaning |
|---|---|---|
Organization | VIEW | Can view information about the organization. |
EDIT | Can edit the organization | |
ADMIN | Can add/remove members of the organization as well as edit permission for the organization | |
OrganizationStudies | LIST | Can see the studies sponsored by the organization |
OrganizationMembers | LIST | Can see the members of an organization |
OrganizationAssessments | LIST | Can view the assessments of an organization |
Study | VIEW | Can view a study (not its participants). |
EDIT | Can edit the study | |
ADMIN | Can edit permissions for the study | |
StudyParticipants * | LIST | Can view a list of the participants in this study (AccountSummary objects) |
VIEW | Can view a study participant’s information | |
EDIT | Can edit the study participant’s information | |
ADMIN | Can create accounts and enroll them in the study. | |
Assessment | VIEW | Can view an assessment |
EDIT | Can edit an assessment | |
ADMIN | Can edit permissions for the assessment |
Here’s the old table
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. |
Assessment | Assessments are owned by organizations, not studies. Study members can read them, who can work with assessments? | |
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) |
...