Как определить, какие роли необходимы для доступа к URL-адресу в Spring Security?

Question

Я использую Spring Security для защиты веб-приложения. URL-адреса защищены следующим образом:

<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>

У меня есть фильтр, который должен перенаправить пользователя на специальную страницу при определенных обстоятельствах. Однако для этой страницы требуются изображения и файлы CSS в каталоге ресурсов, которые, к сожалению, также будут перенаправлены на эту специальную страницу. Я не хочу, чтобы фильтр проверял вручную каждый шаблон URL, потому что моя фактическая конфигурация URL намного длиннее, и я также хочу разрешить другие страницы.

Можно ли из фильтра для данной страницы определить, какие роли требуются? Я мог бы затем не перенаправлять, если ROLE_ANONYMOUS не требуется.

Answer 1

Предполагается, что вы используете Spring Security 3, источником этой информации (какие атрибуты / роли настроены для определенного пути) является FilterInvocationSecurityMetadataSource, который вводится в FilterSecurityInterceptor. Поэтому, если у вас есть конкретный URL, вы можете запросить настроенные атрибуты, передав FilterInvocation (созданный из запроса и ответа) методу getAttributes () FilterInvocationSecurityMetadataSource.

Получить ссылку на внутренние компоненты, созданные пространством имен, может быть немного сложно. Предполагая, что у вас есть свой собственный компонент (или компоненты), из которого вы хотите сделать вызов, вы можете внедрить его в них, добавив BeanPostProcessor в контекст вашего приложения, который реализован примерно так:

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;
    }   
}

Обратите внимание, что Spring Security автоматически регистрирует WebInvocationPrivilegeEvaluator в контексте, который можно использовать для проверки того, имеет ли пользователь возможность вызывать определенный URL-адрес без его фактического вызова. Это похоже на то, что он запрашивает SecurityMetadataSource, но не совсем то, что вам нужно.

Answer 2

Не забывайте, что на самом деле при принятии решения о том, разрешить ли доступ, происходит то, что URL и существующая аутентификация передаются через серию AccessDecisionVoter с, одним из значений по умолчанию которого является RoleVoter . Этот избиратель проверяет конфигурацию запрошенного ресурса и, если требуется определенная роль, отклонит запрос, если существующая аутентификация не имеет этой роли.

Таким образом, к решению - вы можете добавить других избирателей, которые вступают в должность до роли избирателя. Каждый избиратель должен вернуть GRANT, DENY или ABSTAIN, и обработка будет продолжена только для более поздних избирателей, если ABSTAIN будет возвращен. Таким образом, вы можете написать своего собственного избирателя (или повторно использовать существующего, если это будет работать), запустить его до роли избирателя и безоговорочно разрешить доступ к любым запросам к ресурсам, на которые вы ссылаетесь.

Я сделал что-то подобное в текущем проекте, где определенные временные атрибуты, специфичные для приложения, могут позволить кому-то получить доступ к ресурсам, которые они обычно не могут, и это хорошо работает как подход.