Filter installed ahead of spring security filters

[ageery]

In EmbeddedWebApplicationContext.getServletContextInitializerBeans(), beans are ordered within their type but not across types, even if the underlying types are the same. This causes a problem if FilterRegistrationBean is used to define a filter (e.g., a Wicket filter). Because FilterRegistrationBean implements ServletContextInitializer, its filter is added to the list of initializers before the spring security filters, which are added as regular filters. When the application launches, the spring security filters are added after the other filters.

[dsyer]

I guess you need to add a FilterRegistrationBean for the security filter and order it after your own filter? Not everyone would want their filter after the security filter, so it doesn't necessarily make sense to fix it to anything in particular.

[ageery]

I'm using the @EnableWebSecurity annotation -- I would expect that to install the spring security filters before any other filters.

The workaround is not use a FilterRegistrationBean, but instead just a Filter. Instead of this:

@Bean public FilterRegistrationBean getFilter()

Use this:

@Bean public Filter getFilter()

That will give you the correct ordering because the filters are all processed together.

[dsyer]

If you use @Bean Filter the ordering with other Filters is not defined (they all have default @Order), so I suspect that might not be the best workaround, but if it works, then great.

Note that @EnableWebSecurity is not a Spring Boot feature, and when you use it you switch off the Boot security configuration (which may well be what you want). The net effect either way (whether you use that annotation directly or via autoconfiguration) is that a Filter called "springSecurityFilterChain" is created. If you wanted to give it an explicit order you would have to add a FilterRegistrationBean and inject that filter (by name).

[ceefour]

I also got this problem. Static resources are Spring Security-ized just fine, but Wicket pages are not Spring Security-secured at all. Even saving SecurityContextHolder.getContext() to the HttpSession doesn't help, as there's no filter to retrieve the (existing) SecurityContext from the HttpSession on the next request.

[ceefour]

Maybe an additional annotation such as @RequiresSecurity that can be added to the FilterRegistrationBean ?

BTW I've tried setOrder() but not working:

@Inject
protected Environment env;

@Bean
public FilterRegistrationBean wicketFilter() {
    final FilterRegistrationBean reg = new FilterRegistrationBean(new WicketFilter());
    reg.addInitParameter(WicketFilter.FILTER_MAPPING_PARAM, "/*");
    reg.addInitParameter(WicketFilter.APP_FACT_PARAM, SpringWebApplicationFactory.class.getName());
    reg.addInitParameter("applicationBean", "webApp");
    reg.addInitParameter("configuration", env.getRequiredProperty("wicketConfiguration"));
    //        reg.addInitParameter("applicationClassName", MyWebApplication.class.name);
    reg.setOrder(Integer.MAX_VALUE); // try make sure it is after Spring Security filter, but doesn't work :(
    return reg;
}

I still get this:

2015-06-20 14:29:12.478  INFO 12561 --- [           main] o.s.b.c.embedded.FilterRegistrationBean  : Mapping filter: 'metricFilter' to: [/*]
2015-06-20 14:29:12.484  INFO 12561 --- [           main] o.s.b.c.embedded.FilterRegistrationBean  : Mapping filter: 'characterEncodingFilter' to: [/*]
2015-06-20 14:29:12.485  INFO 12561 --- [           main] o.s.b.c.embedded.FilterRegistrationBean  : Mapping filter: 'webRequestLoggingFilter' to: [/*]
2015-06-20 14:29:12.486  INFO 12561 --- [           main] o.s.b.c.embedded.FilterRegistrationBean  : Mapping filter: 'wicketFilter' to: [/*]
2015-06-20 14:29:12.486  INFO 12561 --- [           main] o.s.b.c.embedded.FilterRegistrationBean  : Mapping filter: 'simpleCorsFilter' to: [/*]
2015-06-20 14:29:12.487  INFO 12561 --- [           main] o.s.b.c.embedded.FilterRegistrationBean  : Mapping filter: 'springSecurityFilterChain' to: [/*]
2015-06-20 14:29:12.488  INFO 12561 --- [           main] o.s.b.c.embedded.FilterRegistrationBean  : Mapping filter: 'applicationContextIdFilter' to: [/*]

[ceefour]

Info: springSecurityFilterChain bean is defined by org.springframework.security.config.annotation.web.configuration.WebSecurityConfiguration,
but it's also created by org/springframework/boot/autoconfigure/security/SpringBootWebSecurityConfiguration.java.

I'm a bit confused.

See:

• Make it easier to order a filter after Spring Security's filter #1640
• 0cdb1d3

Update: I think what happens is I've turned of Boot's springSecurityFilterChain bean, which means the one creating it is Spring Security's WebSecurityConfiguration, which doesn't set an order, defaulting to LOWEST_PRECEDENCE (i.e. Integer.MAX_VALUE)

This workaround (http://stackoverflow.com/a/26147788/122441) worked for me:

@Configuration @Profile("daemon")
public class WicketConfig {

    @Inject
    protected Environment env;

    @Bean
    public FilterRegistrationBean securityFilterChain(@Named(AbstractSecurityWebApplicationInitializer.DEFAULT_FILTER_NAME) Filter securityFilter) {
        FilterRegistrationBean registration = new FilterRegistrationBean(securityFilter);
        registration.setOrder(0);
        registration.setName(AbstractSecurityWebApplicationInitializer.DEFAULT_FILTER_NAME);
        return registration;
    }

    @Bean
    public FilterRegistrationBean wicketFilter() {
        final FilterRegistrationBean reg = new FilterRegistrationBean(new WicketFilter());
        reg.addInitParameter(WicketFilter.FILTER_MAPPING_PARAM, "/*");
        reg.addInitParameter(WicketFilter.APP_FACT_PARAM, SpringWebApplicationFactory.class.getName());
        reg.addInitParameter("applicationBean", "webApp");
        reg.addInitParameter("configuration", env.getRequiredProperty("wicketConfiguration"));
        //        reg.addInitParameter("applicationClassName", MyWebApplication.class.name);
        reg.setOrder(Integer.MAX_VALUE); // make sure it is after Spring Security filter
        return reg;
    }
}

[dsyer]

That's not a workaround. That's just the way you have to register the filters if you want a custom order. Maybe you should avoid using @EnableWebSecurity if you don't want to have to do that?

[ceefour]

So to use Spring Boot, I must disable @EnableWebSecurity when using my own WebSecurityConfigurer? (so I can use my own AuthenticationManager)

[dsyer]

I'm not sure what you mean by "disable". You either use it (and accept the defaults provided by Spring Boot), or you don't (and provide your own configuration).

[ceefour]

What I mean is that I'd like to use Spring Boot's security configuration (which sets springSecurityFilterChain order to 0 instead of Spring Security's default of LOWEST_PRECEDENCE) except for AuthenticationManager which I will provide myself.

In my understanding from what you said before:

Maybe you should avoid using @EnableWebSecurity if you don't want to have to do that?

@EnableWebSecurity is only used by Spring Security, not Spring Boot, is that right ? So I should remove @EnableWebSecurity from my WebSecurityConfigurer ?

[dsyer]

So I should remove @EnableWebSecurity from my WebSecurityConfigurer ?

Like I said, it's up to you. That's what I would do (allow Boot to do as much as it wants).

[nickspacek]

I'm a little late to the party, but I wanted to voice some support for the issue that @ceefour raised, and that in fact a fix seems to be on the plate for Spring Boot 1.3.0: #3703