Códice | Entradas sobre «spring security»

Logout personalizado con Spring Security

JavGuerra — Sat, 13 Jul 2024 00:00:00 GMT

Etiquetas: #código, #java, #spring boot, #spring security, #ciberseguridad

En un artículo anterior he usado variables de sesión para guardar información de la aplicación: mensajes para el usuario, aviso de cookies… Puede que, cuando el usuario salga de su sesión, queramos conservar estos datos que seguirán siendo útiles aunque no esté autenticado. En esta entrada muestro mi solución usando Spring Security.

Se asume que el lector tiene conocimientos generales de Spring Boot y Spring Security para aplicar el contenido.

El contexto de seguridad

El primer paso en el proceso de logout que lleva a cabo Spring Security es invalidar la sesión del usuario. Esto significa que Spring Security elimina cualquier información asociada con la sesión del usuario, como datos de estado de sesión almacenados en el servidor o en cookies (borra la información, pero no la cookie). Al invalidar la sesión, se asegura de que el usuario ya no pueda acceder a la aplicación como si estuviera autenticado.

Después de invalidar la sesión, Spring Security también limpia el contexto de seguridad actual. Esto incluye eliminar cualquier token de Authentication que represente al usuario autenticado, asegurando que el usuario ya no sea reconocido como autenticado en la aplicación.

Pero en este caso no interesa ese borrado completo, sino sólo la información de autenticación. Para ello debo codificar mi propio logout limpiando el contexto de seguridad pero sin invalidar la sesión.

Tomando el control de Logout

Como sabemos, para configurar Spring Security se usa la clase SecurityConfig.class, que generalmente incluye el componente SecurityFilterChain, fundamental para establecer filtros a las peticiones HTTP que se reciben en la aplicación. En este ejemplo me centraré en la parte de su configuración relativa al logout.

@Configuration
@EnableWebSecurity
public class  SecurityConfig {

    ...

    @Bean
    public SecurityFilterChain securityFilterChain(HttpSecurity http)  throws Exception {
        http.authorizeHttpRequests(authRequest -> authRequest

                ...

                .requestMatchers(HttpMethod.POST, "/logout").permitAll()

                .anyRequest().authenticated()
            )

            ...

            .logout(logout -> logout
                .logoutUrl("/logout")
                .permitAll()
            )

        return http.build();
    }
}

Con ... indico que el código puede ser más amplio y contener otras configuraciones.

En la línea .requestMatchers(HttpMethod.POST, "/logout").permitAll() estoy permitiendo el acceso a la ruta personalizada para llevar a cabo el logout. Realmente, esto no sería necesario al incluir .permitAll() después de logoutUrl("/logout"). Tampoco sería necesario porque la ruta /logout está disponible por defecto. No obstante, esto puede ser útil si decidimos usar otra ruta distinta a /logout en la aplicación.

Para la gestión del token del usuario, será necesario definir un controlador propio para la ruta logout. Algo similar a esto:

@Slf4j
@Controller
public class LogoutController {

    @RequestMapping("/logout")
    public String logout() {

        log.info("logout");

        SecurityContextHolder.getContext().setAuthentication(null);

        // cosas que hacer tras el cierre de sesión aquí

        return "logout";
    }
}

La información de sesión se guarda en una cookie llamada JSESSIONID, que contendrá las variables de sesión, incluido el token de autenticación.

Con SecurityContextHolder.getContext().setAuthentication(null); elimino el token de autenticación, pero sin borrar toda la información de la cookie, como las variables de sesión.

Después de esto, puedo realizar algunas acciones asociadas al cierre y redirigir al login, o como en este caso, mostrar la vista logout para mostrar un mensaje de despedida.

Refinando el logout

Al usar null elimino el token de autenticación del usuario, pero puede que, en la plantilla que devuelvo con return (logout en el caso anterior), sea necesario usar el contexto de seguridad, por ejemplo mostrando una información u otra en un fragmento de la plantilla si estamos autenticados o no. Con este método, ni sec:authorize="isAnonymous()" ni sec:authorize="isAuthenticated()" funcionarán en Thymeleaft, ya que ahora no existe el token que indique si el usuario es anónimo o está autenticado.

Esto ocurre sólo para la vista asociada al controlador que es llamada tras borrar el token, pero no ocurre así para las siguientes vistas, en las que parece que el token es regenerado como anónimo.

Entonces, si en la siguiente vista no vamos a usar la autenticación, será suficiente con usar null, pero si no es así, entonces hay que cambiar el token en vez de eliminarlo, pero Spring Boot no tiene un token por defecto que pueda usar, así que debo construir uno.

Primeramente añado el siguiente código en

@Bean
public AnonymousAuthenticationToken anonymousAuthenticationToken() {
    List<GrantedAuthority> authorities = Collections.singletonList(new SimpleGrantedAuthority("ROLE_ANONYMOUS"));
    return new AnonymousAuthenticationToken("ANONYMOUS_USER", "ANONYMOUS_USER", authorities);
}

Que me permitirá crear anonymousAuthenticationToken como un Bean. Este método es responsable de crear e inicializar el objeto AnonymousAuthenticationToken. Este token es utilizado por Spring Security para representar la autenticación de usuarios anónimos dentro de una aplicación.

El método realiza las siguientes acciones:

Inicialización de Autoridades: Primero, creo una lista (List<GrantedAuthority>) con un solo elemento, que es una instancia de SimpleGrantedAuthority con el rol "ROLE_ANONYMOUS". Las autoridades (o roles) determinan los privilegios que tiene un usuario dentro de la aplicación. En este caso, asigno al usuario anónimo el rol de ROLE_ANONYMOUS.
Creación del Token: Luego, utilizo esta lista de autoridades para construir un nuevo AnonymousAuthenticationToken, pasando también dos cadenas de texto ("ANONYMOUS_USER") como nombre y detalles del usuario. Estos valores pueden ser personalizados según sea necesario.

Ya puedo usar el token en el controlador, como se muestra:

@Slf4j
@RequiredArgsConstructor
@Controller
public class LogoutController {

    private final AnonymousAuthenticationToken anonymousAuthenticationToken;

    @RequestMapping("/logout")
    public String logout() {

        log.info("logout");

        SecurityContextHolder.getContext().setAuthentication(anonymousAuthenticationToken);

        // cosas que hacer tras el cierre de sesión aquí

        return "logout";
    }
}

Ahora sí, el usuario será anónimo, y cualquier comprobación en la plantilla Thymeleaft que incluya sec:authorize="isAnonymous()" permitirá que la etiqueta HTML que lo use sea mostrada.

Consideraciones

Tal vez podría crearse un servicio al que llamar desde el controlador para gestionar el logout, o un manejador propio CustomLogoutHandler que realice esta función de cierre de sesión sin la necesidad de crear un controlador, y que se use directamente desde SecurityConfig.class.

Se han de tener en cuenta las consideraciones de seguridad relacionadas con este método. Mantener información de la sesión de usuario una vez se lleva a cabo el logout no siempre es seguro, y se deben controlar las posibles fugas de información para evitar problemas.

Un ejemplo

Puedes ver el código que implementan esta funcionalidad en el repositorio de la aplicación Cartelera DAW.

Repositorio de Cartelera DAW

Mira también el artículo donde se usan las variables de sesión que quiero preservar:

Notificaciones con Thymeleaft

Cartelera DAW

JavGuerra — Thu, 20 Jun 2024 00:00:00 GMT

Etiquetas: #portfolio, #web, #java, #spring boot, #bootstrap, #thymeleaft, #spring security, #accesibilidad, #responsive

Recientemente he presentado mi proyecto fin de estudios de Formación Profesional de Grado Superior DAW. Era algo que llevaba aparcado durante demasiado tiempo y finalmente esta etapa se ha cerrado.

El proyecto ha consistido en una aplicación web monolítica, desarrollada en Java, usando el framework Spring Boot, y ha sido desplegada en el servicio de Railway.com.

El proyecto

El proyecto Cartelera DAW desarrolla una plataforma web para mostrar información cinematográfica cuyos usuarios potenciales son los espectadores y las distribuidoras de películas, cines y salas de proyección.

La plataforma, que está basada en Java y Spring Boot, utiliza un patrón Modelo-Vista-Controlador y una arquitectura cliente-servidor, haciendo uso del IDE IntelliJ IDEA, de Maven para la gestión del proyecto, de Git y GitHub para el versionado de código, de MySQL e Hibernate para la gestión de la base de datos y de una configuración LAMP dockerizada para las pruebas. Para el despliegue se utilizaron tecnologías como Docker y metodologías CI/CD. Para el frontend se ha empleado el gestor de plantillas Tymeleaft y Bootstrap.

Adicionalmente se proponen una serie de estrategias comerciales para garantizar la sostenibilidad del modelo empresarial del proyecto.

Se elaboró una memoria de 70 páginas y una presentación.

El objetivo era aprender y usar tecnologías nuevas no estudiadas en DAW.

La calificación final ha sido de 9 de 10, y se ha llevado a cabo en un periodo de tres semanas.

La formación previa

Pero el proyecto no partía de cero. Durante los meses de enero y febrero, y hasta el 9 de marzo de 2023, participé en un curso de especialización en Java + Spring de la Fundación Adecco dentro del Proyecto Digital School Erasmus+

Se trataba de una formación mentorizada que incluía un trabajo en grupo para desarrollar una aplicación web. En mi grupo de trabajo me encargué de la coordinación del equipo mediante Trello y de la planificación de las funcionalidades de la aplicación y las propuesta de mejora de la app. El grupo se llamaba Cinéfilos, y Cartelera DAW bebe de la estructura simple de aquella práctica que me sirvió para entender cómo funciona el framework.

El proyecto ahora presentado ha cambiado mucho desde aquella versión, tanto en su estructura como en su diseño. Partía de un código inconcluso donde sólo se habían implementado los CRUDs básicos, con fallos de integridad y sin funcionalidades mínimas, pero ahora la aplicación ha sido probada y revisada en profundidad, y cuenta con características que refuerzan sus funcionalidades.

En el curso, así como en la práctica, obtuve una calificación de 10/10.

Características

Además de los requisitos solicitados para el MVP, en la app se ha implementado:

Seguridad de rutas
Registros de usuario
Validaciones de formularios
Automatizaciones
Documentación con JavaDoc
Implementación de Logs
Notificaciones
Despliegue dockerizado

Cuenta con:

Portada dinámica
Diseño responsive
Diseño accesible
Aviso legal y privacidad
Aviso de cookies
Ayuda en línea
Spinner loader

Desarrollo y despliegue

Tanto en el desarrollo como en el despliegue ha jugado un papel importante Docker.

La BBDD MySQL y PHPMyAdmin han sido lanzados usando contenedores gestionados con la herramienta Portainer.

El despliegue se lleva a cabo tomando el código fuente y, mediante un dockerfile, construyendo la imagen del contenedor que es lanzado en el servidor.

Spring Boot contiene un servidor Tomcat encargado de servir las páginas de la aplicación.

Indicaciones de instalación

Tras clonar el repositorio, es necesario crear un usuario en la BBDD relacional llamado «cartelera-daw» con el password que deseemos. Estos datos, así como el puerto por defecto de la app (8082), pueden ser introducidos en el fichero «aplication.propieties», en la carpeta resources.

Cada vez que se inicia la aplicación, esta recarga los datos en la BBDD.

Una vez iniciada la aplicación en local, se puede acceder a ella en la dirección: http://localhost:8082

El acceso al panel de administración requiere de usuario y contraseña. Por defecto, la aplicación tiene un usuario «admin» y su contraseña es «admin».

ADVERTENCIA: Se recomienda que, tras el primer acceso, la contraseña de admin sea cambiada o se cree una nueva cuenta de usuario desde la que eliminar la cuenta «admin».

Licencia

Sobre el código fuente: GNU GENERAL PUBLIC LICENSE Version 3

Enlaces

Recursos TIC

JavGuerra — Wed, 11 Dec 2024 00:00:00 GMT

Etiquetas: #portfolio, #web, #java, #spring boot, #bootstrap, #thymeleaft, #spring security, #accesibilidad, #responsive, #selenium, #api, #swagger, #javadoc, #junit, #mockito, #docker, #jacoco, #github actions, #ci-cd, #sonarqube

Recientemente he cursado una formación con Adecco, y este es mi proyecto fin de estudios, que ha consistido en desarrollar una aplicación que permita gestionar recursos TIC y listas de recursos, para realizar los tests correspondientes, aplicando los conocimientos aprendidos, y que ha sido desplegada en el servicio de Railway.com.

El proyecto

La plataforma, que está basada en Java y Spring Boot, utiliza un patrón Modelo-Vista-Controlador y una arquitectura cliente-servidor, haciendo uso del IDE IntelliJ IDEA, de Maven para la gestión del proyecto, de Git y GitHub para el versionado de código, de MySQL, H2 y el ORM Hibernate para la gestión de la base de datos y de una configuración LAMP dockerizada para las pruebas.

Para el frontend se ha empleado el gestor de plantillas Tymeleaft y Bootstrap.

Para los tests se ha usado JUnit, Mockito, Selenium. la API se ha probado con Swagger y las estadísticas se han generado con JaCoCo y SonarQube.

Para el despliegue se utilizaron tecnologías como Docker y metodologías CI/CD con GitHub Actions.

La planificación y codificación se han llevado a cabo usando Trello.

Destacados

Además de los requisitos del MVP, se han incluido las siguientes funcionalidades:

Diseño responsive, “mobile first”
Web accesible AA. Testada con WAVE
Seguridad por diseño
Confirmaciones de borrado
Implementación de login de usuarios
Integra el editor TinyMCE
Provee API REST e interfaz Swagger
Incluye aviso legal, privacidad y cookies
Documentación la aplicación con JavaDoc
Usa el protocolo OpenGraph para RR.SS.
Manifest para móviles (PWA)
Desarrollada con Linux + Docker LAMP
Despliegue

Video

El proyecto fue presentado a empresas de tecnología, y se puede ver en el vídeo de la presentación del proyecto aquí:

Indicaciones de uso

Requisitos

Para ejecutar el proyecto se requiere:

Java 23 o superior
Maven
MySQL
Docker

Configuración

Actualmente la aplicación se ejecuta localmente en el puerto 8082.

Puede construirse un contenedor Docker con la imagen de la aplicación ejecutando el fichero docker.sh que hace uso de docker-compose para lanzar la aplicación y la BBDD que requiere.

Para generar un informe de cobertura de testing, se puede ejecutar el comando mvn site y acceder a él en el directorio target/site/jacoco/index.html.

Códice | Entradas sobre «spring security»

Logout personalizado con Spring Security

El contexto de seguridad

Tomando el control de Logout

Refinando el logout

Consideraciones

Un ejemplo

Cartelera DAW

El proyecto

La formación previa

Características

Desarrollo y despliegue

Indicaciones de instalación

Licencia

Enlaces

Recursos TIC

El proyecto

Destacados

Video

Indicaciones de uso

Requisitos

Configuración

Autores

Licencia

Enlaces