...
Our existing authentication and authorization have all been written from scratch, which means we’d need to overwrite all the core Spring Security classes before any of this would work;
The result would take time and involve learning a lot more about Spring Security;
Security exceptions would appear in places where we are now able to return InvalidEntityExceptions and the like. Possibly confusing to existing usersFor example empty/null/imaginary values are going to throw security exceptions. (I’m fine with this).
Implement a DSL
Nothing Spring does is that hard to duplicate with a DSL that uses our existing RequestContext. We should standardize on calling these checks in the controller or the services (both is leading to confusion for me). It could look something like this:
...
Easier to implement and understand at this point, when compared with overriding Spring Security’s implementation classes
Arguably, easier to understand because it’ll only contain what it necessary for our application (as opposed to Spring which is always more complicated because it can handle anything, including future requirements).
Cons:
...
More custom code for new developers to learn (assuming they already know Spring security which is more portable for them anyway);
We’re bearing down to how it is implemented)Still only in code and does not move permissions to a databasefurther on a custom implementation making that much harder later if we decide to abandon it for anything else. If we’re going to switch, better to switch sooner.
Recommit to implementing authorization in the controllers
...