Cómo funciona la cadena de filtros Spring Security

Me doy cuenta de que la seguridad de Spring se basa en una cadena de filtros, que interceptará la solicitud, detectará (ausencia de) autenticación, redirigirá al punto de entrada de autenticación o pasará la solicitud al servicio de autorización y, finalmente, dejará que la solicitud llegue al servlet o arroje una excepción de seguridad (no autenticado o no autorizado). DelegatingFitlerProxy pega estos filtros juntos. Para realizar sus tareas, estos servicios de acceso de filtro, como UserDetailsService y AuthenticationManager .

Los filtros clave en la cadena son (en el orden)

• SecurityContextPersistenceFilter (restaura la autenticación de JSESSIONID)
• UsernamePasswordAuthenticationFilter (realiza la autenticación)
• ExceptionTranslationFilter (captura excepciones de seguridad de FilterSecurityInterceptor)
• FilterSecurityInterceptor (puede arrojar excepciones de autenticación y autorización)

Estoy confundido sobre cómo se usan estos filtros. ¿Es que para el inicio de sesión proporcionado por la primavera, UsernamePasswordAuthenticationFilter solo se usa para / login , y los últimos filtros no? ¿El elemento de espacio de nombres de inicio de sesión configura automáticamente estos filtros? ¿Cada solicitud (autenticada o no) llega a FilterSecurityInterceptor para la URL sin inicio de sesión?

¿Qué sucede si deseo asegurar mi API REST con JWT-token , que se recupera del inicio de sesión? Debo configurar dos httpetiquetas de configuración de espacio de nombres , ¿derechos? Uno para / iniciar sesión con UsernamePasswordAuthenticationFilter, y otro para URL de REST, con personalizado JwtAuthenticationFilter.

¿La configuración de dos httpelementos crea dos springSecurityFitlerChains? Está UsernamePasswordAuthenticationFilterdesactivado por defecto, hasta que declare form-login? ¿Cómo lo reemplazo SecurityContextPersistenceFiltercon un filtro que se obtendrá Authenticationde los existentes en JWT-tokenlugar de JSESSIONID?

La cadena de filtros de seguridad Spring es un motor muy complejo y flexible.

Los filtros clave en la cadena son (en el orden)

• SecurityContextPersistenceFilter (restaura la autenticación de JSESSIONID)
• UsernamePasswordAuthenticationFilter (realiza la autenticación)
• ExceptionTranslationFilter (captura excepciones de seguridad de FilterSecurityInterceptor)
• FilterSecurityInterceptor (puede arrojar excepciones de autenticación y autorización)

Mirando la documentación actual de la versión estable 4.2.1 , sección 13.3 Orden de filtros , puede ver toda la organización de filtros de la cadena de filtros:

13.3 Ordenar filtros

El orden en que se definen los filtros en la cadena es muy importante. Independientemente de los filtros que esté utilizando, el orden debe ser el siguiente:

1. ChannelProcessingFilter , porque podría necesitar redirigir a un protocolo diferente

2. SecurityContextPersistenceFilter , por lo que se puede configurar un SecurityContext en SecurityContextHolder al comienzo de una solicitud web, y cualquier cambio en SecurityContext se puede copiar en HttpSession cuando finaliza la solicitud web (listo para usar con la próxima solicitud web)

3. ConcurrentSessionFilter , porque utiliza la funcionalidad SecurityContextHolder y necesita actualizar SessionRegistry para reflejar las solicitudes en curso del director

4. Mecanismos de procesamiento de autenticación - UsernamePasswordAuthenticationFilter , CasAuthenticationFilter , BasicAuthenticationFilter , etc. - para que SecurityContextHolder se pueda modificar para que contenga un token de solicitud de autenticación válido

5. El SecurityContextHolderAwareRequestFilter , si lo está utilizando para instalar un HttpServletRequestWrapper consciente de Spring Security en su contenedor de servlet

6. El JaasApiIntegrationFilter , si un JaasAuthenticationToken está en el SecurityContextHolder esto va a procesar el FilterChain como el sujeto en el JaasAuthenticationToken

7. RememberMeAuthenticationFilter , de modo que si ningún mecanismo de procesamiento de autenticación anterior actualizó SecurityContextHolder y la solicitud presenta una cookie que permite que se realicen los servicios recordar, se colocará un objeto de autenticación recordado adecuado

8. AnonymousAuthenticationFilter , de modo que si ningún mecanismo de procesamiento de autenticación anterior actualizara SecurityContextHolder, se colocará un objeto de autenticación anónimo

9. ExceptionTranslationFilter , para detectar cualquier excepción de Spring Security para que se pueda devolver una respuesta de error HTTP o se pueda iniciar un AuthenticationEntryPoint apropiado

10. FilterSecurityInterceptor , para proteger los URI web y generar excepciones cuando se deniega el acceso

Ahora, intentaré continuar con sus preguntas una por una:

Estoy confundido sobre cómo se usan estos filtros. ¿Es que para el inicio de sesión proporcionado por la primavera, UsernamePasswordAuthenticationFilter solo se usa para / login, y los últimos filtros no? ¿El elemento de espacio de nombres de inicio de sesión configura automáticamente estos filtros? ¿Todas las solicitudes (autenticadas o no) llegan a FilterSecurityInterceptor para la URL sin inicio de sesión?

Una vez que esté configurando una <security-http>sección, para cada una debe proporcionar al menos un mecanismo de autenticación. Este debe ser uno de los filtros que coinciden con el grupo 4 en la sección 13.3 Orden de filtros de la documentación de Spring Security que acabo de mencionar.

Esta es la seguridad mínima válida: elemento http que se puede configurar:

<security:http authentication-manager-ref="mainAuthenticationManager" 
               entry-point-ref="serviceAccessDeniedHandler">
    <security:intercept-url pattern="/sectest/zone1/**" access="hasRole('ROLE_ADMIN')"/>
</security:http>

Simplemente, estos filtros se configuran en el proxy de la cadena de filtros:

{
        "1": "org.springframework.security.web.context.SecurityContextPersistenceFilter",
        "2": "org.springframework.security.web.context.request.async.WebAsyncManagerIntegrationFilter",
        "3": "org.springframework.security.web.header.HeaderWriterFilter",
        "4": "org.springframework.security.web.csrf.CsrfFilter",
        "5": "org.springframework.security.web.savedrequest.RequestCacheAwareFilter",
        "6": "org.springframework.security.web.servletapi.SecurityContextHolderAwareRequestFilter",
        "7": "org.springframework.security.web.authentication.AnonymousAuthenticationFilter",
        "8": "org.springframework.security.web.session.SessionManagementFilter",
        "9": "org.springframework.security.web.access.ExceptionTranslationFilter",
        "10": "org.springframework.security.web.access.intercept.FilterSecurityInterceptor"
    }

Nota: Los obtengo creando un RestController simple que @Autowires FilterChainProxy y devuelve su contenido:

    @Autowired
    private FilterChainProxy filterChainProxy;

    @Override
    @RequestMapping("/filterChain")
    public @ResponseBody Map<Integer, Map<Integer, String>> getSecurityFilterChainProxy(){
        return this.getSecurityFilterChainProxy();
    }

    public Map<Integer, Map<Integer, String>> getSecurityFilterChainProxy(){
        Map<Integer, Map<Integer, String>> filterChains= new HashMap<Integer, Map<Integer, String>>();
        int i = 1;
        for(SecurityFilterChain secfc :  this.filterChainProxy.getFilterChains()){
            //filters.put(i++, secfc.getClass().getName());
            Map<Integer, String> filters = new HashMap<Integer, String>();
            int j = 1;
            for(Filter filter : secfc.getFilters()){
                filters.put(j++, filter.getClass().getName());
            }
            filterChains.put(i++, filters);
        }
        return filterChains;
    }

Aquí podríamos ver que solo al declarar el <security:http>elemento con una configuración mínima, se incluyen todos los filtros predeterminados, pero ninguno de ellos es del tipo Autenticación (4to grupo en la sección 13.3 Orden de filtros). Entonces, en realidad significa que con solo declarar el security:httpelemento, SecurityContextPersistenceFilter, ExceptionTranslationFilter y FilterSecurityInterceptor se configuran automáticamente.

De hecho, se debe configurar un mecanismo de procesamiento de autenticación, e incluso el procesamiento de beans de espacio de nombres de seguridad reclama eso, arrojando un error durante el inicio, pero se puede omitir agregando un atributo de entrada-punto-referencia en <http:security>

Si agrego un básico <form-login>a la configuración, de esta manera:

<security:http authentication-manager-ref="mainAuthenticationManager">
    <security:intercept-url pattern="/sectest/zone1/**" access="hasRole('ROLE_ADMIN')"/>
    <security:form-login />
</security:http>

Ahora, el filterChain será así:

{
        "1": "org.springframework.security.web.context.SecurityContextPersistenceFilter",
        "2": "org.springframework.security.web.context.request.async.WebAsyncManagerIntegrationFilter",
        "3": "org.springframework.security.web.header.HeaderWriterFilter",
        "4": "org.springframework.security.web.csrf.CsrfFilter",
        "5": "org.springframework.security.web.authentication.UsernamePasswordAuthenticationFilter",
        "6": "org.springframework.security.web.authentication.ui.DefaultLoginPageGeneratingFilter",
        "7": "org.springframework.security.web.savedrequest.RequestCacheAwareFilter",
        "8": "org.springframework.security.web.servletapi.SecurityContextHolderAwareRequestFilter",
        "9": "org.springframework.security.web.authentication.AnonymousAuthenticationFilter",
        "10": "org.springframework.security.web.session.SessionManagementFilter",
        "11": "org.springframework.security.web.access.ExceptionTranslationFilter",
        "12": "org.springframework.security.web.access.intercept.FilterSecurityInterceptor"
    }

Ahora, estos dos filtros org.springframework.security.web.authentication.UsernamePasswordAuthenticationFilter y org.springframework.security.web.authentication.ui.DefaultLoginPageGeneratingFilter se crean y configuran en FilterChainProxy.

Entonces, ahora, las preguntas:

¿Es que para el inicio de sesión proporcionado por la primavera, UsernamePasswordAuthenticationFilter solo se usa para / login, y los últimos filtros no?

Sí, se utiliza para intentar completar un mecanismo de procesamiento de inicio de sesión en caso de que la solicitud coincida con la URL de UsernamePasswordAuthenticationFilter. Esta url se puede configurar o incluso cambiar su comportamiento para que coincida con cada solicitud.

También podría tener más de un mecanismo de procesamiento de autenticación configurado en el mismo FilterchainProxy (como HttpBasic, CAS, etc.).

¿El elemento de espacio de nombres de inicio de sesión configura automáticamente estos filtros?

No, el elemento form-login configura UsernamePasswordAUthenticationFilter, y en caso de que no proporcione una URL de página de inicio de sesión, también configura org.springframework.security.web.authentication.ui.DefaultLoginPageGeneratingFilter, que termina en un inicio de sesión simple autogenerado página.

Los otros filtros se configuran automáticamente de forma predeterminada simplemente creando un <security:http>elemento sin security:"none"atributo.

¿Todas las solicitudes (autenticadas o no) llegan a FilterSecurityInterceptor para la URL sin inicio de sesión?

Cada solicitud debe llegar a ella, ya que es el elemento que se encarga de si la solicitud tiene los derechos para llegar a la URL solicitada. Pero algunos de los filtros procesados ​​antes podrían detener el procesamiento de la cadena de filtros simplemente no llamando FilterChain.doFilter(request, response);. Por ejemplo, un filtro CSRF podría detener el procesamiento de la cadena de filtros si la solicitud no tiene el parámetro csrf.

¿Qué sucede si deseo asegurar mi API REST con JWT-token, que se recupera del inicio de sesión? Debo configurar dos etiquetas http de configuración de espacio de nombres, ¿derechos? Otro para / iniciar sesión con UsernamePasswordAuthenticationFilter, y otro para URL de REST, con personalizado JwtAuthenticationFilter.

No, no estás obligado a hacerlo de esta manera. Puede declarar ambos UsernamePasswordAuthenticationFiltery el JwtAuthenticationFilteren el mismo elemento http, pero depende del comportamiento concreto de cada uno de estos filtros. Ambos enfoques son posibles, y cuál elegir finalmente depende de sus propias preferencias.

¿La configuración de dos elementos http crea dos springSecurityFitlerChains?

Sí, eso es verdad

¿UsernamePasswordAuthenticationFilter está desactivado por defecto, hasta que declare el inicio de sesión de formulario?

Sí, puedes verlo en los filtros generados en cada una de las configuraciones que publiqué

¿Cómo puedo reemplazar SecurityContextPersistenceFilter con uno, que obtendrá la autenticación del token JWT existente en lugar de JSESSIONID?

Puede evitar SecurityContextPersistenceFilter, simplemente configurando la estrategia de sesión en <http:element>. Solo configúrelo así:

<security:http create-session="stateless" >

O, en este caso, podría sobrescribirlo con otro filtro, de esta manera dentro del <security:http>elemento:

<security:http ...>  
   <security:custom-filter ref="myCustomFilter" position="SECURITY_CONTEXT_FILTER"/>    
</security:http>
<beans:bean id="myCustomFilter" class="com.xyz.myFilter" />

EDITAR:

Una pregunta sobre "También podría tener más de un mecanismo de procesamiento de autenticación configurado en el mismo FilterchainProxy". ¿Este último sobrescribirá la autenticación realizada por el primero, si declara múltiples filtros de autenticación (implementación Spring)? ¿Cómo se relaciona esto con tener múltiples proveedores de autenticación?

Esto finalmente depende de la implementación de cada filtro en sí, pero es cierto el hecho de que los últimos filtros de autenticación al menos pueden sobrescribir cualquier autenticación previa que eventualmente haya hecho los filtros anteriores.

Pero esto no necesariamente sucederá. Tengo algunos casos de producción en servicios REST seguros donde utilizo un tipo de token de autorización que se puede proporcionar como un encabezado Http o dentro del cuerpo de la solicitud. Así que configuro dos filtros que recuperan ese token, en un caso del encabezado Http y el otro del cuerpo de la solicitud de la propia solicitud de descanso. Es cierto el hecho de que si una solicitud http proporciona ese token de autenticación como encabezado Http y dentro del cuerpo de la solicitud, ambos filtros intentarán ejecutar el mecanismo de autenticación delegándolo al administrador, pero podría evitarse fácilmente simplemente verificando si la solicitud es ya autenticado justo al comienzo del doFilter()método de cada filtro.

Tener más de un filtro de autenticación está relacionado con tener más de un proveedor de autenticación, pero no lo fuerce. En el caso que expuse antes, tengo dos filtros de autenticación, pero solo tengo un proveedor de autenticación, ya que ambos filtros crean el mismo tipo de objeto de autenticación, por lo que en ambos casos el administrador de autenticación lo delega al mismo proveedor.

Y frente a esto, yo también tengo un escenario en el que publico solo un UsernamePasswordAuthenticationFilter pero las credenciales del usuario pueden estar contenidas en DB o LDAP, por lo que tengo dos proveedores de soporte UsernamePasswordAuthenticationToken, y AuthenticationManager delega cualquier intento de autenticación del filtro a los proveedores secuencialmente para validar las credenciales.

Entonces, creo que está claro que ni la cantidad de filtros de autenticación determina la cantidad de proveedores de autenticación ni la cantidad de proveedores determina la cantidad de filtros.

Además, la documentación indica que SecurityContextPersistenceFilter es responsable de limpiar SecurityContext, que es importante debido a la agrupación de subprocesos. Si lo omito o proporciono una implementación personalizada, tengo que implementar la limpieza manualmente, ¿verdad? ¿Hay más trucos similares al personalizar la cadena?

No examiné cuidadosamente este filtro antes, pero después de su última pregunta, he estado revisando su implementación y, como generalmente en Spring, casi todo se puede configurar, extender o sobrescribir.

Los SecurityContextPersistenceFilter delegados en un SecurityContextRepository aplicación la búsqueda de los SecurityContext. Por defecto, se utiliza un HttpSessionSecurityContextRepository , pero esto podría cambiarse utilizando uno de los constructores del filtro. Por lo tanto, puede ser mejor escribir un SecurityContextRepository que se ajuste a sus necesidades y simplemente configurarlo en SecurityContextPersistenceFilter, confiando en su comportamiento comprobado en lugar de comenzar a hacer todo desde cero.

UsernamePasswordAuthenticationFiltersolo se usa /loginy los últimos filtros no.

No, se UsernamePasswordAuthenticationFilterextiende AbstractAuthenticationProcessingFilter, y esto contiene un RequestMatcher, eso significa que puede definir su propia url de procesamiento, este filtro solo maneja las RequestMatchercoincidencias con la url de solicitud, la url de procesamiento predeterminada es /login.

Los filtros posteriores aún pueden manejar la solicitud, si se UsernamePasswordAuthenticationFilterejecuta chain.doFilter(request, response);.

Más detalles sobre los montadores centrales

¿El elemento de espacio de nombres de inicio de sesión configura automáticamente estos filtros?

UsernamePasswordAuthenticationFilteres creado por <form-login>, estos son alias de filtro estándar y pedidos

¿Todas las solicitudes (autenticadas o no) llegan a FilterSecurityInterceptor para la URL sin inicio de sesión?

Depende de si los instaladores anteriores tienen éxito, pero FilterSecurityInterceptornormalmente es el último instalador.

¿La configuración de dos elementos http crea dos springSecurityFitlerChains?

Sí, cada fitlerChain tiene una RequestMatcher, si RequestMatchercoincide con la solicitud, la solicitud será manejada por los instaladores en la cadena de instaladores.

El valor predeterminado RequestMatchercoincide con todas las solicitudes si no configura el patrón, o puede configurar la url específica ( <http pattern="/rest/**").

Si quieres saber más sobre los fitlers, creo que puedes consultar el código fuente en seguridad de primavera. doFilter(ServletRequest request, ServletResponse response, FilterChain filterChain)

Spring Security es un marco basado en filtros, planta un WALL (HttpFireWall) antes de su aplicación en términos de filtros proxy o beans gestionados por Spring. Su solicitud debe pasar por varios filtros para llegar a su API.

Secuencia de ejecución en Spring Security

1. WebAsyncManagerIntegrationFilter Proporciona integración entre SecurityContext y el WebAsyncManager de Spring Web.
   

2. SecurityContextPersistenceFilterEste filtro solo se ejecutará una vez por solicitud, rellena el SecurityContextHolder con la información obtenida del SecurityContextRepository configurado antes de la solicitud y la almacena de nuevo en el repositorio una vez que la solicitud se ha completado y borra el contenedor de contexto.
   La solicitud se verifica para la sesión existente. Si hay una nueva solicitud, se creará SecurityContext; de lo contrario, si la solicitud tiene sesión, el contexto de seguridad existente se obtendrá del repositorio .

3. HeaderWriterFilter Implementación de filtro para agregar encabezados a la respuesta actual.

4. LogoutFilterSi la solicitud es url /logout(para la configuración por defecto) o si mathces solicitud de URL RequestMatcherconfigurados de LogoutConfigurerentonces

   • borra el contexto de seguridad.
   • invalida la sesión
   • elimina todas las cookies con nombres de cookies configurados en LogoutConfigurer
   • Redirige a la url de éxito predeterminada de cierre de /sesión o url de éxito de cierre de sesión configurada o invoca logoutSuccessHandler configurado.

5. UsernamePasswordAuthenticationFilter

   • Para cualquier url de solicitud que no sea loginProcessingUrl, este filtro no se procesará más, pero la cadena de filtros simplemente continúa.
   • Si se solicita el URL es partidos (debe ser HTTP POST) por defecto /logino partidos .loginProcessingUrl()configurados en FormLoginConfigurerentonces UsernamePasswordAuthenticationFilterla autenticación intentos.
   • parámetros del formulario de inicio de sesión por defecto son nombre de usuario y contraseña, puede ser anulado por usernameParameter(String), passwordParameter(String).
   • la configuración .loginPage() anula los valores predeterminados
   • Al intentar la autenticación
     • se crea un Authenticationobjeto ( UsernamePasswordAuthenticationTokeno cualquier implementación Authenticationen caso de su filtro de autenticación personalizado).
     • y authenticationManager.authenticate(authToken)será invocado
       
     • Tenga en cuenta que podemos configurar cualquier número de AuthenticationProvidermétodo de autenticación que intente con todos los proveedores de autenticación y verifique cualquiera de los proveedores de autenticación supportsauthToken / objeto de autenticación, se utilizará el proveedor de autenticación compatible para la autenticación. y devuelve el objeto de autenticación en caso de autenticación exitosa, de lo contrario, se lanza AuthenticationException.
   • Si se creará una sesión de autenticación exitosa y authenticationSuccessHandlerse invocará, se redireccionará a la URL de destino configurada (el valor predeterminado es /)
   • Si la autenticación falló, el usuario se convierte en usuario no autenticado y la cadena continúa.

6. SecurityContextHolderAwareRequestFilter, si lo está utilizando para instalar un HttpServletRequestWrapper consciente de Spring Security en su contenedor de servlet

7. AnonymousAuthenticationFilterDetecta si no hay un objeto de autenticación en SecurityContextHolder, si no se encuentra ningún objeto de autenticación, crea un Authenticationobjeto ( AnonymousAuthenticationToken) con autorización otorgada ROLE_ANONYMOUS. Aquí AnonymousAuthenticationTokenfacilita la identificación de solicitudes posteriores de usuarios no autenticados.
   

DEBUG - /app/admin/app-config at position 9 of 12 in additional filter chain; firing Filter: 'AnonymousAuthenticationFilter'
DEBUG - Populated SecurityContextHolder with anonymous token: 'org.springframework.security.authentication.AnonymousAuthenticationToken@aeef7b36: Principal: anonymousUser; Credentials: [PROTECTED]; Authenticated: true; Details: org.springframework.security.web.authentication.WebAuthenticationDetails@b364: RemoteIpAddress: 0:0:0:0:0:0:0:1; SessionId: null; Granted Authorities: ROLE_ANONYMOUS' 

8. ExceptionTranslationFilter, para detectar cualquier excepción de Spring Security para que se pueda devolver una respuesta de error HTTP o se pueda iniciar un AuthenticationEntryPoint apropiado

9. FilterSecurityInterceptor
   Habrá FilterSecurityInterceptorcasi el último en la cadena de filtros que obtiene el objeto de autenticación SecurityContexty obtiene la lista de autoridades (roles otorgados) y tomará la decisión de permitir que esta solicitud llegue al recurso solicitado o no, la decisión se toma haciendo coincidir con lo permitido AntMatchersconfigurado en HttpSecurityConfiguration.

Considere las excepciones 401-No autorizadas y 403-Prohibidas. Estas decisiones se tomarán al final de la cadena de filtros.

• Un usuario autenticado que intenta acceder al recurso público: permitido
  
• Un usuario autenticado que intenta acceder al recurso seguro - 401-No autorizado
  
• Usuario autenticado que intenta acceder a recursos restringidos (restringido por su rol) - 403-Prohibido
  

Nota: Solicitud de Usuario fluye no sólo en filtros anteriormente mencionado, pero hay otros filtros también que no se muestran aquí (. ConcurrentSessionFilter, RequestCacheAwareFilter, SessionManagementFilter...)
Será diferente cuando se utiliza el filtro de autenticación personalizado en lugar de UsernamePasswordAuthenticationFilter.
Será diferente si configura el filtro de autenticación JWT y omite .formLogin() i.e, UsernamePasswordAuthenticationFilterque se convertirá en un caso completamente diferente.

De la documentación, el orden de los filtros se da como

• ChannelProcessingFilter
• ConcurrentSessionFilter
• SecurityContextPersistenceFilter
• Cerrar sesión
• X509AuthenticationFilter
• AbstractPreAuthenticatedProcessingFilter
• CasAuthenticationFilter
• UsernamePasswordAuthenticationFilter
• ConcurrentSessionFilter
• OpenIDAuthenticationFilter
• DefaultLoginPageGeneratingFilter
• DefaultLogoutPageGeneratingFilter
• ConcurrentSessionFilter
• Digesto Autenticación Filtro
• Portador Tomado Autenticación Filtro
• BasicAuthenticationFilter
• RequestCacheAwareFilter
• SecurityContextHolderAwareRequestFilter
• JaasApiIntegrationFilter
• RememberMeAuthenticationFilter
• Anónimo Autenticación Filtro
• SessionManagementFilter
• ExceptionTranslationFilter
• FilterSecurityInterceptor
• SwitchUserFilter

¿También puede referirse a la forma
más común de autenticar una aplicación web moderna?
diferencia entre autenticación y autorización en el contexto de Spring Security?