Spring Security - segurança nenhuma, filtros nenhum, permissão de acesso
*1. Visão geral *
O Spring Security fornece vários mecanismos para configurar um padrão de solicitação como não seguro ou permitindo todo o acesso. Dependendo de cada um desses mecanismos - isso pode significar não executar a cadeia de filtros de segurança nesse caminho ou executar a cadeia de filtros e permitir acesso.
Leitura adicional:
https://www..com/role-and-privilege-for-spring-security-registration [Spring Security - Funções e privilégios]
Como mapear funções e privilégios para um aplicativo Spring Security: a instalação, a autenticação e o processo de registro.
https://www..com/securing-a-restful-web-service-with-spring-security [Spring Security para uma API REST]
Como proteger uma API REST com Spring Security - a configuração XML, o web.xml, os códigos de status HTTP para autenticação, etc.
https://www..com/spring-security-expressions-basic [Spring Security Expressions - hasRole Example]
Introdução à hasRole Spring Security Expression: configure a Autorização da Web por URL e na página, bem como a Method Security com @PreAuthorize.
https://www..com/spring-security-expressions-basic [Leia mais] →
===* 2. _access = ”allowAll” _ *
A configuração de um elemento _ <intercept-url> _ com _access = ”allowAll” _ configurará a autorização para que todos os pedidos sejam* permitidos * nesse caminho específico:
<intercept-url pattern="/login*" access="permitAll"/>Ou, via configuração Java:
http.authorizeRequests().antMatchers("/login*").permitAll();Isso é alcançado sem desativar os filtros de segurança - eles ainda são executados, portanto, qualquer funcionalidade relacionada ao Spring Security ainda estará disponível.
*3. _filters = ”none” _ *
Este é um recurso anterior ao Spring 3.1 que foi* reprovado e substituído no Spring 3.1. *
O atributo filters desativa completamente a cadeia de filtros do Spring Security nesse caminho de solicitação específico:
<intercept-url pattern="/login*" filters="none"/>Isso pode causar problemas quando o processamento da solicitação exigir alguma funcionalidade do Spring Security.
Como esse é um recurso descontinuado, versões Spring anteriores a 3.0, usá-lo com o Spring 3.1 resultará em uma exceção de tempo de execução na inicialização:
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 <http> 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” _ *
Como vimos na mensagem de erro acima, o Spring 3.1 substitui _filters = ”none” _ por uma nova expressão - _security = ”none” _.
O escopo também mudou - isso não é mais especificado no nível do elemento _ <intercept-url> _. Em vez disso, o Spring 3.1 permite que vários elementos _ <http> _ sejam definidos - cada um com sua própria configuração de cadeia de filtros de segurança. E assim, o novo atributo de segurança agora pertence ao nível do elemento _ <http> _.
Na prática, será semelhante a:
<http pattern="/resources/**" security="none"/>Ou com a configuração Java:
web.ignoring().antMatchers("/resources/**");Em vez do antigo:
<intercept-url pattern="/resources/**" filters="none"/>Semelhante a _filters = ”none” _, isso também desativará completamente a cadeia de filtros de Segurança para esse caminho de solicitação - portanto, quando a solicitação for tratada no aplicativo, os recursos do Spring Security não estarão disponíveis.
Isso não é um problema para os exemplos acima, que tratam principalmente de servir recursos estáticos - onde nenhum processamento real ocorre. No entanto, se a solicitação for tratada de forma programática de alguma maneira - funcionalidades de segurança como requires-channel, acessar o usuário atual ou chamar métodos seguros não estarão disponíveis.
Pelo mesmo motivo, não faz sentido especificar atributos adicionais em um elemento _ <http> _ que já foi configurado com _security = ”none” _ porque esse caminho de solicitação não é seguro e os atributos serão simplesmente ignorados.
Como alternativa, access = 'IS_AUTHENTICATED_ANONYMOUSLY' pode ser usado para permitir acesso anônimo.
*5. Advertências para _security = ”none” _ *
Ao usar vários elementos _ <http> _, alguns configurados com _security = ”none” _, lembre-se de que a ordem na qual esses elementos são definidos é importante. Queremos que os caminhos específicos _ <http> _ primeiro sigam o padrão universal no final.
Observe também que, se um elemento _ <http> _* não especificar um padrão , por padrão, será mapeado para o padrão de correspondência universal - "/*" - então, novamente, esse elemento precisará ser o último. Se a ordem dos elementos não estiver correta, a criação da cadeia de filtros de segurança falhará:
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 <security:http> 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. Conclusão *
Este artigo discute as opções de permitir acesso a um caminho com o Spring Security - focando nas diferenças entre* filtros = "nenhum", segurança = "nenhum" e acesso = "permitirTodos" *.
Como de costume, os exemplos estão disponíveis over no GitHub.