Безопасность Spring для защиты уровня сервиса, уровня веб-сервиса или того и другого?

У меня есть API, который я открываю через REST, и я обдумываю, где разместить ограничения полномочий.
Я читал, что существует наилучшая практика защиты сервисного уровня, поскольку именно он выполняет работу, и вы не знаете, где он будет вызываться, но я не уверен, что является наилучшей практикой в ​​отношении WS. слой.
Одна из моих мыслей заключается в том, что мне нужна очень детализированная модель авторизации на уровне службы и очень грубая модель авторизации на уровне WS, чтобы свести к минимуму нарушение принципа DRY, с одной стороны, но при этом иметь некоторое представление о защита в глубину.

Пример:

Для ресурса Usersесть UserWSи UserService. Администраторы могут создавать/обновлять/удалять пользователей, а пользователи могут читать о других пользователях.
Предполагая, что UserWSпривязан к %root%/users, я определю URL-адрес перехватадля этого URL-адреса с полномочиями ROLE_USER, которые просто говорит, что вы должны быть пользователем, чтобы попасть туда, но сам сервисный уровень укажет конкретные полномочия для соответствующих методов.

Другие варианты:

• Установите одинаковые требования авторизации как для службы, так и для WS-
  Pro — вы будете как можно раньше отфильтровывать злоумышленников (и сохранять, например, преобразование параметров, если вы используете Spring MVC)
  Con- Дублирование конфигурации является проблемой обслуживания и подвержено ошибкам => проблема безопасности

• Поместите требования авторизации только на WS-
  Профильтровать как можно скорее, если исходит из WS
  Con- Уровень службы может использоваться в разных контекстах.

• Нанесите требования авторизации только на службу-
  Pro-Без дублирования
  Con- Накладные расходы, связанные с разрешением "прямо" неуместного запроса на уровень обслуживания

Был бы очень признателен за любые отзывы об опциях