Page Comparison

...

Implementation Considerations

Using 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 questions.

class Permission {
  String guid; // natural key makes create/add/update ambiguous
  String userId;
  String role;
  String objectType;
  String objectId; 
  
  // Object ID may need to be compound
  void setStudyObjectId(String appId, String studyId) {
    this.objectId = appId + ":" + studyId;
  }
}

Using Spring security for authorization (not authentication, at least initially) we would do the following:

1. In a filter, create a caller's Authentication object and put it in Spring Security's SecurityContext (exactly like what we've been doing with our own RequestContext, but we'd probably store the caller's permissions);

2. 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 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 parameters) to access the controller method. But because we can implement that "permit" 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. @IsDeveloper could do all of the above).

3. Remove our own static method call checks in AuthUtils. Eventually consider if we can remove RequestContext since it is 99% of the time being used to do authorization checks.

There will be top-level APIs to change permissions:

...