...
This is getting messy. I think we could use a more robust alternative to implement this. Here are three options I can think of:But first, here are the authorization checks we know of so far (described in terms of access to objects in the REST API, rather than through the several endpoints that are needed to expose each object in the API itself, and skipping participant-facing APIs):
Authorization Rules
Object | Assoc(1) | Role | Permissions(2) |
|---|---|---|---|
AccountSummary | |||
Android/AppleAppLink | |||
App | |||
AppConfig | |||
AppConfigElement | |||
Assessment | |||
AssessmentConfig | |||
Enrollment | |||
EnrollmentDetail | |||
ExternalResource | |||
FileMetadata/Revision | |||
HealthDataRecord(Ex3) | |||
MasterScheduleConfig | |||
NotificationMessage | |||
NotificationRegistration | |||
NotificationTopic | |||
OAuthProvider | |||
Organization | |||
RecordExportStatusRequest | |||
ReportData | |||
ReportIndex | |||
RequestInfo | |||
SchedulePlan | |||
SmsTemplate | |||
Study | |||
StudyConsent | |||
StudyParticipant | |||
Subpopulation | |||
Survey | |||
Tag | |||
Template/TemplateRevision | |||
Upload | |||
UploadSchema |
(1) = association of model object to some other object, which can have a different permission structure from editing the individual models, here R = read (the association only), A = add, R = remove. Only listed in one of the two directions in this table (should be the same either direction).
(2) C = create/write, R = read (list or detail object), U = update/write/delete logically, D = delete (physically)
Here are objects from the v2 domain model that have been designed far enough to think about permissions:
Object | Assoc | Role | Permissions | Note |
|---|---|---|---|---|
Protocol/Study Arms | ||||
Schedule | ||||
Session |
Spring Security
This is the most complex option available, but we could use the method-based security via annotations. Our service methods could declare the security using complex expression rules.
...