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


Table of Contents

1. Overview

This tutorial shows how to Secure a REST Service using Spring and Spring Security 4 with Java based configuration. The article will focus on how to set up the Security Configuration specifically for the REST API using a Login and Cookie approach.

Further reading:

Spring Security Authentication Tutorial

How to build a production-grade Registration process for new users, and Login flow for existing users.

Read more

Granted Authority Versus Role in Spring Security

A quick guide to the difference between a granted authority and a role in Spring Security.

Read more

Spring Security Basic Authentication

Set up Basic Authentication in Spring - the XML Configuration, the Error Messages, and example of consuming the secured URLs with curl.

Read more

2. Spring Security in the web.xml

The architecture of Spring Security is based entirely on Servlet Filters and, as such, comes before Spring MVC in regards to the processing of HTTP requests. Keeping this in mind, to begin with, a filter needs to be declared in the web.xml of the application:


The filter must necessarily be named ‘springSecurityFilterChain’ to match the default bean created by Spring Security in the container.

Note that the defined filter is not the actual class implementing the security logic but a DelegatingFilterProxy with the purpose of delegating the Filter’s methods to an internal bean. This is done so that the target bean can still benefit from the Spring context lifecycle and flexibility.

The URL pattern used to configure the Filter is /* even though the entire web service is mapped to /api/* so that the security configuration has the option to secure other possible mappings as well if required.

3. The XML Security Configuration

<?xml version="1.0" encoding="UTF-8"?>

   <http entry-point-ref="restAuthenticationEntryPoint">
      <intercept-url pattern="/api/admin/**" access="ROLE_ADMIN"/>


      <logout />

   <beans:bean id="mySuccessHandler"
   <beans:bean id="myFailureHandler" class=

   <authentication-manager alias="authenticationManager">
            <user name="temporary" password="temporary" authorities="ROLE_ADMIN"/>
            <user name="user" password="user" authorities="ROLE_USER"/>


Most of the configuration is done using the security namespace – for this to be enabled, the schema locations must be defined and pointed to the correct 4.x XSD versions. The namespace is designed so that it expresses the common use cases of Spring Security while still providing hooks raw beans to accommodate more advanced scenarios.

>> Signup for my Course on Building a REST API with Spring 4

3.1. The <http> Element

The <http> element is the main container element for HTTP security configuration. In the current implementation, it only secured a single mapping: /api/admin/**. Note that the mapping is relative to the root context of the web application, not to the rest Servlet; this is because the entire security configuration lives in the root Spring context and not in the child context of the Servlet.

3.2. The Entry Point

In a standard web application, the authentication process may be automatically triggered when the client tries to access a secured resource without being authenticated – this is usually done by redirecting to a login page so that the user can enter credentials. However, for a REST Web Service, this behavior doesn’t make much sense – Authentication should only be done by a request to the correct URI and all other requests should simply fail with a 401 UNAUTHORIZED status code if the user is not authenticated.

Spring Security handles this automatic triggering of the authentication process with the concept of an Entry Point – this is a required part of the configuration, and can be injected via the entry-point-ref attribute of the <http> element. Keeping in mind that this functionality doesn’t make sense in the context of the REST Service, the new custom entry point is defined to simply return 401 whenever it is triggered:

@Component( "restAuthenticationEntryPoint" )
public class RestAuthenticationEntryPoint
  implements AuthenticationEntryPoint{

   public void commence(
     HttpServletRequest request,
     HttpServletResponse response, 
     AuthenticationException authException) throws IOException {
      response.sendError( HttpServletResponse.SC_UNAUTHORIZED, "Unauthorized" );

A quick side note here is that the 401 is sent without the WWW-Authenticate header, as required by the HTTP Spec – we can, of course, set the value manually if we need to.

3.3. The Login Form for REST

There are multiple ways to do Authentication for a REST API – one of the defaults Spring Security provides is Form Login – which uses an authentication processing filter – org.springframework.security.web.authentication.UsernamePasswordAuthenticationFilter.

The <form-login> element will create this filter and will also allow us to set our custom authentication success handler on it. This can also be done manually by using the <custom-filter> element to register a filter at the position FORM_LOGIN_FILTER – but the namespace support is flexible enough.

Note that for a standard web application, the auto-config attribute of the <http> element is shorthand syntax for some useful security configuration. While this may be appropriate for some very simple configurations, it doesn’t fit and should not be used for a REST API.

3.4. Authentication should Return 200 Instead of 301

By default, form login will answer a successful authentication request with a 301 MOVED PERMANENTLY status code; this makes sense in the context of an actual login form which needs to redirect after login. For a RESTful web service, however, the desired response for a successful authentication should be 200 OK.

This is done by injecting a custom authentication success handler in the form login filter, to replace the default one. The new handler implements the exact same login as the default org.springframework.security.web.authentication.SavedRequestAwareAuthenticationSuccessHandler with one notable difference – the redirect logic is removed:

public class MySavedRequestAwareAuthenticationSuccessHandler 
  extends SimpleUrlAuthenticationSuccessHandler {

    private RequestCache requestCache = new HttpSessionRequestCache();

    public void onAuthenticationSuccess(
      HttpServletRequest request,
      HttpServletResponse response, 
      Authentication authentication) 
      throws ServletException, IOException {
        SavedRequest savedRequest
          = requestCache.getRequest(request, response);

        if (savedRequest == null) {
        String targetUrlParam = getTargetUrlParameter();
        if (isAlwaysUseDefaultTargetUrl()
          || (targetUrlParam != null
          && StringUtils.hasText(request.getParameter(targetUrlParam)))) {
            requestCache.removeRequest(request, response);


    public void setRequestCache(RequestCache requestCache) {
        this.requestCache = requestCache;

3.5. Failed Authentication should return 401 instead of 302

Similarly – we configured the authentication failure handler – the same way we did with the success handler.

Luckily – in this case, we don’t need to actually define a new class for this handler – the standard implementation – SimpleUrlAuthenticationFailureHandler – does just fine.

The only difference is that – now that we’re defining this explicitly in our XML config – it’s not going to get a default defaultFailureUrl from Spring – and so it won’t redirect.

3.6. The Authentication Manager and Provider

The authentication process uses an in-memory provider to perform authentication – this is meant to simplify the configuration as a production implementation of these artifacts is outside the scope of this post.

3.7. Finally – Authentication against the running REST Service

Now let’s see how we can authenticate against the REST API – the URL for login is /login – and a simple curl command performing login would be:

curl -i -X POST -d username=user -d password=userPass

This request will return the Cookie which will then be used by any subsequent request against the REST Service.

We can use curl to authentication and store the cookie it receives in a file:

curl -i -X POST -d username=user -d password=userPass -c /opt/cookies.txt 

Then we can use the cookie from the file to do further authenticated requests:

curl -i --header "Accept:application/json" -X GET -b /opt/cookies.txt 

This authenticated request will correctly result in a 200 OK:

HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
Content-Type: application/json;charset=UTF-8
Transfer-Encoding: chunked
Date: Wed, 24 Jul 2013 20:31:13 GMT


4. The Java Security Configuration

Here’s how the Java configuration would look like:

public class SecurityJavaConfig extends WebSecurityConfigurerAdapter {

    private RestAuthenticationEntryPoint restAuthenticationEntryPoint;

    private MySavedRequestAwareAuthenticationSuccessHandler

    protected void configure(AuthenticationManagerBuilder auth)
      throws Exception {

    protected void configure(HttpSecurity http) throws Exception { 
        .failureHandler(new SimpleUrlAuthenticationFailureHandler())

    public MySavedRequestAwareAuthenticationSuccessHandler mySuccessHandler(){
        return new MySavedRequestAwareAuthenticationSuccessHandler();
    public SimpleUrlAuthenticationFailureHandler myFailureHandler(){
        return new SimpleUrlAuthenticationFailureHandler();

A quick note, the Spring Security 4 config has changed the old defaults for XML configuration to be the same as Java defaults.

Old XML Configuration defaults – before Spring Security 4:

  • loginProcessingUrl: /j_spring_security_check
  • usernameParameter: j_username
  • passwordParameter: j_password

Current XML Configuration defaults:

  • loginProcessingUrl: /login
  • usernameParameter: username
  • passwordParameter: password

5. Maven and Other Troubles

The Spring core dependencies necessary for a web application and for the REST Service have been discussed in detail. For security, we’ll need to add: spring-security-web and spring-security-config – all of these have also been covered in the Maven for Spring Security tutorial.

It’s worth paying close attention to the way Maven will resolve the older Spring dependencies – the resolution strategy will start causing problems once the security artifacts are added to the pom.

To address this problem, some of the core dependencies will need to be overridden in order to keep them at the right version.

6. Conclusion

This post covered the basic security configuration and implementation for a RESTful Service using Spring Security 4, discussing the web.xml, the security configuration, the HTTP status codes for the authentication process and the Maven resolution of the security artifacts.

And, as always, the full implementation is available over on Github.

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


newest oldest most voted
Notify of
Sigmund Lundgren
Sigmund Lundgren

Hmm successful auth still redirects for my, done in the spring base class. Had to comment this line in the successhandler:

//super.onAuthenticationSuccess(request, response, authentication);

René Fleischhauer
René Fleischhauer

Hi Sigmund, all,

I have the same problem…

super.onAuthenticationSuccess(request, response, authentication) calls SimpleUrlAuthenticationSuccessHandler#handle which contains the following line

redirectStrategy.sendRedirect(request, response, targetUrl);

Seems to be pretty non-sense to call the super method and therefore, I also removed it. Additionally I added a response.setStatus(200) for safety purposes…




Am having a problem in understanding one thing, how the actual login will be done. I added the configuration and when trying to access a rest method/url I get 401 error, but am unable to figure out how and where to login. can help me pleas?

Eugen Paraschiv

Because it’s REST, there is should be no state on the server side. What that means is that the concept of login doesn’t fit the RESTful architecture – each request will contain the credentials for it to be authenticated. So, just add the correct Authentication headers and you’ll be OK. Also, if you’re looking at the github project, there is extensive testing that does that – you can take a look at that.


Thank you for the response, but am using FF plugin and I added the Authorization header to the url, the only place fired in my code is the EntryPoint and it never enters my AuthenticationProvider. which makes wounder if am doing something wrong!


Eugen Paraschiv

Not sure how you can add the header to the URL – do you mean you added the header to the request? Also, to follow some working examples, you can always clone the project from github and run the tests.


If you are using the REST service through AJAX from a browser can you had the necessary Authentication headers? For example, if you are using form based authentication to your website and want to retrieve data from your REST service. I guess I must just be missing something here.

Eugen Paraschiv

You can take a look at: http://code.google.com/p/crypto-js/

Branislav Vidovic
Branislav Vidovic

This is the most interesting part in my opinion…. I am interested which other additional component of spring security you have extended to read request headers and build a required authentication object. Besides i had a look into your git project but in there you did not do it totally like in this post..

Eugen Paraschiv

The article is now updated with the exact process of how to perform the login and how to use the cookie in further requests.


Thank you for a good article about this, just what I needed!

René Fleischhauer
René Fleischhauer

Hi all, thanks for the tutorial. Great stuff! I have a minor question: I added within the element in order to customize the login url. After starting the application again the following exception occurs: org.springframework.beans.factory.parsing.BeanDefinitionParsingException: Configuration problem: Filter beans ” and ” have the same ‘order’ value. When using custom filters, please make sure the positions do not conflict with default filters. Alternatively you can disable the default filters by removing the corresponding child elements from and avoiding the use of . The problem is clear, however I’m not sure how I can avoid the use of j_spring_security_check. I’d highly… Read more »

Eugen Paraschiv

Hi – yes, using the element is a good alternative as it does keep the configuration simple – please check out the updated configuration section and the new github project for a working implementation. Thanks.


Great article, however every time I get 401 Unauthorized, regardless sending or not valid username and password (temporary/temporary) in username or j_username and password or j_password. Tried to figure it out looking at your git project, but there seems to be a lot of other stuff, and the only authentication used in this project is Digest authentication. Did I miss something important here?

Eugen Paraschiv

Hi – I updated the article to better explain how to perform login and how to interact with the service; I also added a specific github project to only cover this article – should be simpler to understand. Thanks.