Spring Security – security none, filters none, access PermitAll

1. Обзор

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

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

Spring Security – Роли и привилегии

2.

Настройка элемента с access=”PermitAll” настроит авторизацию так, чтобы все запросы были разрешены на этом конкретном пути:

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

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

Это достигается без отключения фильтров безопасности – они все еще работают, поэтому любые функции, связанные с безопасностью Spring, по-прежнему будут доступны.

3.

Это функция pre-Spring 3.1, которая была устаревшей и заменена в Spring 3.1.

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

Это может вызвать проблемы, когда для обработки запроса потребуется некоторая функциональность 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.

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

Область действия также изменилась – она больше не указывается на уровне элемента . Вместо этого Spring 3.1 позволяет определить несколько элементов – каждый со своей собственной конфигурацией цепочки фильтров безопасности. Таким образом, новый атрибут безопасности теперь находится на уровне элемента .

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

Или с конфигурацией Java:

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

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

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

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

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

Кроме того, access=’IS_AUTHENTICATED_ANONYMOUSLY’ может использоваться для разрешения анонимного доступа.

5. Предостережения для

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

Также обратите внимание, что если элемент не указывает шаблон , то по умолчанию он сопоставляется с универсальным шаблоном соответствия – “| * * ” – так что опять же этот элемент должен быть последним. Если порядок элементов неправильный, то создание цепочки фильтров безопасности завершится неудачей :

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” и .

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