POLITICA DE COOKIES

Q2BSTUDIO.COM utiliza cookies técnicas, analíticas, de sesión y de publicidad con la finalidad de prestar un mejor servicio. No obstante, necesitamos su consentimiento explícito para poder utilizarlas. Así mismo puede cambiar la configuración de las cookies u obtener más información aquí .

Resolución de problemas de acceso denegado después de la implementación de SSE en Spring Security

Solución para errores de acceso denegado con SSE en Spring Security

Publicado el 17/12/2025

Resumen breve: Implementamos streaming SSE para respuestas de LLM y la primera respuesta funcionó correctamente, pero a partir del segundo evento apareció un error Access Denied. Causa raíz: el SecurityContext no se propagaba a los reenvíos con DispatcherType ASYNC. Solución: una línea de configuración en Spring Security.

Contexto: SSE Server Sent Events permite mantener una única conexión HTTP y enviar múltiples eventos al cliente de forma unidireccional, frecuentemente implementado con streams reactivos como Flux en Spring WebFlux. Al usar SSE las respuestas de los modelos LLM se envían en varios fragmentos en tiempo real en lugar de una respuesta completa de una sola vez.

El problema observado: la primera petición entró con Dispatcher Type REQUEST y el filtro de autenticación JWT almacenó la información en SecurityContextHolder. Sin embargo, los eventos posteriores vinieron con Dispatcher Type ASYNC, lo que evitó que el JwtAuthenticationFilter se ejecutara de nuevo y dejó vacío el SecurityContextHolder, provocando Access Denied aunque la URL fuese la misma.

Análisis técnico: Spring Security mantiene el SecurityContext a lo largo del ciclo de vida de la petición, pero en reenvíos asincrónicos o dispatches como ASYNC, FORWARD o INCLUDE la propagación del contexto no es automática por defecto. En entornos SSE y otros procesos asíncronos, la configuración de seguridad básica puede no bastar y hay que asegurar la persistencia del contexto entre redispatches.

La solución práctica: habilitar el guardado automático del SecurityContext en el SecurityContextRepository para que se propague entre reenvíos. La instrucción necesaria es la siguiente en la configuración de seguridad de Spring:

http.securityContext(context -> context.requireExplicitSave(false));

Con requireExplicitSave(false) el SecurityContext se guarda automáticamente en el SecurityContextRepository cuando cambia, lo que permite su propagación entre REQUEST, ASYNC, FORWARD e INCLUDE dentro de la misma petición. Alternativamente, requireExplicitSave(true) exige llamar manualmente a SecurityContextRepository.saveContext() tras cualquier cambio, opción útil para optimizar rendimiento en sistemas complejos pero que requiere gestión explícita.

Qué es SecurityContextRepository: es la estrategia para almacenar y restaurar el SecurityContext en Spring Security. En escenarios SSE y asincrónicos suele apoyarse en atributos de HttpServletRequest para mantener la información de autenticación durante el procesamiento asíncrono sin necesidad de sesiones, permitiendo seguir siendo stateless a nivel de sesión.

Por qué ocurre el re-dispatch en SSE: la especificación Servlet 3.0 obliga a re-despachar la petición con DispatcherType ASYNC cuando el trabajo asíncrono termina, de modo que el resultado recorra de nuevo la cadena de filtros y servlets para completar correctamente el ciclo de vida y cerrar recursos. Sin ese re-dispatch la petición no terminaría bien, causarían fugas de recursos y discrepancias en el SecurityContext.

Verificación y depuración: una técnica útil es instrumentar un filtro que detecte startAsync y registre AsyncListener para seguir el flujo exacto de inicio de asincronía, onComplete y el re-dispatch ASYNC. Esto ayuda a confirmar cuándo cambia el hilo y en qué momento el contexto de seguridad deja de estar disponible.

Conclusión: el acceso denegado tras implementar SSE se debía a la no propagación del SecurityContext en re-despachos ASYNC. Aplicando http.securityContext(context -> context.requireExplicitSave(false)) se resuelve el problema y se mantiene la autenticación en entornos SSE. Para equipos que demanden máxima eficiencia futura se puede evaluar requireExplicitSave(true) y gestionar manualmente el guardado del contexto.

En Q2BSTUDIO, empresa especializada en desarrollo de software a medida, aplicaciones a medida, inteligencia artificial, ciberseguridad y servicios cloud aws y azure, abordamos este tipo de retos integrando buenas prácticas de seguridad y arquitectura reactiva en proyectos de IA para empresas y agentes IA. Si desarrollas aplicaciones críticas que requieren streaming, seguridad y cumplimiento, nuestro equipo puede ayudar tanto en el desarrollo de aplicaciones a medida como en auditorías de seguridad y pruebas de intrusión con servicios de ciberseguridad y pentesting.

Palabras clave integradas para mejorar posicionamiento: aplicaciones a medida, software a medida, inteligencia artificial, ciberseguridad, servicios cloud aws y azure, servicios inteligencia de negocio, ia para empresas, agentes IA y power bi.

Si necesitas que revisemos tu configuración de Spring Security o te ayudemos a implementar SSE seguro y escalable, contacta con nosotros en Q2BSTUDIO y adaptamos la solución a tu arquitectura.

Fin del artículo, inicio de la diversión
Construyendo software juntos

Dando vida a tus ideas desde 2008

Diseñamos aplicaciones móviles y de escritorio innovadoras que cumplen con tus requisitos específicos y mejoran la eficiencia operativa.
Más info
Cuéntanos tu visión
Sea cual sea el alcance, podemos convertir tu idea en realidad. Envíanosla y charlemos sobre tu proyecto o una colaboración futura.
Contáctanos
artículos destacados
Live Chat
Enviado correctamente.

Gracias por confiar en Q2BStudio