Conectando RH e TI: Como Usei Java e Spring Security para Melhorar a Comunicação Interna

Recentemente, participei de uma reunião de TI e percebi um problema recorrente entre os setores de RH e TI: a dificuldade na comunicação e no compartilhamento de dados sobre os colaboradores. Informações sobre admissões, desligamentos, promoções e mudanças de setor precisavam ser gerenciadas de forma mais eficiente e segura. A empresa até tinha processos para isso, mas faltava uma solução integrada que realmente facilitasse o fluxo de informação entre os dois setores.

Como não há um setor dedicado ao desenvolvimento de software na empresa e eu gosto muito de criar soluções tecnológicas, comecei a pensar em algo que pudesse ajudar. Quase que instantaneamente, imaginei um aplicativo para facilitar essa gestão. E, claro, escolhi minha linguagem favorita: Java. Afinal, "escreva uma vez, use em qualquer lugar!" 😊

Para apresentar minha ideia, pensei inicialmente em criar um projeto. Eu já sabia um pouco de HTML, CSS e JavaScript, mas queria algo mais estruturado. Foi então que lembrei do React. Eu já havia iniciado um curso sobre essa tecnologia e decidi retomá-lo para aprofundar meu conhecimento e construir uma apresentação visualmente agradável e acessível para todos. Como um professor que admiro costuma dizer: "Um código não precisa apenas rodar, todos têm que entender."

Comecei pelo front-end, para que a ideia ficasse clara para todos, mesmo para quem não trabalha com desenvolvimento. Eu poderia focar diretamente no back-end, seguindo as melhores práticas, mas, para quem não é da área, ver apenas código não teria tanto impacto. Então, priorizei a interface para garantir uma comunicação mais eficiente da proposta.

A Parte Mais Divertida: Desenvolvendo o Back-end

Depois de finalizar o front-end e deixá-lo apresentável, chegou o momento que eu mais esperava: fazer o back-end.

O sistema foi estruturado em quatro microserviços, cada um responsável por uma parte essencial da gestão de colaboradores:

• Serviço de Cadastro: Responsável pelo registro de novos colaboradores.

• Serviço de Desligamento: Gerencia os desligamentos de funcionários.

• Serviço de Promoções: Controla promoções e mudanças de cargo.

• Serviço de Movimentações: Registra transferências de setor dentro da empresa.

Depois de definir os microserviços conforme as necessidades da empresa, surgiu um desafio: fazer com que as APIs se comunicassem corretamente. Duas delas já estavam rodando individualmente, mas não interagiam entre si.

Fui investigar o que estava errado. Revisei minhas dependências, chequei o arquivo application.properties, mas nada parecia fora do lugar. Então, decidi rodar os serviços manualmente pelo CMD, usando um comando do Spring Boot que exibe logs detalhados:

mvn spring-boot:run -Dspring-boot.run.arguments="--debug"

Inicialmente, nada parecia errado. Resolvi seguir em frente e comecei a escrever testes automatizados usando JaCoCo com JUnit 5. Foi então que percebi algo curioso no log: "Uma senha foi gerada automaticamente". Isso me deixou intrigado, já que eu não tinha configurado nenhuma autenticação.

De início, suspeitei do Lombok, mas logo descartei essa hipótese, pois ele apenas gera getters e setters automaticamente. A dúvida surgiu porque eu estava começando a usar o Lombok e ainda não dominava completamente a ferramenta.

Continuei investigando e, ao revisar meu pom.xml, encontrei uma dependência do Spring Security que eu não lembrava de ter adicionado. Como um bom curioso, fui pesquisar sobre isso e finalmente entendi o que estava acontecendo.

Ao estudar mais sobre Spring Security, percebi que ele oferece recursos essenciais para proteger aplicações:

• Autenticação: Podemos utilizar OAuth2 ou JWT (JSON Web Tokens) para autenticar usuários.

• Autorização: Permite definir permissões para diferentes papéis dentro do sistema.

• Boas Práticas: Implementa proteções contra CSRF (Cross-Site Request Forgery) e incentiva o uso de HTTPS para comunicações seguras.

📌 Dica de ouro: Nunca inicie um projeto com sono! Foi assim que acabei adicionando uma dependência extra sem perceber. 😆

Gostei muito de aprender sobre isso! Talvez eu já tivesse visto algo sobre Spring Security no meu curso de Java, mas não lembrava. Quanto mais eu lia, mais queria entender.

Então, criei uma classe de configuração para desativar temporariamente a autenticação, sem remover a dependência. Fiz um teste e, finalmente, minhas APIs começaram a se comunicar corretamente! Aqui está a configuração que utilizei para testar o Spring Security:

j@EnableWebSecurity

public class SecurityConfig extends WebSecurityConfigurerAdapter {

@Override

protected void configure(AuthenticationManagerBuilder auth) throws Exception {

auth.inMemoryAuthentication()

.withUser("user").password("{noop}123").roles("USER")

.and()

.withUser("admin").password("{noop}123").roles("ADMIN");

}

@Override

protected void configure(HttpSecurity http) throws Exception {

http

.authorizeRequests()

.antMatchers("/admin/**").hasRole("ADMIN")

.antMatchers("/user/**").hasRole("USER")

.anyRequest().authenticated()

.and()

.formLogin();

}

Agora, vou explicar de forma simples o que esse código faz:

Ativando a Segurança com @EnableWebSecurity

Essa anotação informa ao Spring Boot que a segurança deve ser ativada na aplicação.

Autenticação em Memória

O método configure(AuthenticationManagerBuilder auth) cria dois usuários de teste:

auth.inMemoryAuthentication()

.withUser("user").password("{noop}123").roles("USER")

.and()

.withUser("admin").password("{noop}123").roles("ADMIN");

• inMemoryAuthentication() → Define autenticação em memória (não persiste os usuários).

• withUser("user") → Cria um usuário chamado "user".

• password("{noop}123") → Define a senha como "123" (sem criptografia, {noop} indica isso).

• roles("USER") → Dá ao usuário a função de "USER".

Autorização das Rotas

O método configure(HttpSecurity http) define quais caminhos cada tipo de usuário pode acessar:

http

.authorizeRequests()

.antMatchers("/admin/**").hasRole("ADMIN")

.antMatchers("/user/**").hasRole("USER")

.anyRequest().authenticated()

.and()

.formLogin();

• antMatchers("/admin/**").hasRole("ADMIN") → Apenas usuários ADMIN podem acessar /admin/**.

• antMatchers("/user/**").hasRole("USER") → Apenas usuários USER podem acessar /user/**.

• anyRequest().authenticated() → Todas as outras rotas exigem login.

• formLogin() → Habilita login via formulário web.

Com atenção à segurança e boas práticas, esta configuração que compartilho é uma solução simples e ideal para testes iniciais. No entanto, quando um sistema está pronto para entrar em produção, é imprescindível aplicar uma abordagem mais robusta. Isso significa utilizar um banco de dados para gerenciar as credenciais dos usuários, implementar criptografia para as senhas e adotar tokens JWT para garantir a segurança das comunicações. No meu projeto, optei pelo MySQL como banco de dados, proporcionando uma base sólida para armazenar os dados dos colaboradores e integrar com a parte de autenticação de forma segura e eficiente.

Desenvolver um sistema de RH utilizando Java, Spring Boot e uma arquitetura de microserviços foi uma jornada incrível e transformadora. Além de resolver um problema real para a empresa, tive a oportunidade de aprender sobre segurança com Spring Security, o que me deu uma compreensão mais profunda de como proteger adequadamente um sistema. O aprendizado sobre APIs intercomunicáveis também foi crucial, pois permitiu que eu entendesse melhor como integrar diferentes serviços em uma arquitetura distribuída de maneira eficiente e segura.

Espero que este artigo seja útil para aqueles que estão iniciando ou explorando o universo do Java, Spring Boot e microserviços. Se o seu objetivo é criar sistemas não apenas funcionais, mas também robustos e seguros, vale muito a pena investir tempo e estudo nessas tecnologias. 🚀