I am implementing authorization for a REST service using Spring Security. I have roles that can be grouped in role groups.
In particular, I have VIEW_EMPLOYEE and EDIT_EMPLOYEE roles.
I have EmployeeController with two endpoints: readEmployee and updateEmployee. The updateEmployee endpoint is secured with the EDIT_EMPLOYEE role via the next Spring Security annotation: @Secured(EDIT_EMPLOYEE).
My question is about readEmployee: should I secure it with both VIEW_EMPLOYEE and EDIT_EMPLOYEE roles? Or just with VIEW_EMPLOYEE?
@Secured({VIEW_EMPLOYEE, EDIT_EMPLOYEE /* do I need it here? */})
@GetMapping("/employees/{id}")
Employee readEmployee(@PathVariable Long id) {
// ...
}
@Secured(EDIT_EMPLOYEE)
@PostMapping("/employees/{id}")
Employee updateEmployee(@PathVariable Long id, Employee employee) {
// ...
}
The first approach looks more natural to me: on the UI of my application, in order to edit an employee, I should first read it. This means that EDIT_EMPLOYEE role should implicitly allow to read employee as well.
On the other hand, the second approach (with just VIEW_EMPLOYEE) looks more maintainable: in future, every time I create a new read* endpoint, I should not keep in mind that I need to add an EDIT_* role to it as well.
Is there a best practice on what approach to use?