Как работает Spring Security Filter Chain

Я понимаю, что безопасность Spring основывается на цепочке фильтров, которые будут перехватывать запрос, обнаруживать (отсутствовать) аутентификацию, перенаправлять на точку входа аутентификации или передавать запрос в службу авторизации и в конечном итоге позволят запросу либо попасть в сервлет, либо выдать исключение безопасности (не авторизованный или не авторизованный). DelegatingFitlerProxy склеивает эти фильтры вместе. Для выполнения своих задач они фильтруют службы доступа, такие как UserDetailsService и AuthenticationManager .

Ключевые фильтры в цепочке есть (в заказе)

• SecurityContextPersistenceFilter (восстанавливает аутентификацию из JSESSIONID)
• UsernamePasswordAuthenticationFilter (выполняет аутентификацию)
• ExceptionTranslationFilter (перехватывать исключения безопасности из FilterSecurityInterceptor)
• FilterSecurityInterceptor (может выдавать исключения аутентификации и авторизации)

Я запутался, как эти фильтры используются. Неужели для весны, предоставленной формы входа в систему, UsernamePasswordAuthenticationFilter используется только для / login , а последние фильтры - нет? Имеет ли форма-Войти элемент пространства имен автоматической настройки этих фильтров? Каждый запрос (аутентифицированный или нет) достигает FilterSecurityInterceptor для URL, не входящего в систему?

Что, если я хочу защитить свой REST API с помощью JWT-токена , который извлекается из логина? Я должен настроить два тега конфигурации пространства имен http, права? Один для / логин с UsernamePasswordAuthenticationFilter, а другой для REST URL, с пользовательскими JwtAuthenticationFilter.

Создает ли настройка двух httpэлементов два springSecurityFitlerChains? Является ли UsernamePasswordAuthenticationFilterпо умолчанию отключено, пока я не объявляю form-login? Как мне заменить SecurityContextPersistenceFilterфильтр, который получит Authenticationиз существующих, JWT-tokenа не JSESSIONID?

Цепочка фильтров безопасности Spring - очень сложный и гибкий двигатель.

Ключевые фильтры в цепочке есть (в заказе)

• SecurityContextPersistenceFilter (восстанавливает аутентификацию из JSESSIONID)
• UsernamePasswordAuthenticationFilter (выполняет аутентификацию)
• ExceptionTranslationFilter (перехватывать исключения безопасности из FilterSecurityInterceptor)
• FilterSecurityInterceptor (может выдавать исключения аутентификации и авторизации)

Изучив текущую документацию стабильного выпуска 4.2.1 , раздел 13.3 Упорядочение фильтров, вы можете увидеть организацию фильтров всей цепочки фильтров:

13.3 Порядок фильтров

Порядок, в котором фильтры определяются в цепочке, очень важен. Независимо от того, какие фильтры вы на самом деле используете, порядок должен быть следующим:

1. ChannelProcessingFilter , потому что может потребоваться перенаправление на другой протокол

2. SecurityContextPersistenceFilter , поэтому SecurityContext может быть установлен в SecurityContextHolder в начале веб-запроса, а любые изменения в SecurityContext могут быть скопированы в HttpSession, когда веб-запрос заканчивается (готов для использования со следующим веб-запросом)

3. ConcurrentSessionFilter , потому что он использует функциональность SecurityContextHolder и должен обновить SessionRegistry, чтобы отразить текущие запросы от участника

4. Механизмы обработки аутентификации - UsernamePasswordAuthenticationFilter , CasAuthenticationFilter , BasicAuthenticationFilter и т. Д., Так что SecurityContextHolder можно изменить, чтобы он содержал действительный токен запроса аутентификации

5. SecurityContextHolderAwareRequestFilter , если вы используете его для установки Spring Security известно HttpServletRequestWrapper в ваш контейнер сервлетов

6. JaasApiIntegrationFilter , если JaasAuthenticationToken находится в SecurityContextHolder это будет обрабатывать FilterChain как субъект в JaasAuthenticationToken

7. RememberMeAuthenticationFilter , так что если более ранний механизм обработки аутентификации не обновил SecurityContextHolder, а запрос представляет файл cookie, который позволяет запускать сервисы запомнить меня, туда будет помещен подходящий запомненный объект аутентификации.

8. AnonymousAuthenticationFilter , так что если ранее механизм обработки аутентификации не обновлял SecurityContextHolder, туда будет помещен анонимный объект аутентификации

9. ExceptionTranslationFilter , для перехвата любых исключений Spring Security, чтобы можно было либо вернуть ответ об ошибке HTTP, либо запустить соответствующий AuthenticationEntryPoint.

10. FilterSecurityInterceptor , для защиты веб-URI и создания исключений, когда доступ запрещен

Теперь я постараюсь ответить на ваши вопросы один за другим:

Я запутался, как эти фильтры используются. Неужели для весны, предоставленной формы входа в систему, UsernamePasswordAuthenticationFilter используется только для / login, а последние фильтры - нет? Элемент пространства имен form-login автоматически настраивает эти фильтры? Каждый запрос (аутентифицированный или нет) достигает FilterSecurityInterceptor для URL, не входящего в систему?

Как только вы настраиваете <security-http>раздел, для каждого из них вы должны как минимум предоставить один механизм аутентификации. Это должен быть один из фильтров, которые соответствуют группе 4 в разделе 13.3 «Порядок фильтров» из документации Spring Security, на которую я только что ссылался.

Это минимальный действительный элемент безопасности: http, который можно настроить:

<security:http authentication-manager-ref="mainAuthenticationManager" 
               entry-point-ref="serviceAccessDeniedHandler">
    <security:intercept-url pattern="/sectest/zone1/**" access="hasRole('ROLE_ADMIN')"/>
</security:http>

Просто сделав это, эти фильтры настраиваются в прокси цепочки фильтров:

{
        "1": "org.springframework.security.web.context.SecurityContextPersistenceFilter",
        "2": "org.springframework.security.web.context.request.async.WebAsyncManagerIntegrationFilter",
        "3": "org.springframework.security.web.header.HeaderWriterFilter",
        "4": "org.springframework.security.web.csrf.CsrfFilter",
        "5": "org.springframework.security.web.savedrequest.RequestCacheAwareFilter",
        "6": "org.springframework.security.web.servletapi.SecurityContextHolderAwareRequestFilter",
        "7": "org.springframework.security.web.authentication.AnonymousAuthenticationFilter",
        "8": "org.springframework.security.web.session.SessionManagementFilter",
        "9": "org.springframework.security.web.access.ExceptionTranslationFilter",
        "10": "org.springframework.security.web.access.intercept.FilterSecurityInterceptor"
    }

Примечание: я получаю их, создав простой RestController, который @Autowires FilterChainProxy и возвращает его содержимое:

    @Autowired
    private FilterChainProxy filterChainProxy;

    @Override
    @RequestMapping("/filterChain")
    public @ResponseBody Map<Integer, Map<Integer, String>> getSecurityFilterChainProxy(){
        return this.getSecurityFilterChainProxy();
    }

    public Map<Integer, Map<Integer, String>> getSecurityFilterChainProxy(){
        Map<Integer, Map<Integer, String>> filterChains= new HashMap<Integer, Map<Integer, String>>();
        int i = 1;
        for(SecurityFilterChain secfc :  this.filterChainProxy.getFilterChains()){
            //filters.put(i++, secfc.getClass().getName());
            Map<Integer, String> filters = new HashMap<Integer, String>();
            int j = 1;
            for(Filter filter : secfc.getFilters()){
                filters.put(j++, filter.getClass().getName());
            }
            filterChains.put(i++, filters);
        }
        return filterChains;
    }

Здесь мы можем видеть, что, просто объявив <security:http>элемент с одной минимальной конфигурацией, все фильтры по умолчанию включены, но ни один из них не относится к типу аутентификации (4-я группа в разделе 13.3 «Порядок фильтров»). Таким образом, на самом деле это означает, что просто объявив security:httpэлемент, SecurityContextPersistenceFilter, ExceptionTranslationFilter и FilterSecurityInterceptor автоматически конфигурируются.

Фактически, должен быть настроен один механизм обработки аутентификации, и даже бины пространства имен безопасности обрабатывают заявки на это, выдавая ошибку во время запуска, но это можно обойти, добавив атрибут entry-point-ref в <http:security>

Если я добавлю базовое <form-login>в конфигурацию, то так:

<security:http authentication-manager-ref="mainAuthenticationManager">
    <security:intercept-url pattern="/sectest/zone1/**" access="hasRole('ROLE_ADMIN')"/>
    <security:form-login />
</security:http>

Теперь filterChain будет выглядеть так:

{
        "1": "org.springframework.security.web.context.SecurityContextPersistenceFilter",
        "2": "org.springframework.security.web.context.request.async.WebAsyncManagerIntegrationFilter",
        "3": "org.springframework.security.web.header.HeaderWriterFilter",
        "4": "org.springframework.security.web.csrf.CsrfFilter",
        "5": "org.springframework.security.web.authentication.UsernamePasswordAuthenticationFilter",
        "6": "org.springframework.security.web.authentication.ui.DefaultLoginPageGeneratingFilter",
        "7": "org.springframework.security.web.savedrequest.RequestCacheAwareFilter",
        "8": "org.springframework.security.web.servletapi.SecurityContextHolderAwareRequestFilter",
        "9": "org.springframework.security.web.authentication.AnonymousAuthenticationFilter",
        "10": "org.springframework.security.web.session.SessionManagementFilter",
        "11": "org.springframework.security.web.access.ExceptionTranslationFilter",
        "12": "org.springframework.security.web.access.intercept.FilterSecurityInterceptor"
    }

Теперь эти два фильтра org.springframework.security.web.authentication.UsernamePasswordAuthenticationFilter и org.springframework.security.web.authentication.ui.DefaultLoginPageGeneratingFilter создаются и настраиваются в FilterChainProxy.

Итак, теперь вопросы:

Неужели для весны, предоставленной формы входа в систему, UsernamePasswordAuthenticationFilter используется только для / login, а последние фильтры - нет?

Да, он используется, чтобы попытаться завершить механизм обработки входа в систему, если запрос соответствует URL-адресу UsernamePasswordAuthenticationFilter. Этот URL-адрес может быть настроен или даже изменен в соответствии с каждым запросом.

Вы также можете иметь более одного механизма обработки аутентификации, настроенного в одном и том же FilterchainProxy (например, HttpBasic, CAS и т. Д.).

Элемент пространства имен form-login автоматически настраивает эти фильтры?

Нет, элемент form-login настраивает UsernamePasswordAUthenticationFilter, и в случае, если вы не предоставляете URL-адрес страницы входа, он также настраивает org.springframework.security.web.authentication.ui.DefaultLoginPageGeneratingFilter, который заканчивается простым автоматически сгенерированным входом в систему. стр.

Другие фильтры автоматически настраиваются по умолчанию, просто создав <security:http>элемент без security:"none"атрибута.

Каждый запрос (аутентифицированный или нет) достигает FilterSecurityInterceptor для URL, не входящего в систему?

Каждый запрос должен достигать его, так как это элемент, который заботится о том, имеет ли запрос право на получение запрошенного URL. Но некоторые из фильтров, обработанных ранее, могут остановить обработку цепочки фильтров, просто не вызывая FilterChain.doFilter(request, response);. Например, фильтр CSRF может остановить обработку цепочки фильтров, если в запросе отсутствует параметр csrf.

Что, если я хочу защитить свой REST API с помощью JWT-токена, который извлекается из логина? Я должен настроить два тега http конфигурации пространства имен, права? Другой для / логин с UsernamePasswordAuthenticationFilter, и другой для REST URL, с обычаем JwtAuthenticationFilter.

Нет, вы не обязаны делать это. Вы можете объявить оба UsernamePasswordAuthenticationFilterи один и JwtAuthenticationFilterтот же элемент http, но это зависит от конкретного поведения каждого из этих фильтров. Оба подхода возможны, и какой из них выбрать в конечном итоге зависит от собственных предпочтений.

Создает ли конфигурация двух элементов http два элемента springSecurityFitlerChains?

Да, это правда

Имя пользователяPasswordAuthenticationFilter отключено по умолчанию, пока я не объявлю форму входа в систему?

Да, вы могли видеть это в фильтрах, поднятых в каждом из конфигов, которые я выложил

Как заменить SecurityContextPersistenceFilter на один, который будет получать аутентификацию от существующего JWT-токена, а не JSESSIONID?

Вы можете избежать SecurityContextPersistenceFilter, просто настроив стратегию сессии в <http:element>. Просто настройте так:

<security:http create-session="stateless" >

Или, в этом случае вы можете перезаписать его другим фильтром, вот так внутри <security:http>элемента:

<security:http ...>  
   <security:custom-filter ref="myCustomFilter" position="SECURITY_CONTEXT_FILTER"/>    
</security:http>
<beans:bean id="myCustomFilter" class="com.xyz.myFilter" />

РЕДАКТИРОВАТЬ:

Один вопрос о том, что «в одной и той же FilterchainProxy может быть настроено несколько механизмов обработки аутентификации». Будет ли последняя перезаписывать аутентификацию, выполняемую первой, если объявляет несколько фильтров (реализация Spring)? Как это связано с наличием нескольких поставщиков аутентификации?

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

Но это не обязательно произойдет. У меня есть несколько производственных случаев в защищенных REST-сервисах, где я использую токен авторизации, который может быть предоставлен как в виде заголовка Http, так и внутри тела запроса. Поэтому я настраиваю два фильтра, которые восстанавливают этот токен, в одном случае из заголовка Http, а в другом - из тела запроса собственного запроса покоя. Это правда, что если один http-запрос предоставляет этот токен аутентификации как в виде заголовка Http, так и внутри тела запроса, оба фильтра будут пытаться выполнить механизм аутентификации, делегируя его менеджеру, но этого можно легко избежать, просто проверяя, является ли запрос уже аутентифицированы только в начале doFilter()метода каждого фильтра.

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

И напротив, у меня тоже есть сценарий, в котором я публикую только один UsernamePasswordAuthenticationFilter, но учетные данные пользователя могут содержаться в БД или LDAP, поэтому у меня есть два поддерживаемых провайдера UsernamePasswordAuthenticationToken, и AuthenticationManager делегирует любую попытку аутентификации от фильтра поставщикам последовательно проверять полномочия.

Поэтому я думаю, что ясно, что ни количество фильтров аутентификации не определяет количество поставщиков аутентификации, ни количество провайдеров не определяет количество фильтров.

Также в документации говорится, что SecurityContextPersistenceFilter отвечает за очистку SecurityContext, что важно из-за пула потоков. Если я пропущу это или предоставлю пользовательскую реализацию, я должен выполнить очистку вручную, верно? Есть ли больше подобных ошибок при настройке цепочки?

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

В SecurityContextPersistenceFilter делегаты в SecurityContextRepository реализации Поиски SecurityContext. По умолчанию используется HttpSessionSecurityContextRepository , но это можно изменить с помощью одного из конструкторов фильтра. Поэтому может быть лучше написать SecurityContextRepository, который соответствует вашим потребностям, и просто настроить его в SecurityContextPersistenceFilter, полагаясь на его проверенное поведение, а не начинать все с нуля.

UsernamePasswordAuthenticationFilterиспользуется только для /login, а последние фильтры нет?

Нет, UsernamePasswordAuthenticationFilterрасширяет AbstractAuthenticationProcessingFilter, и это содержит RequestMatcher, что означает, что вы можете определить свой собственный URL-адрес обработки, этот фильтр обрабатывает только RequestMatcherсовпадения URL-адреса запроса, URL-адрес обработки по умолчанию - /login.

Более поздние фильтры все еще могут обрабатывать запрос, если он UsernamePasswordAuthenticationFilterвыполняется chain.doFilter(request, response);.

Подробнее о сборщиках сердечника

Элемент пространства имен form-login автоматически настраивает эти фильтры?

UsernamePasswordAuthenticationFilterсоздается <form-login>, это стандартный фильтр Псевдонимы и заказ

Каждый запрос (аутентифицированный или нет) достигает FilterSecurityInterceptor для URL, не входящего в систему?

Это зависит от того, успешны ли ранее установщики, но FilterSecurityInterceptorобычно ли это последний установщик.

Создает ли конфигурация двух элементов http два элемента springSecurityFitlerChains?

Да, у каждого fitlerChain есть RequestMatcher, если он RequestMatcherсоответствует запросу, запрос будет обработан установщиками в цепочке соответствия.

По умолчанию RequestMatcherсоответствует всем запросам, если вы не настроили шаблон, или вы можете настроить конкретный URL ( <http pattern="/rest/**").

Если вы хотите узнать больше о сборщиках, я думаю, вы можете проверить исходный код в Spring Security. doFilter(ServletRequest request, ServletResponse response, FilterChain filterChain)

Spring security - это основанная на фильтрах инфраструктура, которая устанавливает WALL (HttpFireWall) перед вашим приложением в терминах прокси-фильтров или bean-компонентов, управляемых Spring. Ваш запрос должен пройти через несколько фильтров, чтобы добраться до вашего API.

Последовательность выполнения в Spring Security

1. WebAsyncManagerIntegrationFilter Обеспечивает интеграцию между SecurityContext и WebAsyncManager Spring Web.
   

2. SecurityContextPersistenceFilterЭтот фильтр будет выполняться только один раз для каждого запроса, заполняет SecurityContextHolder информацией, полученной из сконфигурированного SecurityContextRepository до запроса, и сохраняет ее в хранилище после завершения запроса и очистки держателя контекста.
   Запрос проверен на существующий сеанс. Если новый запрос, SecurityContext будет создан в противном случае, если запрос имеет сеанс, тогда существующий контекст безопасности будет получен из репозитория .

3. HeaderWriterFilter Реализация фильтра для добавления заголовков к текущему ответу.

4. LogoutFilterЕсли URL-адрес запроса /logout(для конфигурации по умолчанию) или если в запросе RequestMatcherнастроены выражения URL-адресов, LogoutConfigurerто

   • очищает контекст безопасности
   • делает сессию недействительной
   • удаляет все куки с именами куки, настроенными в LogoutConfigurer
   • Перенаправляет на стандартный URL-адрес успешного /выхода из системы или настроенный URL-адрес выхода из системы или вызывает настроенный logoutSuccessHandler.

5. UsernamePasswordAuthenticationFilter

   • Для любого URL-адреса запроса, кроме loginProcessingUrl, этот фильтр не будет обрабатываться дальше, но цепочка фильтров просто продолжается.
   • Если запрошенный URL является матчами (должно быть HTTP POST) по умолчанию /loginили спички , .loginProcessingUrl()настроенные в FormLoginConfigurerто UsernamePasswordAuthenticationFilterаутентификации попыток.
   • параметры по умолчанию форма Логин являются имя пользователя и пароль, могут быть перекрыты usernameParameter(String), passwordParameter(String).
   • установка .loginPage() переопределений по умолчанию
   • При попытке аутентификации
     • Authenticationобъект ( UsernamePasswordAuthenticationTokenили любая реализация Authenticationв случае пользовательского фильтра AUTH) создается.
     • и authenticationManager.authenticate(authToken)будет вызван
       
     • Обратите внимание, что мы можем настроить любое количество методов AuthenticationProviderпроверки подлинности, которые проверяются всеми провайдерами аутентификации, и проверяют любой supportsобъект authToken / authentication провайдера аутентификации, для аутентификации будет использоваться поддерживающий провайдер аутентификации. и возвращает объект Аутентификация в случае успешной аутентификации, которую еще выбрасывает AuthenticationException.
   • Если сессия аутентификации будет успешно создана и authenticationSuccessHandlerбудет вызвана, которая перенаправляет на целевой URL-адрес настроен (по умолчанию это /)
   • Если аутентификация не удалась, пользователь становится неаутентифицированным пользователем и цепочка продолжается.

6. SecurityContextHolderAwareRequestFilter, если вы используете его для установки HttpServletRequestWrapper с поддержкой Spring Security в свой контейнер сервлета

7. AnonymousAuthenticationFilterОпределяет, нет ли объекта Security Authentication в SecurityContextHolder, если объект аутентификации не найден, создает Authenticationobject ( AnonymousAuthenticationToken) с предоставленными полномочиями ROLE_ANONYMOUS. Это AnonymousAuthenticationTokenоблегчает выявление неаутентифицированных пользователей последующих запросов.
   

DEBUG - /app/admin/app-config at position 9 of 12 in additional filter chain; firing Filter: 'AnonymousAuthenticationFilter'
DEBUG - Populated SecurityContextHolder with anonymous token: 'org.springframework.security.authentication.AnonymousAuthenticationToken@aeef7b36: Principal: anonymousUser; Credentials: [PROTECTED]; Authenticated: true; Details: org.springframework.security.web.authentication.WebAuthenticationDetails@b364: RemoteIpAddress: 0:0:0:0:0:0:0:1; SessionId: null; Granted Authorities: ROLE_ANONYMOUS' 

8. ExceptionTranslationFilterдля перехвата любых исключений Spring Security, чтобы можно было либо вернуть ответ об ошибке HTTP, либо запустить соответствующий AuthenticationEntryPoint

9. FilterSecurityInterceptor
   В FilterSecurityInterceptorцепочке фильтров будет происходить последнее, которое будет последним, которое получает объект проверки подлинности SecurityContextи получает список предоставленных прав доступа (роли предоставлены), и оно примет решение, разрешить ли этот запрос достичь запрошенного ресурса, или нет, решение принимается путем сопоставления с разрешено AntMatchersнастроено в HttpSecurityConfiguration.

Рассмотрим исключения 401-UnAuthorized и 403-Forbidden. Эти решения будут приняты последними в цепочке фильтров

• Не авторизованный пользователь пытается получить доступ к общедоступному ресурсу - разрешено
  
• Не аутентифицированный пользователь пытается получить доступ к защищенному ресурсу - 401-UnAuthorized
  
• Пользователь, прошедший проверку подлинности при попытке доступа к ограниченному ресурсу (ограниченному для его роли) - 403-Запрещено
  

Примечание: Запрос пользователя потоки не только в упомянутых выше фильтров, но есть и другие фильтры тоже не показанные здесь (. ConcurrentSessionFilter, RequestCacheAwareFilter, SessionManagementFilter...)
Это будет отличаться , если вы используете пользовательские аутентификации фильтр вместо UsernamePasswordAuthenticationFilter.
Он будет другим, если вы настроите фильтр аутентификации JWT и опустите .formLogin() i.e, UsernamePasswordAuthenticationFilterего, что станет совершенно другим случаем.

Из документации заказ фильтров дан как

• ChannelProcessingFilter
• ConcurrentSessionFilter
• SecurityContextPersistenceFilter
• LogoutFilter
• X509AuthenticationFilter
• AbstractPreAuthenticatedProcessingFilter
• CasAuthenticationFilter
• UsernamePasswordAuthenticationFilter
• ConcurrentSessionFilter
• OpenIDAuthenticationFilter
• DefaultLoginPageGeneratingFilter
• DefaultLogoutPageGeneratingFilter
• ConcurrentSessionFilter
• DigestAuthenticationFilter
• BearerTokenAuthenticationFilter
• BasicAuthenticationFilter
• RequestCacheAwareFilter
• SecurityContextHolderAwareRequestFilter
• JaasApiIntegrationFilter
• RememberMeAuthenticationFilter
• AnonymousAuthenticationFilter
• SessionManagementFilter
• ExceptionTranslationFilter
• FilterSecurityInterceptor
• SwitchUserFilter

Вы также можете назвать
наиболее распространенный способ аутентификации современного веб-приложения?
разница между аутентификацией и авторизацией в контексте Spring Security?