¿Cómo puedo determinar qué funciones se requieren para acceder a una URL con Spring Security?

Question

Estoy usando Spring Security para asegurar una aplicación web. Las direcciones URL se aseguró de esta manera:

<security:http entry-point-ref="authenticationEntryPoint"> 
    <security:intercept-url pattern="/" access="ROLE_ANONYMOUS" /> 
    <security:intercept-url pattern="/assets/**/*" access="ROLE_ANONYMOUS" /> 
    ... 
    <security:intercept-url pattern="/**" access="ROLE_USER" /> 
    <security:anonymous granted-authority="ROLE_ANONYMOUS" /> 
</security:http> 

tengo un filtro que necesita para redirigir al usuario a una página especial en determinadas circunstancias. Sin embargo, esa página requiere imágenes y archivos CSS en el directorio de activos, que desafortunadamente también serán redirigidos a esa página especial. No quiero que el filtro compruebe manualmente cada patrón de URL porque mi configuración de URL real es mucho más larga y también quiero permitir otras páginas.

¿Hay alguna manera de determinar a partir del filtro para una página determinada qué roles se requieren? Podría elegir no redirigir si ROLE_ANONYMOUS no es obligatorio.

Answer 1

No olvide que lo que realmente ocurre al decidir si se permite el acceso es que la URL y la autenticación existente se pasa a través de una serie de AccessDecisionVoter s, una de las predeterminadas es RoleVoter. Este votante verifica la configuración del recurso solicitado, y si se requiere un rol específico, denegará la solicitud si la autenticación existente no tiene ese rol.

Entonces, para la solución, puede agregar a otros votantes que entren antes que el votante de la función. Cada votante debe devolver GRANT, DENY o ABSTAIN, y el procesamiento solo continúa para los votantes posteriores si se devuelve ABSTAIN. Por lo tanto, puede escribir su propio votante personalizado (o reutilizar uno existente si esto funciona), hacer que se active antes que el votante del rol e otorgar incondicionalmente acceso a cualquier solicitud a los recursos a los que se refiere.

He hecho algo como esto en un proyecto actual, donde ciertos atributos transitorios específicos de la aplicación pueden permitir que alguien acceda a recursos que ordinariamente no podrían, y funciona bien como un enfoque.

Answer 2

Suponiendo que estamos usando Spring Security 3, la fuente de esa información (qué atributos/papeles están configurados para un camino particular) es el FilterInvocationSecurityMetadataSource que se inyecta en la FilterSecurityInterceptor. Por lo tanto, si tiene una URL particular, puede consultar los atributos configurados al pasar una FilterInvocation (creada a partir de la solicitud y la respuesta) al método getAttributes() de FilterInvocationSecurityMetadataSource.

Obtener una referencia a los beans internos creados por el espacio de nombres puede ser un poco complicado. Asumiendo que tiene su propio café en grano (o granos) que desea realizar la llamada, usted puede inyectar en ellos mediante la adición de un BeanPostProcessor a su contexto de aplicación, que se implementa algo como esto:

public class FilterSecurityMDSExtractor implements BeanPostProcessor, BeanFactoryAware { 
    private ConfigurableListableBeanFactory bf; 

    public Object postProcessBeforeInitialization(Object bean, String beanName) throws BeansException { 
     if (bean instanceof FilterInvocationSecurityMetadataSource) { 
      // Get your own bean from the BeanFactory here and inject the SecurityMetadataSource into it 
     } 
     return bean; 
    } 

    public Object postProcessAfterInitialization(Object bean, String beanName) throws BeansException { 
     return bean; 
    }  

    public void setBeanFactory(BeanFactory beanFactory) throws BeansException { 
     this.bf = (ConfigurableListableBeanFactory)beanFactory; 
    } 
} 

Tenga en cuenta que Spring Security registra automáticamente un WebInvocationPrivilegeEvaluator en el contexto que se puede utilizar para verificar si un usuario tiene la capacidad de invocar una URL particular sin invocarla realmente. Esto es similar, ya que consulta SecurityMetadataSource, pero no es lo que busca aquí.