Roberto Trunfio Roberto Trunfio - 5 months ago 264
Java Question

Correct use of WebSecurity in WebSecurityConfigurerAdapter

In my Spring Boot application based on version 1.3.0.BUILD-SNAPSHOT, I have the static resources (images, css, js) in the

static
folder under
resources
.

I see some examples related to security configuration like the following:

@Configuration
@EnableWebSecurity
public class WebSecurityConfig extends WebSecurityConfigurerAdapter {

@Override
public void configure(final WebSecurity web) throws Exception {
web.ignoring()
.antMatchers("/static/**");
}
}


Is that example correct?
What should be the effect?
How to verify that it works (e.g. doing a request to
localhost:8080/something
?
What cool things can I do with
WebSecurity
?

Answer

Your example mean that Spring (Web) Security is ignoring Url-Pattern that match the Expression you have defined ("/static/**"). This Url is skipped by Security, therefore non-secured.

Allows adding RequestMatcher instances that should that Spring Security should ignore. Web Security provided by Spring Security (including the SecurityContext) will not be available on HttpServletRequest that match. Typically the requests that are registered should be that of only static resources. For requests that are dynamic, consider mapping the request to allow all users instead.

See: http://docs.spring.io/autorepo/docs/spring-security/4.0.0.RELEASE/apidocs/org/springframework/security/config/annotation/web/builders/WebSecurity.html

You can have as many Url-Pattern secured or unsecured. With Spring Security you have authentication and access-control features for the web layer of an application. You can also restict users who have a specified role to access a partitial Url and so on... Have a look here: http://docs.spring.io/spring-security/site/docs/current/reference/html/

Ordering Priority of Url Pattern

When matching the specified patterns against an incoming request, the matching is done in the order in which the elements are declared. So the most specific matches patterns should come first and the most general should come last.

There are multiple children to the http.authorizeRequests() method each matcher is considered in the order they were declared.

Patterns are always evaluated in the order they are defined. Thus it is important that more specific patterns are defined higher in the list than less specific patterns.

Have a look: http://docs.spring.io/spring-security/site/docs/current/reference/htmlsingle/#filter-security-interceptor

Example 1
Generell use of WebSecurity ignoring() Method omits Spring Security and none of Spring Security’s features will be available. WebSecurity is based above HttpSecurity. In Xml-Configuration you can write <http pattern="/resources/**" security="none"/>.

@Override
public void configure(WebSecurity web) throws Exception {
    web
        .ignoring()
        .antMatchers("/resources/**")
        .antMatchers("/publics/**");
}

@Override
protected void configure(HttpSecurity http) throws Exception {
    http
        .authorizeRequests()
        .antMatchers("/admin/**").hasRole("ADMIN")
        .antMatchers("/publics/**").hasRole("USER") // no effect
        .anyRequest().authenticated();
}

WebSecurity in the above example let Spring ignoring /resources/** and /publics/** . Therefore the .antMatchers("/publics/**").hasRole("USER") in HttpSecurity is unconsidered.

This will omit the request pattern from the security filter chain entirely. Note that anything matching this path will then have no authentication or authorization services applied and will be freely accessible.

Example 2
Patterns are always evaluated in order. The below matching is invalid because the first matches every request and will never apply the second match:

@Override
protected void configure(HttpSecurity http) throws Exception {
    http
        .authorizeRequests()
        .antMatchers("/**").hasRole("USER")
        .antMatchers("/admin/**").hasRole("ADMIN"):
}