Spring Security 5.0.0 liberado

Como introdução da SpringOne Platform Conference, a Pivotal liberou o Spring Security 5.0.0, a primeira grande versão desde a 4.0.0 (lançada em março de 2015).

O Spring Security foi iniciado em 2004 com o nome de Acegi e atualmente é liderado pelo engenheiro da Pivotal Robert Winch, co-autor do livro Spring Security. A versão 5.0.0 contém mais de 400 melhorias e correções de bugs, incluindo suporte ao OAuth 2.0, suporte reativo ao Spring WebFlux e testes com o projeto Step Verifier.

O InfoQ conversou com Rob Winch, líder do Spring Security sobre a versão atual e o futuro.

InfoQ: O site de atualização é bastante robusto. Você pode resumir o lançamento?

Winch: Os destaques do Spring Security 5.0 requerem no mínimo o JDK 8, Reactive Security, OAuth 2.0 log-in (OIDC), e armazenamento de senhas modernizado.

InfoQ: Como surgiu o tema e a implementação do armazenamento de senhas modernizado?

Winch: É lamentável, mas antes do Spring Security 5.0, o armazenamento de senha era texto simples que não é totalmente seguro. Uma vez que este foi um lançamento importante, esta foi a nossa oportunidade de mudar para um padrão mais seguro.

Felizmente, tivemos a oportunidade de trabalhar com John Steven, que é um especialista em armazenamento de senhas. Na verdade, ele foi um dos principais autores do OWASP Password Storage Cheat Sheet. O Spring Security agora fornece padrões que seguem as recomendações atuais de armazenamento de senhas. Melhor ainda, podemos atualizar passivamente para diferentes mecanismos de atualização.

InfoQ: O que mais impressiona é como o Spring sempre parece entregar exatamente o que estava faltando. Como as funcionalidades são selecionadas e priorizadas?

Winch: Tentamos seguir a comunidade observando os problemas mais votados e em seguida desenvolvemos um tema em todo o portfólio. Este tema foi atualizado para ter no mínimo o JDK 8 e suporte reativo usando o Project Reactor.

InfoQ: O ciclo de lançamento do Spring Security está sendo acelerado, como descrito por Juergen Hoeller, liberando "o que está pronto" em curtos intervalos?

Winch: Sim. O Spring Security tenta seguir o ciclo de lançamento do Spring Framework para assegurar que existe segurança para o que o Spring Framework está fornecendo.

InfoQ: O que está planejado para a próxima versão?

Winch: Para a próxima versão planejamos refinar tanto o suporte ao reativo como o OAuth log-in. Também forneceremos maneiras de migrar as senhas que já estão armazenadas. Esperamos lançar uma versão inicial com suporte ao OAuth Resource Server.

Vamos ver como o Method Security foi melhorado (exemplos do site do Spring Security):

É possível habilitar a anotação baseada em segurança usando a anotação @EnableGlobalMethodSecurity em qualquer instância @Configuration para limitar o acesso ao método. Por exemplo, o código abaixo habilita a anotação @Secured.

@Configuration
@EnableGlobalMethodSecurity(securedEnabled = true)
public class MethodSecurityConfig {
// ...
}

Então é possível aplicar as anotações no nível dos métodos:

public interface BankService {

@Secured("IS_AUTHENTICATED_ANONYMOUSLY")
public Account readAccount(Long id);

@Secured("IS_AUTHENTICATED_ANONYMOUSLY")
public Account[] findAccounts();

@Secured("ROLE_TELLER")
public Account post(Account account, double amount);
}

Entretanto, às vezes queremos mais flexibilidade do que a fornecida pelo GlobalMethodSecurity. Para esses casos, o Spring Security 5.0 introduz a possibilidade do desenvolvedor fornecer uma implementação própria criando uma classe de configuração que estende GlobalMethodSecurityConfiguration e adicionar a anotação @EnableGlobalMethodSecurity na classe de configuração:

@EnableGlobalMethodSecurity(prePostEnabled = true)
public class MethodSecurityConfig extends GlobalMethodSecurityConfiguration {
	@Override
	protected MethodSecurityExpressionHandler createExpressionHandler() {
		// ... create and return custom MethodSecurityExpressionHandler ...
		return expressionHandler;
	}
}

Uma funcionalidade dos streams reativos do Reactor é permitir que uma única thread possa alocar novos jobs, o que introduz novos desafios para implementar mapeamentos ThreadLocal. O Reactor respondeu com a reativa Context API, um tipo de ThreadLocal map reativa.

É possível acessar o contexto reativo através do estático ReactiveSecurityContextHolder.getContext(), que permite que um token de segurança (e outros dados específicos) seja carregado através das chamadas de métodos.