The Master Class of "Learn Spring Security" is out:


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.

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:


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

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:


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(
	at o.s.s.c.h.DefaultFilterChainValidator.validate(

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

The Master Class "Learn Spring Security" is out:


  • von

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

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

  • Kees de Kooter

    What would be the Java Config equivalent of this configuration?

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

      • Kees de Kooter

        Great. Thanks!

  • Mitu

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

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

      • Mitu

        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.

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

  • jimmy

    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?

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

      • jimmy

        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?

        • 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 acceptable.
          Third – you can have a look at ACL; that is quite a bit of complexity, but also definitely a lot of flexibility and – very likely – it will give you the dynamic behaviour you’re looking for.
          Hope that sets you on the right path with your implementation. Cheers,

          • jimmy

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