No tienes acceso a esta clase

¡Continúa aprendiendo! Únete y comienza a potenciar tu carrera

Aplicar requestMatchers

9/23
Recursos

¿Cómo se configuran las reglas de seguridad en Spring Security?

Spring Security nos permite definir reglas de seguridad para denegar o permitir el acceso a diferentes endpoints o métodos HTTP. Al configurar estas reglas, podemos proteger rutas específicas en nuestra aplicación según las necesidades del proyecto. Utilizaremos request matchers para establecer estas reglas, una manera flexible de aplicar criterios de seguridad personalizados.

¿Qué son los request matchers?

Los request matchers son criterios que utilizamos para definir las reglas de acceso a nuestros endpoints. Esto se puede hacer especificando:

  • El path o patrón: Una ruta específica o patrón sobre el cual aplicar la regla.
  • El método HTTP: Combinado con un path, permite definir reglas para métodos específicos como GET, POST, etc.

Por ejemplo, podemos crear una regla que permita todos los métodos GET en rutas que sigan el patrón /api/*.

¿Cómo configurar y lanzar una aplicación con reglas de acceso específicas?

Al establecer reglas, es importante definir claramente las acciones sobre ellas. Podemos permitir, denegar o requerir roles específicos. Por simplicidad, mencionaremos cómo permitir acceso a ciertos métodos.

Ejemplo básico

A continuación, presentamos un ejemplo de configuración básica permitiendo todos los métodos GET en cualquier ruta que comience con /api/ seguido de cualquier subruta:

http.authorizeHttpRequests()
    .requestMatchers(HttpMethod.GET, "/api/*")
    .permitAll();

Este fragmento de código indica que todas las peticiones GET a rutas bajo /api/ están permitidas. Si lanzamos la aplicación y probamos estas rutas usando herramientas como Postman, podemos ver una diferencia clara en el acceso permitido.

¿Qué diferencia existe entre un asterisco y dos en los patrones?

El uso de un solo asterisco (*) en las rutas permite el acceso solo al siguiente nivel del path. Por ejemplo, /api/* permite acceso al primer nivel después de /api/. Así, una ruta /api/pizzas funcionará, pero /api/pizzas/available requerirá una configuración adicional.

Por otro lado, utilizar dos asteriscos ()** expande la autorización a cualquier subruta en todo el árbol después del sufijo indicado. Modifiquemos nuestro ejemplo previo:

http.authorizeHttpRequests()
    .requestMatchers(HttpMethod.GET, "/api/**")
    .permitAll();

Esto permite acceder a cualquier ruta bajo /api/ sin restricciones adicionales.

¿Cómo aplicamos reglas más específicas?

Podemos designar reglas para rutas específicas restringiendo el acceso a otras. Por ejemplo, si queremos que solo esté permitido el acceso a /api/pizzas:

http.authorizeHttpRequests()
    .requestMatchers(HttpMethod.GET, "/api/pizzas")
    .permitAll()
    .anyRequest()
    .authenticated();

Con esto, cualquier otra petición, por ejemplo, /api/orders, requerirá autenticación.

¿Cómo podemos denegar acceso a ciertos métodos?

Es posible bloquear completamente un método HTTP en toda la aplicación. Supongamos que las reglas de negocio prohíben el uso del método PUT en todo el proyecto:

http.authorizeHttpRequests()
    .requestMatchers(HttpMethod.PUT)
    .denyAll();

Esto denegará cualquier intento de uso del método PUT, sin importar la autenticación del usuario.

Consejos prácticos para implementar reglas en Spring Security

  • Planifica tus reglas: Asegúrate de que las rutas críticas y sensibles estén protegidas antes de lanzar tu aplicación.
  • Prueba exhaustivamente: Usa herramientas como Postman para verificar que la configuración de seguridad funcione como esperabas.
  • Considera roles de usuario: Aunque este ejemplo no cubre roles, piénsalo para una mayor granularidad en accesos.

Seguir estos consejos te ayudará a mantener una aplicación segura, y te animamos a seguir profundizando en la seguridad de Spring Security. ¡No te detengas aquí! El futuro del desarrollo seguro depende de seguir aprendiendo y aplicando estas prácticas.

Aportes 7

Preguntas 2

Ordenar por:

¿Quieres ver más aportes, preguntas y respuestas de la comunidad?

Al momento de pasar el pattern al request matcher solo podemos agregar los valores de nuestro @RequestMapping definidos en los controladores. Spring Security no tomara en cuenta el server.servlet.context-path que definamos. Si agregamos el nombre de nuestro context-path en el pattern no funcionara

Buenas noches, estoy teniendo un problema y es que a pesar de tener esta configuración: ```java package com.example.ferreadminbackend.auth.infraestructure.config; import org.springframework.context.annotation.Bean; import org.springframework.context.annotation.Configuration; import org.springframework.http.HttpMethod; import org.springframework.security.config.Customizer; import org.springframework.security.config.annotation.web.builders.HttpSecurity; import org.springframework.security.config.annotation.web.configurers.AbstractHttpConfigurer; import org.springframework.security.web.SecurityFilterChain; @Configuration public class SecurityConfig { @Bean public SecurityFilterChain filterChain(HttpSecurity http) throws Exception { http .authorizeHttpRequests((authorizeRequests) -> authorizeRequests .requestMatchers(HttpMethod.GET, "/api/**").permitAll() .requestMatchers(HttpMethod.PUT).denyAll() .anyRequest() .authenticated() ) .httpBasic(Customizer.withDefaults()) .csrf(AbstractHttpConfigurer::disable) .cors(Customizer.withDefaults()); return http.build(); } } ```En el postman me sigue mostrando "401Unauthorized" cuando hago la petición al GET, la ruta esta bien, y cuando hago la petición con el password que me genera Spring si me consulta la información normal, creo que algo me falta, entonces quisiera saber si alguien me podría ayudar con este problema, muchas gracias.
No se si se puede hacer con Spring en una web que tiene sus usuarios, usuarios externos necesitan entrar con sus propios usuarios de Active Directory. un SSO SAML con Java Spring Multicliente. entonces, desde nuestra web se entra en: * <https://app.web.com/sso/servidor_1/login> * en este caso ingresan las personas que estén registradas en el servidor 1 * <https://app.web.com/sso/servidor_2/login> * en este caso ingresan las personas que estén registradas en el servidor 2 * <https://app.web.com/sso/servidor_3/login> * en este caso ingresan las personas que estén registradas en el servidor 3 * luego de ingresar van a una sección donde se le asigna un token para que ingrese a la web principal * y así sucesivamente contra n servidores lo que hemos conseguido es hacer un SSO con un solo servidor, pero no con varios servidores, y que cambien dependiendo de la URL Esto es posible con Spring SAML. Ejemplo practico, > Hay una web de música, y los trabajadores de CocaCola quieren entrar y los de pepsi también entonces tanto CocaCola como Pepsi tiene sus propios AD (Active directory) con los usuariosentonces la web de música tiene esta URL: <https://webmusic.com/sso/cocacola/login> o <https://webmusic.com/sso/pepsi/login> (u o más urls, fanta, redbull)y estas rutas redirigen al AD pertinente, luego cuando el AD da el OK, se crea y redirige a la web de Musica con el nuevo token creado a partir de los datos que entrego el AD.

Mi aporte para JDK 19

@Bean
    public SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
        http
                .csrf().disable()
                .cors().and()
                .authorizeRequests()
                .antMatchers("/producto/**").permitAll() // Acceso con Java SDK 19 
                .anyRequest()
                .authenticated()
                .and()
                .httpBasic();

        return http.build();
    }
El uso de `requestMatchers` en Spring Security permite definir reglas para controlar el acceso a diferentes endpoints de tu aplicación. Puedes especificar rutas y métodos HTTP, permitiendo o denegando el acceso según lo necesites. Por ejemplo, puedes permitir todas las solicitudes `GET` a `/api/*` usando: ```java http.authorizeRequests() .requestMatchers(HttpMethod.GET, "/api/**").permitAll(); ``` Esto permite el acceso sin autenticación a cualquier endpoint que comience con `/api/`. Es crucial entender cómo el orden de estas reglas afecta la seguridad de tu aplicación, ya que las solicitudes que no coincidan se evaluarán según las reglas siguientes.
```java package com.platzi.pizzeria.web.config; import org.springframework.context.annotation.Bean; import org.springframework.context.annotation.Configuration; import org.springframework.http.HttpMethod; import org.springframework.security.config.Customizer; import org.springframework.security.config.annotation.web.builders.HttpSecurity; import org.springframework.security.config.annotation.web.configuration.EnableWebSecurity; import org.springframework.security.config.annotation.web.configurers.AbstractHttpConfigurer; import org.springframework.security.web.SecurityFilterChain; @Configuration @EnableWebSecurity public class SecurityConfig { @Bean public SecurityFilterChain filterChain(HttpSecurity http) throws Exception { http .csrf(AbstractHttpConfigurer::disable) .cors(Customizer.withDefaults()) .authorizeHttpRequests((authorize) -> authorize.requestMatchers(HttpMethod.GET, "/api/pizzas/**").permitAll() .requestMatchers(HttpMethod.PUT).denyAll() .anyRequest() .authenticated() ) .httpBasic(Customizer.withDefaults()) ; return http.build(); } } ```
```java @Configuration public class SecurityConfig { @Bean public SecurityFilterChain filterChain(HttpSecurity http) throws Exception { http .csrf(csrf -> csrf.disable()) .authorizeRequests() .requestMatchers("/swagger-ui/**", "/v3/api-docs/**").permitAll() .requestMatchers(HttpMethod.GET, "/api/candidate/**").permitAll() .anyRequest() .authenticated() .and() .httpBasic(Customizer.withDefaults()); return http.build(); } } ```para Swagger