Spring Security - безопасности нет, фильтров нет, разрешение на доступВсе

Spring Security - безопасность отсутствует, фильтра нет, разрешение на доступВсе

1. обзор

Spring Security предоставляет несколько механизмов для настройки шаблона запроса как незащищенного или разрешающего весь доступ. В зависимости от каждого из этих механизмов - это может означать либо не запускать цепочку фильтров безопасности на этом пути, либо запускать цепочку фильтров и разрешать доступ.

Дальнейшее чтение:

Spring Security - роли и привилегии

Как сопоставить роли и привилегии для приложения Spring Security: настройка, аутентификация и процесс регистрации.

Spring Security для REST API

Как защитить REST API с помощью Spring Security - Конфигурация XML, web.xml, коды состояния HTTP для аутентификации и т. Д.

Spring Security Expressions - пример hasRole

Введение в выражение безопасности hasRole Spring: настройте веб-авторизацию по URL и на странице, а также метод безопасности с помощью @PreAuthorize.

**2. access=”permitAll”с**

Установка элемента<intercept-url> сaccess=”permitAll” настроит авторизацию так, чтобы все запросы былиallowed на этом конкретном пути:

Или через конфигурацию Java:

http.authorizeRequests().antMatchers("/login*").permitAll();

Это достигаетсяwithout disabling the security filters - они все еще работают, поэтому любые функции, связанные с Spring Security, по-прежнему будут доступны.

**3. filters=”none”с**

Это функция до Spring 3.1, которая былаdeprecated and replaced in Spring 3.1.

Атрибутfilters полностью отключает цепочку фильтров Spring Security на этом конкретном пути запроса:

Это может вызвать проблемы, когда обработка запроса потребует некоторых функций Spring Security.

Так как это устаревшая функция версий Spring, более новых, чем 3.0, использование ее с Spring 3.1 приведет к исключению времени выполнения при запуске:

SEVERE: Context initialization failed
org.springframework.beans.factory.parsing.BeanDefinitionParsingException:
Configuration problem: The use of "filters='none'" is no longer supported.
Please define a separate  element for the pattern you want to exclude
and use the attribute "security='none'".
Offending resource: class path resource [webSecurityConfig.xml]
    at o.s.b.f.p.FailFastProblemReporter.error(FailFastProblemReporter.java:68)

**4. security=”none”с**

Как мы видели в сообщении об ошибке выше, Spring 3.1 заменяетfilters=”none” новым выражением -security=”none”.

Область видимости также изменилась - она больше не указывается на уровне элемента<intercept-url>. Вместо этого Spring 3.1 позволяет определятьmultiple <http> elements - каждый со своей собственной конфигурацией цепочки фильтров безопасности. Итак, новый атрибут безопасности теперь принадлежит на уровне элемента<http>.

На практике это будет выглядеть так:

Или с настройкой Java:

web.ignoring().antMatchers("/resources/**");

Вместо старого

Подобноfilters=”none”, это также полностью отключит цепочку фильтров безопасности для этого пути запроса, поэтому, когда запрос обрабатывается в приложении, функции Spring Security будут недоступны.

Это не проблема для приведенных выше примеров, которые в основном имеют дело сserving static resources - где фактическая обработка не происходит. Однако, если запрос каким-либо образом обрабатывается программно, тогда функции безопасности, такие какrequires-channel, доступ к текущему пользователю или вызов защищенных методов, будут недоступны.

По той же причине нет смысла указывать дополнительные атрибуты для элемента<http>, который уже был настроен с помощьюsecurity=”none”, потому что этот путь запроса не защищен и атрибуты будут просто игнорироваться.

В качестве альтернативы можно использоватьaccess='IS_AUTHENTICATED_ANONYMOUSLY' для разрешения анонимного доступа.

5. Предостережения дляsecurity=”none”

При использовании нескольких элементов<http>, некоторые из которых настроены с помощьюsecurity=”none”, имейте в виду, что порядок, в котором эти элементы определены, важен. Мы хотим, чтобы сначала были конкретные пути<http>, а в самом конце они следовали универсальному шаблону.

Также обратите внимание, что если элемент<http>doesn’t specify a pattern, то по умолчанию он отображается на универсальный шаблон соответствия - «/*” – so again, this element needs to be last. If the order of the elements is not correct, the *creation of the security filter chain will fail:

Caused by: java.lang.IllegalArgumentException: A universal match pattern ('/**')
is defined  before other patterns in the filter chain, causing them to be ignored.
Please check the ordering in your  namespace or FilterChainProxy bean configuration
    at o.s.s.c.h.DefaultFilterChainValidator.checkPathOrder(DefaultFilterChainValidator.java:49)
    at o.s.s.c.h.DefaultFilterChainValidator.validate(DefaultFilterChainValidator.java:39)

6. Заключение

В этой статье обсуждаются варианты разрешения доступа к пути с помощью Spring Security с упором на различия междуfilters=”none”, security=”none” and access=”permitAll”.

Как обычно доступны примерыover on GitHub.

TOC