Spring Boot Security - konfiguracja z pliku

Nawet jak to będzie wyciągnięte do jakiejś klasy jako static, musisz w jakiś sposób zapewnić, że zmiany zostaną wszędzie zaciągnięte w postaci wdrożenia z nową wersją biblioteki. Więc IMHO to o czym pisze Shalom albo można zapewnić zrzucając odpowiedzialność za rejestrację route na zespół opiekujący się danym serwisem, albo jakiś mechanizm automatycznej aktualizacji routy w api-gateway.

Odnośnie sprawdzania uprawnień, skalowalnym podejściem jest autoryzacja na poziomie określonej domeny, której dotyczą te uprawnienia. Inaczej w api-gateway zrobi się śmietnik.

Moim zdaniem dobrą praktyką jest kontrola uprawnień jak najbliżej kodu wykonującego opreację lub danych (przydaje się w dużych projektach). Jeżeli będziesz sprawdzać uprawnienia na poziomie api gateway, to zawsze ktoś się może wstrzelić z boku. Często też wersje samych serwisów mogą sie rozjechać i nagle API jest dostępne dla wszystkich po niefortunnym wdrożeniu.

Jeśli chodzi o sprawdzanie uprawnień użytkownika to polecam użyć @EnableGlobalMethodSecurity(prePostEnabled=true) i pisać kod tak:

@Controller
public UserManagementController {

  @RequestMapping(method = RequestMethod.GET)
  @PreAuthorize("hasAuthority('CAN_LIST_USERS')")
  public List<RestUser> listUsers() {
    // ...
  }

  @RequestMapping(method = RequestMethod.POST)
  @PreAuthorize("hasAuthority('CAN_SUSPEND_USER')")
  public void suspendUser(@RequestParam UUID userId) {
    // ...
  }

}

Dodatkowo polecam używać ról jako kontenerów na uprawnienia (authorities). I w samym kodzie sprawdzać authorities. Przykładowo:

• ROLE_USER_MANAGEMENT zawiera
• CAN_LIST_USERS
• CAN_SUSPEND_USER
• CAN_CHANGE_USER_ROLES
• etc.

Dzięki temu zyskujesz elastyczność. Jeżeli trzeba dodać nową rolę to nie trzeba przerabiać wszystkich aplikacji, tylko definiujesz nową rolę i przypisane do niej uprawnienia.