I just announced the newSpring Security 5 modules (primarily focused on OAuth2) in the course:

>> CHECK OUT LEARN SPRING SECURITY

1. Overview

Spring Security provides several mechanisms to configure a request pattern as unsecured or allowing all access. Depending on each of these mechanisms – this can either mean not running the security filter chain on that path at all, or running the filter chain and allowing access.

Further reading:

Spring Security – Roles and Privileges

How to map Roles and Privileges for a Spring Security application: the setup, the authentication and the registration process.

Read more

Spring Security for a REST API

How to Secure a REST API with Spring Security - the XML Configuration, the web.xml, the HTTP status codes for authentication, etc.

Read more

2. access=”permitAll”

Setting up an <intercept-url> element with access=”permitAll” will configure the authorization so that all requests are allowed on that particular path:

<intercept-url pattern="/login*" access="permitAll" />

Or, via Java configuration:

http.authorizeRequests().antMatchers("/login*").permitAll();

This is achieved without disabling the security filters – these still run, so any Spring Security related functionality will still be available.

3. filters=”none”

This is a pre-Spring 3.1 feature that has been deprecated and replaced in Spring 3.1.

The filters attribute disables the Spring Security filters chain entirely on that particular request path:

<intercept-url pattern="/login*" filters="none" />

This may cause problems when the processing of the request will require some functionality of Spring Security.

Since this is a deprecated feature Spring versions newer than 3.0, using it with Spring 3.1 will result in a runtime exception on startup:

SEVERE: Context initialization failed
org.springframework.beans.factory.parsing.BeanDefinitionParsingException: 
Configuration problem: The use of "filters='none'" is no longer supported. 
Please define a separate <http> element for the pattern you want to exclude 
and use the attribute "security='none'".
Offending resource: class path resource [webSecurityConfig.xml]
	at o.s.b.f.p.FailFastProblemReporter.error(FailFastProblemReporter.java:68)

4. security=”none”

As we saw in the error message above, Spring 3.1 replaces filters=”none” with a new expression – security=”none”.

The scope has changed as well – this is no longer specified at the <intercept-url> element level. Instead, Spring 3.1 allows multiple <http> elements to be defined – each with its own security filter chain configuration. And so, the new security attribute now belongs on at the <http> element level.

In practice, this will look like:

<http pattern="/resources/**" security="none"/>

Or with Java configuration:

web.ignoring().antMatchers("/resources/**");

Instead of the old:

<intercept-url pattern="/resources/**" filters="none"/>

Similar to filters=”none”, this will also completely disable the Security filter chain for that request path – so when the request is handled in the application, Spring Security features will not be available.

This is not a problem for the examples above, which mainly deal with serving static resources – where no actual processing takes place. However, if the request is handled programmatically in some way – then security functionalities such as requires-channel, accessing the current user or calling secured methods will not be available.

For the same reason, there is no point specifying additional attributes on an <http> element that has already been configured with security=”none” because that request path is unsecured and the attributes will simply be ignored.

Alternatively, access=’IS_AUTHENTICATED_ANONYMOUSLY’ can be used to allow anonymous access.

5. Caveats for security=”none”

When using multiple <http> elements, some configured with security=”none”, keep in mind that the order in which these elements are defined is important. We want to have the specific <http> paths first, followed the universal pattern at the very end.

Also note that, if an <http> element doesn’t specify a pattern, then by default, that maps to the universal match pattern – “/**” – so again, this element needs to be last. If the order of the elements is not correct, the creation of the security filter chain will fail:

Caused by: java.lang.IllegalArgumentException: A universal match pattern ('/**') 
is defined  before other patterns in the filter chain, causing them to be ignored. 
Please check the ordering in your <security:http> namespace or FilterChainProxy bean configuration
	at o.s.s.c.h.DefaultFilterChainValidator.checkPathOrder(DefaultFilterChainValidator.java:49)
	at o.s.s.c.h.DefaultFilterChainValidator.validate(DefaultFilterChainValidator.java:39)

6. Conclusion

This article discusses the options of allowing access to a path with Spring Security – focusing on the differences between filters=”none”, security=”none” and access=”permitAll”.

I just announced the new Spring Security 5 modules (primarily focused on OAuth2) in the course:

>> CHECK OUT LEARN SPRING SECURITY

Sort by:   newest | oldest | most voted
von
Guest

How about using mvc:resource to set this as static link

Eugen Paraschiv
Guest

Hey Von – I covered static resources a few days ago actually – here. Cheers,
Eugen.

Kees de Kooter
Guest

What would be the Java Config equivalent of this configuration?

Eugen Paraschiv
Guest

Hey Kees – thanks for the suggestion – Java config added, hope it helps. Cheers,
Eugen.

Kees de Kooter
Guest

Great. Thanks!

Mitu
Guest

It would be nice if you could provide some xml config details.

Eugen Paraschiv
Guest

Hey Mitu – what kind of XML configs (besides the ones that are already there)?

Mitu
Guest

Please put the entire XML config file to download for easier understanding, and also mention the library version as the settings of different versions are quite different.

Eugen Paraschiv
Guest

The github project contains the full XML configuration (as well as a working project you can use to see it in action) – feel free to grab it from there.
When you’re saying that the configuration is different for different versions – what is the difference you’re thinking of? Cheers,
Eugen.

jimmy
Guest

i’m very exiting with spring security and this blog.
but i got big big problem..
Can spring security security change antMatchers on the fly?
thx

Eugen Paraschiv
Guest

Hey Jimmy – I’m glad you’re enjoying the site.
No, unfortunately not, at least not out of the box.
I’m sure, if you really need to – you can do it manually, but it’s going to be a very low level implementation, so I wouldn’t recommend doing it unless you have a really good understanding of the framework.
Hope that helps. Cheers,
Eugen.

jimmy
Guest

Thanks for fast response too Eugen.
The actual problem is that i need to change the user role (their permission to accessing specific urls) on the fly.
Do you have any suggestion?

Eugen Paraschiv
Guest
I see; that’s slightly different than, and there are a few ways you could go about it. First – depending on the exact semantics you’re looking for – you can have a look at a custom voter; that’s not exactly going to allow you to change the authorities of a principal after they’re already logged in, but it will give you some control during the authorization process – which may or may not be enough. Second – you can try to log them out; again, that’s not exactly dynamic but – depending on how often it happens, it may be… Read more »
jimmy
Guest

Ok, i will try ACL. Thanks a lot Eugen, Cheers.