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. |
Assuming a generic authorization model (user → has permission → object), maybe we don’t need groups (or rather, that object could be a study and it could be a group). But we should look at other systems to see what it buys us. I think that practically, it’s difficult to grant read permissions to a group without a grouping construct (I create a new study and the system has to figure out who should be able to see it…that’s not easy with overlapping associations).
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.
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 | For object |
|---|---|---|
DEVELOPER | DEVELOPER | APP |
RESEARCHER | RESEARCHER | APP |
STUDY_DESIGNER | DEVELOPER | STUDY (one for every study sponsored by user’s organization; every admin user must be in an organization) |
STUDY_COORDINATOR | RESEARCHER | STUDY (one for every study sponsored by user’s organization; every admin user must be in an organization) |
ORG_ADMIN | ADMIN | ORGANIZATION |
ADMIN | ADMIN | APP |
SUPERADMIN | ADMIN | SYSTEM |
WORKER | SUPERADMIN | SYSTEM |
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.