Безопасность контроллера (веб-запроса / antMatcher) против уровня метода (службы)

Question

В Spring Security я вижу, что URL защищен с помощью:

http
    .authorizeRequests()
        .antMatchers("/admin").hasRole("ADMIN");

Я также вижу, что есть защита уровня метода:

@PreAuthorize("hasRole('ADMIN')")

Используются ли antMatchers для защиты URLв то время как @PreAuthorize используется для защиты интерфейсов?

Если antMatcher уже защищает URL-адрес, который вызывает интерфейс, тогда зачем нужна отдельная защита метода интерфейса?

Не могли бы вы использоватьБезопасность уровня метода на контроллере как:

@PreAuthorize("hasRole('ADMIN')")
@GetMapping("/dashboard/person")
public String findEvent(Model model, HttpServletRequest request) {
....

Answer 1

Веб-безопасность и безопасность методов - это два разных способа защиты вашего приложения, см. Справочник по безопасности Spring :

Почему бы просто не использовать безопасность web.xml?

Предположим, вы разрабатываете корпоративное приложение на основе Spring.Есть четыре проблемы безопасности, которые вы обычно должны решать: аутентификация, безопасность веб-запросов, безопасность уровня обслуживания (т.е. ваши методы, которые реализуют бизнес-логику) и безопасность экземпляров объекта домена (то есть разные объекты домена имеют разные разрешения).С учетом этих типичных требований:

[...]

Безопасность веб-запроса: Спецификация сервлета обеспечивает подход для защиты URI вашего запроса.Однако эти URI могут быть выражены только в собственном формате пути ограниченного URI спецификации сервлета.Spring Security предоставляет гораздо более комплексный подход.Например, вы можете использовать пути Ant или регулярные выражения, вы можете рассматривать части URI, отличные от просто запрашиваемой страницы (например, вы можете учитывать параметры HTTP GET), и вы можете реализовать свой собственный источник данных конфигурации во время выполнения.Это означает, что безопасность вашего веб-запроса может динамически изменяться во время фактического выполнения вашего веб-приложения.

Уровень обслуживания и безопасность объекта домена: Отсутствие поддержки в сервлетеСпецификация безопасности уровня сервиса или безопасности экземпляра объекта домена представляет серьезные ограничения для многоуровневых приложений.Обычно разработчики либо игнорируют эти требования, либо реализуют логику безопасности в своем коде контроллера MVC (или, что еще хуже, внутри представлений).У этого подхода есть серьезные недостатки:

a. Разделение интересов: Авторизация является сквозной задачей и должна осуществляться как таковая.Контроллеры MVC или представления, реализующие код авторизации, усложняют тестирование логики контроллера и авторизации, затрудняют отладку и часто приводят к дублированию кода.

b. Поддержка расширенных клиентов и веб-сервисов: Если в конечном итоге необходимо поддерживать дополнительный тип клиента, любой код авторизации, встроенный в веб-слой, не подлежит повторному использованию.Следует учитывать, что экспортеры удаленного взаимодействия Spring экспортируют только бины уровня обслуживания (не контроллеры MVC).Так как такая логика авторизации должна быть расположена на уровне сервисов для поддержки множества типов клиентов.

c. Проблемы с наслоениями: Контроллер или представление MVC - это просто неправильный архитектурный уровень для реализации решений по авторизации, касающихся методов уровня служб или экземпляров объекта домена.Хотя Принципал может быть передан на уровень сервисов, чтобы он мог принять решение об авторизации, это может привести к дополнительному аргументу для каждого метода уровня сервисов.Более элегантный подход заключается в использовании ThreadLocal для хранения Принципала, хотя это, вероятно, увеличит время разработки до такой степени, что станет более экономичным (с точки зрения затрат и выгод) просто использовать выделенную инфраструктуру безопасности.

*+1036 * д. Качество кода авторизации: Часто о веб-фреймворках говорят, что они "облегчают делать правильные вещи и труднее делать неправильные".Каркасы безопасности одинаковы, потому что они разработаны абстрактно для широкого спектра целей.Написание собственного кода авторизации с нуля не обеспечивает «проверки проекта», которую могла бы предложить инфраструктура, а внутренний код авторизации, как правило, испытывает недостаток в усовершенствованиях, возникающих в результате широкого развертывания, экспертной оценки и новых версий.

Spring Security рекомендует метод защиты, см. Справочник по безопасности Spring :

10.1.4 Соответствие запросов и HttpFirewall

[...]

На практике мы рекомендуем использовать метод защиты на уровне сервисов для управления доступом к вашему приложению и не полагаться полностью на использование ограничений безопасности, определенных на уровне веб-приложений.URL-адреса меняются, и сложно учесть все возможные URL-адреса, которые может поддерживать приложение, и способы обработки запросов.Вы должны попытаться ограничиться использованием нескольких простых путей муравья, которые просты для понимания.Всегда старайтесь использовать подход «отрицать по умолчанию», когда у вас есть универсальный (/ или) подстановочный знак, определяемый последним и запрещающий доступ.

Безопасность, определенная на уровне обслуживания, гораздо более надежна и труднееОбход, поэтому вы всегда должны использовать параметры безопасности метода Spring Security.

Spring Security рекомендует применять защиту метода на уровне обслуживания, а не на отдельных веб-контроллерах, см. Ссылка на Spring Security :

Я добавил элемент Spring Security в контекст своего приложения, но если я добавлю аннотации безопасности к моим компонентам контроллера Spring MVC (действия Struts и т. Д.), То, похоже, они не имеютэффект.

[...]

Обычно мы рекомендуем применять метод защиты на уровне службы, а не на отдельных веб-контроллерах.