Валидация generic параметров в Spring контроллерах

Абсолютно согласен. Валидатор должен проверять корректность запроса (или его тела), а не доступ к сущности (И вернуть, к примеру HTTP 400). Для проверки секьюрити можно просто воспользоваться @PreAuthorize:

@PreAuthorize("@AccessService.checkAccess(#entityId)")
@RequestMapping(value = {"/entityName/{entityId}/get"}, method = RequestMethod.GET)
    @ResponseBody
    public Entity get(@PathVariable(value = "entityId") Integer entityId) {
        //возврат значения сущности по ID
    }

Далее написать секьюрити сервис, который проверит права доступа. В данном случае, при отсутствии доступа вернётся HTTP 403 Forbidden.

Путь запроса по внутренностям Spring Security

Спасибо, интересно. Пара моментов:

1. SecurityContextPersistenceFilter — думаю, что тут можно ещё упомянуть, что он не только заполняет SecurityContextHolder, но и сохраняет его значение обратно в репозиторий (в сессию в дефолтной имплементации) по окончании запроса. То есть, все манипуляции с SecurityContext во время запроса будут сохранены с помощью этого же фильтра.

2. Не вызывайте SecurityContextHolder.getContext().getAuthentication(); для получения текущего юзера

   
   По поводу этого пункта и своего HandlerMethodArgumentResolver — думаю, также можно упомянуть, что с четвертого спринга для этих целей есть аннотация @AuthenticationPrincipal и, соответственно, AuthenticationPrincipalArgumentResolver.
   

Настройка валидации DTO в Spring Framework

Согласен. Тем не менее, интересуют варианты реализации, общий каркас, скажем так.

Настройка валидации DTO в Spring Framework

Плюсую. Также интересуют более сложные варианты валидации. К примеру, если ли пользователь с таким именем уже в БД, валидация завязанная на несколько полей сразу и проч. Будет ли продолжение?
P.S. Также не нашёл аннотацию @Validation. Есть @Validated. Возможно перепутали?

Обработка ошибок в формате JSON со Spring Boot

Аннотация ServiceAdvice

— поправьте, пожалуйста, на ControllerAdvice.