Spring Security Configuration - Httpsecurity VS Websecurity

Spring Security Configuration - HttpSecurity vs WebSecurity

General use of WebSecurity ignoring() method omits Spring Security and none of Spring Security’s features will be available.
WebSecurity is based above HttpSecurity.

@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 lets Spring ignore /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.

configure(HttpSecurity) allows configuration of web-based security at a resource level, based on a selection match - e.g. The example below restricts the URLs that start with /admin/ to users that have ADMIN role, and declares that any other URLs need to be successfully authenticated.

configure(WebSecurity) is used for configuration settings that impact global security (ignore resources, set debug mode, reject requests by implementing a custom firewall definition). For example, the following method would cause any request that starts with /resources/ to be ignored for authentication purposes.

---

Let's consider the below code, we can ignore the authentication for the endpoint provided within antMatchers using both the methods.

@Override
public void configure(WebSecurity web) throws Exception {
    web
        .ignoring()
        .antMatchers("/login", "/register", "/api/public/**");
}

@Override
public void configure(HttpSecurity http) throws Exception {

    http
        .csrf().disable()
        .authorizeRequests()
        .antMatchers("/login", "/register", "/api/public/**").permitAll()
        .anyRequest().authenticated();
}

• configure(WebSecurity web)
  Endpoint used in this method ignores the spring security filters, security features (secure headers, csrf protection etc) are also ignored and no security context will be set and can not protect endpoints for Cross-Site Scripting, XSS attacks, content-sniffing.

• configure(HttpSecurity http)
  Endpoint used in this method ignores the authentication for endpoints used in antMatchers and other security features will be in effect such as secure headers, CSRF protection, etc.

Difference between Web ignoring and Http permitting in Spring Security?

I suggest you skim over this article: Spring Security Java Config Preview: Web Security The differences between the two approaches from your codes are:

• HttpSecurity allows configuring web-based security for HTTP requests. At this level, you declare the authentication rules.
• WebSecurity allows configuring things that have a global impact o all of the web security, such as setting the debug mode or enabling further firewall configuration using an implementation of the HttpFirewall or simply ignoring resources as your code shows.

You might be interested in the 3rd configure method of WebSecurityConfigurerAdapter which uses:

• AuthenticationManagerBuilder that enables and assures the authentication mechanism such as LDAP based authentication or the JDBC based one.

Correct use of WebSecurity in WebSecurityConfigurerAdapter

Your example means that Spring (Web) Security is ignoring URL patterns that match the expression you have defined ("/static/**"). This URL is skipped by Spring Security, therefore not 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 WebSecurity API documentation for more info.

You can have as many URL patterns secured or unsecured as you want.

With Spring Security you have authentication and access control features for the web layer of an application. You can also restrict users who have a specified role to access a particular URL and so on.

Read the Spring Security reference for more details:

http://docs.spring.io/spring-security/site/docs/current/reference/html/

Ordering Priority of URL Patterns

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.

Read here for more details:

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

Example 1

General use of WebSecurity ignoring() method omits Spring Security and none of Spring Security’s features will be available.
WebSecurity is based above HttpSecurity

(in an XML configuration you can write this: <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 lets Spring ignore /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"):
}

HttpSecurity permitAll and WebSecurity ignoring functions for un-Auth URL's?

As @M. Deinum pointed out, I am concluding the answer and I have updated the documentation for the same in PR.

configure(WebSecurity web)

Endpoint used in this method ignores the spring security filters,
headers, CSRF etc. see HeadersConfigurer, CsrfConfigurer. Instead, if
you want to protect public endpoints against common vulnerabilities,
then see configure(HttpSecurity) and
HttpSecurity#authorizeRequests configuration method.

configure(HttpSecurity http)

Public endpoints that require defense against common vulnerabilities
can be specified here. see HttpSecurity#authorizeRequests and the
permitAll() authorization rule for more details.

Method configure(WebSecurity web) in Spring Security doesn't work

From your source code, which is not complete in the question, i might suggest that Spring Boot is putting JwtAuthenticationTokenFilter class automatically into the filter chain. So, although was correct to exclude /auth/ in the ignoring() method in security config, that wasn't enough to stop the filter from happening in the context of Spring Boot itself. The solution is to remove the annotation @Bean from jwtAuthenticationTokenFilter() method or to follow the other way explained in Spring Security filter chain not ignoring specified path

---

Related Topics