...
Method | URL | Description |
|---|---|---|
GET | /v1/permissions/{userId} | Get all permissions for a user. |
GET | /v1/permissions/{objectType}/{objectId} | Get all permissions for an object like organization, study, or app. |
POST | /v1/permissions | Create a permission for a specific object and user. Caller must be an admin for the object. Returns the object with a GUID. |
POST | /v1/permissions/{guid} | Update a permission (caller must be an admin for the object). |
DELETE | /v1/permissions/{guid} | Remove a permission for an object (caller must be an admin for the object). |
...
Spring Security
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. We need a table of permissions that can be used to answer the framework’s authorization questionsSpring security has nice support for annotation-based authorization constraints. I would suggest we switch to it and secure the system at a request level by annotating our controller methods. Spring provides an expression language we can use to declare our constraints, and we can even implement new methods in that constraint language, and Spring will delegate to our own code to answer authorization questions. But it would allow new developers to work with a technology that they have seen before and that is documented.
Using Spring security for authorization (not authentication, at least initially) we would do the following:
In a filter, create a caller's
Authenticationobject and put it in Spring Security'sSecurityContext(exactly like what we've been doing with our ownRequestContext, but we'd probably store the caller's permissions; we’d store the user’s ID and app ID);Add authorization annotations to all of our controller methods.
Spring has many choices, including annotations that will take expression languages and security check methods that we can write ourselves. I like that option a lot. So we We can basically do our security checks in these annotations, e.g.@PreAuthorize("permit('developer', #studyId)")- permit a developer for the study ID (taken from the method method’s parameters) to access the controller method. But because Because we can implement that "permit" the “permissions” method, we could also allow app developers, admins, and superadmins to pass this test, as we do now.
Another approach is to create custom annotations that bundle complicated expression rules (e.g.@IsDevelopercould do all of the above).we can carry over our specific business logic. Later we can hook in other authorization systems very cleanly this way.Remove our own static method call checks in
AuthUtils. Eventually consider if we can removeRequestContextsince it is 99% 90% of the time being used to do authorization checks.
...
Old role | New role | Description |
|---|---|---|
DEVELOPER | DEVELOPER, APP SCOPE | |
RESEARCHER | RESEARCHER, APP SCOPE | |
ADMIN | ADMIN, APP SCOPE | |
STUDY_DESIGNER | DEVELOPER, STUDY SCOPE | Create this role for every study currently sponsored by the account’s organization |
STUDY_COORDINATOR | RESEARCHER, STUDY SCOPE | Create this role for every study currently sponsored by the account’s organization |
PI_AGENT, STUDY SCOPECan move study into recruitment phase, can be made the administrator of data repository for study, must be verified Synapse user. | ||
ORG_ADMIN | ADMIN, ORGANIZATION SCOPE | |
MEMBER, ORGANIZATION SCOPE | Create this permission for the account’s member organization? Not sure if we want to duplicate like this. Maybe we do and drop the org membership column, allowing for an easy migration to membership in multiple organizations. | |
SUPERADMIN | ADMIN, SYSTEM SCOPE | |
WORKER | WORKER, SYSTEM SCOPE |
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.The steps would be:
Multiple organization membership
...