Como a cadeia de filtros de segurança da Spring funciona

Percebo que a segurança do Spring se baseia na cadeia de filtros, que interceptará a solicitação, detectará (ausência de) autenticação, redirecionará para o ponto de entrada da autenticação ou passará a solicitação para o serviço de autorização e, eventualmente, permitirá que a solicitação atinja o servlet ou gere uma exceção de segurança (não autenticado ou não autorizado). DelegatingFitlerProxy cola esses filtros juntos. Para executar suas tarefas, esses serviços de acesso ao filtro, como UserDetailsService e AuthenticationManager .

Os principais filtros da cadeia são (na ordem)

• SecurityContextPersistenceFilter (restaura a autenticação de JSESSIONID)
• UsernamePasswordAuthenticationFilter (executa autenticação)
• ExceptionTranslationFilter (capturar exceções de segurança de FilterSecurityInterceptor)
• FilterSecurityInterceptor (pode gerar exceções de autenticação e autorização)

Estou confuso como esses filtros são usados. Será que para o formulário fornecido na primavera, o UsernamePasswordAuthenticationFilter é usado apenas para / login e os filtros posteriores não? O elemento do espaço para nome do formulário-login configura automaticamente esses filtros? Todas as solicitações (autenticadas ou não) chegam ao FilterSecurityInterceptor para obter um URL sem logon?

E se eu quiser proteger minha API REST com o token JWT , que é recuperado do login? Preciso configurar duas httptags de configuração de namespace , direitos? Um para / login com UsernamePasswordAuthenticationFiltere outro para URLs REST, com customização JwtAuthenticationFilter.

A configuração de dois httpelementos cria dois springSecurityFitlerChains? Está UsernamePasswordAuthenticationFilterdesativado por padrão, até que eu declare form-login? Como faço para substituir SecurityContextPersistenceFiltercom um filtro que irá obter Authenticationa partir existente JWT-tokenem vez de JSESSIONID?

A cadeia de filtros de segurança Spring é um mecanismo muito complexo e flexível.

Os principais filtros da cadeia são (na ordem)

• SecurityContextPersistenceFilter (restaura a autenticação de JSESSIONID)
• UsernamePasswordAuthenticationFilter (executa autenticação)
• ExceptionTranslationFilter (capturar exceções de segurança de FilterSecurityInterceptor)
• FilterSecurityInterceptor (pode gerar exceções de autenticação e autorização)

Examinando a documentação atual do release estável 4.2.1 , seção 13.3 Ordenação de filtros, você pode ver toda a organização de filtros da cadeia de filtros:

13.3 Solicitação de filtro

A ordem em que os filtros são definidos na cadeia é muito importante. Independentemente de quais filtros você está realmente usando, o pedido deve ser o seguinte:

1. ChannelProcessingFilter , porque pode ser necessário redirecionar para um protocolo diferente

2. SecurityContextPersistenceFilter , para que um SecurityContext possa ser configurado no SecurityContextHolder no início de uma solicitação da Web, e quaisquer alterações no SecurityContext podem ser copiadas no HttpSession quando a solicitação da Web terminar (pronta para uso com a próxima solicitação da Web)

3. ConcurrentSessionFilter , porque usa a funcionalidade SecurityContextHolder e precisa atualizar o SessionRegistry para refletir solicitações em andamento do principal

4. Mecanismos de processamento de autenticação - UsernamePasswordAuthenticationFilter , CasAuthenticationFilter , BasicAuthenticationFilter etc - para que o SecurityContextHolder possa ser modificado para conter um token de solicitação de autenticação válido

5. O SecurityContextHolderAwareRequestFilter , se você estiver usando-o para instalar um HttpServletRequestWrapper compatível com o Spring Security no contêiner do servlet

6. O JaasApiIntegrationFilter , se um JaasAuthenticationToken estiver no SecurityContextHolder, isso processará o FilterChain como o Assunto no JaasAuthenticationToken

7. RememberMeAuthenticationFilter , para que, se nenhum mecanismo de processamento de autenticação anterior atualize o SecurityContextHolder, e a solicitação apresente um cookie que permita a realização de serviços de lembrança de mim, um objeto de autenticação lembrado adequado será colocado lá

8. AnonymousAuthenticationFilter , para que, se nenhum mecanismo de processamento de autenticação anterior atualizasse o SecurityContextHolder, um objeto de autenticação anônimo será colocado lá

9. ExceptionTranslationFilter , para capturar qualquer exceção do Spring Security, para que uma resposta de erro HTTP possa ser retornada ou um AuthenticationEntryPoint apropriado possa ser iniciado

10. FilterSecurityInterceptor , para proteger URIs da web e gerar exceções quando o acesso é negado

Agora, tentarei continuar suas perguntas uma a uma:

Estou confuso como esses filtros são usados. Será que para o formulário fornecido na primavera, o UsernamePasswordAuthenticationFilter é usado apenas para / login e os filtros posteriores não? O elemento do espaço para nome do formulário-login configura automaticamente esses filtros? Todas as solicitações (autenticadas ou não) chegam ao FilterSecurityInterceptor para obter um URL sem logon?

Depois de configurar um <security-http> seção, para cada uma você deve fornecer pelo menos um mecanismo de autenticação. Esse deve ser um dos filtros que correspondem ao grupo 4 na seção 13.3 Ordenação de filtros da documentação do Spring Security que acabei de referenciar.

Este é o elemento http mínimo de segurança válido: que pode ser configurado:

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

Ao fazer isso, esses filtros são configurados no proxy da cadeia de filtros:

{
        "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"
    }

Nota: Eu os obtenho criando um RestController simples que @Autowires the FilterChainProxy e retorna seu conteúdo:

    @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;
    }

Aqui pudemos ver que apenas declarando o <security:http>elemento com uma configuração mínima, todos os filtros padrão estão incluídos, mas nenhum deles é do tipo Autenticação (quarto grupo na seção 13.3 Ordenação de filtros). Portanto, na verdade, significa que apenas declarando o security:httpelemento, o SecurityContextPersistenceFilter, o ExceptionTranslationFilter e o FilterSecurityInterceptor são configurados automaticamente.

De fato, um mecanismo de processamento de autenticação deve ser configurado e até os beans de namespace de segurança processam reivindicações para isso, gerando um erro durante a inicialização, mas isso pode ser ignorado pela adição de um atributo de ponto de entrada-ref em <http:security>

Se eu adicionar um básico <form-login>à configuração, desta maneira:

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

Agora, o filterChain ficará assim:

{
        "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"
    }

Agora, esses dois filtros org.springframework.security.web.authentication.UsernamePasswordAuthenticationFilter e org.springframework.security.web.authentication.ui.DefaultLoginPageGeneratingFilter são criados e configurados no FilterChainProxy.

Então, agora, as perguntas:

Será que para o formulário fornecido na primavera, o UsernamePasswordAuthenticationFilter é usado apenas para / login e os filtros posteriores não?

Sim, é usado para tentar concluir um mecanismo de processamento de login, caso a solicitação corresponda ao URL UsernamePasswordAuthenticationFilter. Esse URL pode ser configurado ou até alterado seu comportamento para corresponder a todas as solicitações.

Você também pode ter mais de um mecanismo de processamento de autenticação configurado no mesmo FilterchainProxy (como HttpBasic, CAS, etc.).

O elemento do espaço para nome do formulário-login configura automaticamente esses filtros?

Não, o elemento form-login configura o UsernamePasswordAUthenticationFilter e, caso você não forneça um URL da página de login, ele também configura o org.springframework.security.web.authentication.ui.DefaultLoginPageGeneratingFilter, que termina em um login simples gerado automaticamente página.

Os outros filtros são configurados automaticamente por padrão apenas criando um <security:http>elemento sem security:"none"atributo.

Todas as solicitações (autenticadas ou não) chegam ao FilterSecurityInterceptor para obter um URL sem logon?

Cada solicitação deve alcançá-lo, pois é o elemento que cuida se a solicitação tem os direitos de atingir o URL solicitado. Mas alguns dos filtros processados ​​anteriormente podem parar o processamento da cadeia de filtros, simplesmente não sendo chamados FilterChain.doFilter(request, response);. Por exemplo, um filtro CSRF pode parar o processamento da cadeia de filtros se a solicitação não tiver o parâmetro csrf.

E se eu quiser proteger minha API REST com o token JWT, que é recuperado do login? Preciso configurar duas tags http de configuração de namespace, direitos? Outro para / login com UsernamePasswordAuthenticationFiltere outro para URLs REST, com customização JwtAuthenticationFilter.

Não, você não é forçado a fazer isso. Você pode declarar ambos UsernamePasswordAuthenticationFiltere o JwtAuthenticationFiltermesmo elemento http, mas isso depende do comportamento concreto de cada um desses filtros. Ambas as abordagens são possíveis e a escolha final depende das próprias preferências.

A configuração de dois elementos http cria dois springSecurityFitlerChains?

Sim, é verdade

O UsernamePasswordAuthenticationFilter está desativado por padrão, até que eu declare o login do formulário?

Sim, você pode vê-lo nos filtros criados em cada uma das configurações que publiquei

Como substituo o SecurityContextPersistenceFilter por um que obtém a autenticação do token JWT existente em vez do JSESSIONID?

Você pode evitar o SecurityContextPersistenceFilter, apenas configurando a estratégia de sessão no <http:element>. Basta configurar assim:

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

Ou, nesse caso, você pode substituí-lo por outro filtro, desta forma dentro do <security:http>elemento:

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

EDITAR:

Uma pergunta sobre "Você também pode ter mais de um mecanismo de processamento de autenticação configurado no mesmo FilterchainProxy". O último substituirá a autenticação executada pelo primeiro, se declarar vários filtros de autenticação (implementação Spring)? Como isso está relacionado a ter vários provedores de autenticação?

Finalmente, isso depende da implementação de cada filtro em si, mas é verdade que os últimos filtros de autenticação são capazes de sobrescrever qualquer autenticação anterior eventualmente feita pelos filtros anteriores.

Mas isso não acontece necessariamente. Eu tenho alguns casos de produção em serviços REST protegidos, onde eu uso um tipo de token de autorização que pode ser fornecido como um cabeçalho Http ou dentro do corpo da solicitação. Portanto, configurei dois filtros que recuperam esse token, em um caso do cabeçalho Http e o outro no corpo da solicitação da própria solicitação de descanso. É verdade que, se uma solicitação http fornecer esse token de autenticação como cabeçalho Http e dentro do corpo da solicitação, ambos os filtros tentarão executar o mecanismo de autenticação que o delegará ao gerente, mas isso poderá ser facilmente evitado simplesmente verificando se a solicitação está correta. já autenticado apenas no início do doFilter()método de cada filtro.

Ter mais de um filtro de autenticação está relacionado a ter mais de um provedor de autenticação, mas não o force. No caso exposto anteriormente, tenho dois filtros de autenticação, mas apenas um provedor de autenticação, pois os dois filtros criam o mesmo tipo de objeto de autenticação. Nos dois casos, o gerenciador de autenticação o delega ao mesmo provedor.

E, ao contrário disso, também tenho um cenário em que publico apenas um UsernamePasswordAuthenticationFilter, mas as credenciais do usuário podem estar contidas no DB ou LDAP, por isso tenho dois provedores de suporte de UsernamePasswordAuthenticationToken e o AuthenticationManager delega qualquer tentativa de autenticação do filtro nos provedores para validar as credenciais.

Portanto, acho claro que nem a quantidade de filtros de autenticação determina a quantidade de provedores de autenticação nem a quantidade de provedor determina a quantidade de filtros.

Além disso, a documentação afirma que SecurityContextPersistenceFilter é responsável por limpar o SecurityContext, que é importante devido ao pool de encadeamentos. Se eu omitir ou fornecer implementação personalizada, tenho que implementar a limpeza manualmente, certo? Existem truques mais semelhantes ao personalizar a cadeia?

Eu não examinei cuidadosamente esse filtro antes, mas após sua última pergunta, estive verificando sua implementação e, como normalmente no Spring, quase tudo poderia ser configurado, estendido ou substituído.

O SecurityContextPersistenceFilter delega em uma implementação SecurityContextRepository a procura pelo SecurityContext. Por padrão, um HttpSessionSecurityContextRepository é usado, mas isso pode ser alterado usando um dos construtores do filtro. Portanto, pode ser melhor escrever um SecurityContextRepository que atenda às suas necessidades e apenas configurá-lo no SecurityContextPersistenceFilter, confiando no seu comportamento comprovado, em vez de começar a fazer tudo do zero.

UsernamePasswordAuthenticationFilteré usado apenas para /login, e filtros posteriores não são?

Não, UsernamePasswordAuthenticationFilterestende AbstractAuthenticationProcessingFilter, e isso contém a RequestMatcher, o que significa que você pode definir seu próprio URL de processamento, esse filtro manipula apenas as RequestMatchercorrespondências com o URL de solicitação, o URL de processamento padrão é /login.

Os filtros posteriores ainda podem manipular a solicitação, se a UsernamePasswordAuthenticationFilterexecução for executada chain.doFilter(request, response);.

Mais detalhes sobre instaladores principais

O elemento do espaço para nome do formulário-login configura automaticamente esses filtros?

UsernamePasswordAuthenticationFilteré criado por <form-login>, são Aliases de filtro padrão e Pedidos

Todas as solicitações (autenticadas ou não) chegam ao FilterSecurityInterceptor para obter um URL sem logon?

Depende se os adaptadores anteriores são bem-sucedidos, mas FilterSecurityInterceptoré o último ajustador normalmente.

A configuração de dois elementos http cria dois springSecurityFitlerChains?

Sim, todo fitlerChain tem um RequestMatcher, se oRequestMatcher corresponder à solicitação, a solicitação será tratada pelos instaladores na cadeia de montagem.

O padrão RequestMatchercorresponde a todas as solicitações se você não configurar o padrão ou pode configurar o URL específico (<http pattern="/rest/**" ).

Se você quiser saber mais sobre os instaladores, acho que você pode verificar o código-fonte na segurança da primavera. doFilter(ServletRequest request, ServletResponse response, FilterChain filterChain)

Spring security é uma estrutura baseada em filtro, ele planta um WALL (HttpFireWall) antes da sua aplicação em termos de filtros proxy ou beans gerenciados por primavera. Sua solicitação precisa passar por vários filtros para acessar sua API.

Sequência de execução no Spring Security

1. WebAsyncManagerIntegrationFilter Fornece integração entre o SecurityContext e o WebAsyncManager do Spring Web.
   

2. SecurityContextPersistenceFilterEsse filtro será executado apenas uma vez por solicitação, preenche o SecurityContextHolder com informações obtidas do SecurityContextRepository configurado antes da solicitação e as armazena de volta no repositório assim que a solicitação for concluída e limpar o detentor do contexto.
   A solicitação é verificada para a sessão existente. Se uma nova solicitação, SecurityContext será criada, caso contrário, se a solicitação tiver sessão, o contexto de segurança existente será obtido no repositório .

3. HeaderWriterFilter Filtre a implementação para adicionar cabeçalhos à resposta atual.

4. LogoutFilterSe o pedido url é /logout(para a configuração padrão) ou se mathces pedido de URL RequestMatcherconfigurado em LogoutConfigurerseguida,

   • limpa o contexto de segurança.
   • invalida a sessão
   • exclui todos os cookies com nomes de cookies configurados em LogoutConfigurer
   • Redireciona para o URL de sucesso de logoff padrão /ou URL de sucesso de logout configurado ou chama logoutSuccessHandler configurado.

5. UsernamePasswordAuthenticationFilter

   • Para qualquer URL de solicitação que não seja loginProcessingUrl, esse filtro não será processado mais, mas a cadeia de filtros continuará.
   • Se o URL solicitado for correspondências (devem ser HTTP POST) padrão /loginou correspondências .loginProcessingUrl()configuradas em FormLoginConfigurerseguida,UsernamePasswordAuthenticationFilter tentará a autenticação.
   • os parâmetros padrão do formulário de login são nome de usuário e senha, podem ser substituídos por usernameParameter(String),passwordParameter(String) .
   • a configuração .loginPage() substitui os padrões
   • Ao tentar autenticação
     • um Authenticationobjeto ( UsernamePasswordAuthenticationTokenou qualquer implementação deAuthentication no caso do seu filtro de autenticação personalizado) é criado.
     • e authenticationManager.authenticate(authToken) será invocado
       
     • Observe que podemos configurar qualquer número de AuthenticationProvidermétodos de autenticação, tente todos os provedores de autenticação e verifique qualquer supportsobjeto de provedor de autenticação authToken / authentication, o provedor de autenticação de suporte será usado para autenticação. e retorna o objeto de autenticação em caso de autenticação bem-sucedida lançada AuthenticationException.
   • Se a sessão de êxito da autenticação for criada e authenticationSuccessHandlerinvocada, o redirecionamento para o URL de destino configurado (o padrão é /)
   • Se a autenticação falhar, o usuário se tornará um usuário não autenticado e a cadeia continuará.

6. SecurityContextHolderAwareRequestFilter, se você estiver usando-o para instalar um HttpServletRequestWrapper compatível com o Spring Security no contêiner do servlet

7. AnonymousAuthenticationFilterDetecta se não há nenhum objeto de autenticação no SecurityContextHolder, se nenhum objeto de autenticação encontrado, cria Authenticationobject ( AnonymousAuthenticationToken) com autoridade concedida ROLE_ANONYMOUS. Aqui AnonymousAuthenticationTokenfacilita a identificação de solicitações subseqüentes de usuários não autenticados.
   

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, para capturar quaisquer exceções do Spring Security para que uma resposta de erro HTTP possa ser retornada ou um AuthenticationEntryPoint apropriado possa ser iniciado

9. FilterSecurityInterceptor
   Haverá o FilterSecurityInterceptorque vem quase por último na cadeia de filtros que obtém o objeto Autenticação SecurityContexte recebe a lista de autoridades concedidas (funções concedidas) e tomará uma decisão para permitir que essa solicitação atinja o recurso solicitado ou não, a decisão é tomada por correspondência com o permitido AntMatchersconfigurado em HttpSecurityConfiguration.

Considere as exceções 401-Não autorizado e 403-Proibido. Essas decisões serão tomadas no final da cadeia de filtros

• Usuário não autenticado tentando acessar o recurso público - permitido
  
• Usuário não autenticado tentando acessar recursos protegidos - 401-UnAuthorized
  
• Usuário autenticado tentando acessar o recurso restrito (restrito à sua função) - 403-Proibido
  

Nota: Request usuário flui não só na acima filtros mencionado, mas há outros filtros também não mostrados aqui (. ConcurrentSessionFilter, RequestCacheAwareFilter, SessionManagementFilter...)
Será diferente quando você usa o filtro de autenticação personalizada em vez de UsernamePasswordAuthenticationFilter.
Será diferente se você configurar o filtro de autenticação JWT e omitir que .formLogin() i.e, UsernamePasswordAuthenticationFilterele se tornará um caso totalmente diferente.

Na documentação, a ordenação de filtros é fornecida como

• 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

Você também pode consultar a
maneira mais comum de autenticar um aplicativo Web moderno?
diferença entre autenticação e autorização no contexto do Spring Security?