example grails spring-security grails-plugin

example - Cómo omitir condicionalmente el filtro SecurityContextPersistenceFilter en la cadena de filtros de plugins de Grails Spring Security



spring security grails 3.3 1 (2)

Daniel, tu solución funcionó. Aquí está mi fragmento

@Override public SecurityContext loadContext(HttpRequestResponseHolder requestResponseHolder) { logger.debug("loadContext entry"); String ssoParameter = requestResponseHolder.getRequest().getParameter("sso"); if (ssoParameter != null && ssoParameter.equalsIgnoreCase("true")) { HttpSession session = requestResponseHolder.getRequest().getSession(false); if (session != null) session.invalidate(); } return super.loadContext(requestResponseHolder); }

Tengo un escenario único que estoy tratando de resolver bajo las limitaciones del complemento Spring Security (versión 1.2.7.3 si es currious). Creé un complemento SSO personalizado que permite el inicio de sesión con una URL firmada. El complemento personalizado funciona muy bien, y lo he agregado de acuerdo con la documentación al crear los beans en resources.groovy y agregarlos a la cadena de filtros dentro de BootStrap.groovy.

SpringSecurityUtils.clientRegisterFilter(''ssoFilter'', SecurityFilterPosition.SECURITY_CONTEXT_FILTER.order + 10)

Una vez que el usuario inicia sesión, todo funciona bien y la sesión activa existente que se agregó al contexto de seguridad autentica al usuario.

Tengo un caso de uso donde es posible que un usuario que ya está autenticado pueda regresar al mismo navegador (es decir, la misma cookie de sesión) con un usuario diferente en una solicitud de SSO. Me gustaría que la cadena de filtros detecte el ''sso = true'' en la cadena de consulta de la URL.

El comportamiento que estoy viendo ahora es que nunca se llega al SSO porque el usuario original ya está autenticado por el contexto de seguridad. No puedo agregar el filtro SSO antes del SecurityContextPersistenceFilter, ya que causa problemas donde el filtro SSO se golpea constantemente y no se procesa nada. Esto sigue a documentos donde lo he visto decir que no debe poner ningún filtro por delante del filtro de contexto de seguridad.

He investigado la creación de una cadena de filtro especial específicamente para URL con ''sso = true'' (algo que estoy haciendo durante el flujo no autenticado añadiendo una implementación personalizada de RequestMatcher y AuthenticationEntryPoint al DelegatingAuthenticationEntryPoint ) utilizando springsecurity.filterChain.chainMap config. Sin embargo, de los documentos y experimentos se desprende que solo se filtra la ruta.

¿Hay alguna forma de garantizar que cada vez que se vea "sso = true" en la URL, que se golpee el filtro SSO mientras todavía esté disponible para el contexto de seguridad o que SecurityContextPersistenceFilter pueda pasar la solicitud al filtro SSO?


Me parece que podría usar un SecurityContextRepository personalizado.

La versión 1.2.7.3 del complemento Spring Security Grails parece usar Spring Security 3.0.7. Como se menciona en la Sección 8.3.1 de la referencia de Spring Security, de Spring Security 3.0 en adelante, SecurityContextPersistenceFilter está configurado con un bean SecurityContextRepository , que se encarga de cargar y guardar SecurityContext . Por defecto, esta es una instancia de HttpSessionSecurityContextRepository .

Puede crear una clase personalizada que amplíe HttpSessionSecurityContextRepository . La subclase personalizada puede anular el método loadContext (HttpRequestResponseHolder) para eliminar el atributo de sesión "SPRING_SECURITY_CONTEXT" si la solicitud contiene el parámetro de consulta sso=true .

Puede ver la implementación de HttpSessionSecurityContextRepository en Spring Security 3.0.7 en GitHub:
https://github.com/spring-projects/spring-security/blob/3.0.7.RELEASE/web/src/main/java/org/springframework/security/web/context/HttpSessionSecurityContextRepository.java

Relacionado: ¿Cómo puedo usar Spring Security sin sesiones?