Enterprise Java

How to secure Jersey REST services with Spring Security and Basic authentication

In my previous blog post, Quick way to check if the REST API is alive – GET details from Manifest file, I showed how to develop a REST resource to easy check if the developed REST API is reachable. In this post I will present how you can secure this resource with Spring Security and Basic authentication – “In the context of an HTTP transaction, basic access authentication is a method for an HTTP user agent to provide a user name and password when making a request.”

The secured REST resources introduced here are part of bigger project, presented extensively in the Tutorial – REST API design and implementation in Java with Jersey and Spring

Software used

  1. Jersey JAX-RS implementation 2.14
  2. Spring 4.1.4
  3. Spring security 3.2.5
  4. Maven 3.1.1
  5. JDK 7

Spring security configuration


To secure the REST services with basic authentication, the following Spring security libraries are necessary in the classpath. Because I am using Maven, they are listed as Maven dependencies in the pom.xml:

Spring security libraries

<!-- Spring security -->

Security-application context

Spring security configuration

<?xml version="1.0" encoding="UTF-8"?>
<beans:beans xmlns="http://www.springframework.org/schema/security"
	<!-- Stateless RESTful services use BASIC authentication -->
    <security:http create-session="stateless" pattern="/manifest/**">
        <security:intercept-url pattern="/**" access="ROLE_REST"/>

                <security:user name="rest" password="rest" authorities="ROLE_REST"/>


As you can see, a “rest” user and role is defined in memory. These are defined in the element <security:user-service> and its child element <security:user>. This makes sure that only users with ROLE_REST role are able to reach:

authenticaion manager with in memory setup

			<security:user name="rest" password="rest" authorities="ROLE_REST"/>

The next step is to secure the /manifest/* URLs, allowing access only to the newly defined rest user:

Securing URLs with role-based access

<security:http create-session="stateless" pattern="/manifest/**">
	<security:intercept-url pattern="/**" access="ROLE_REST"/>

Basic HTTP authentication is enabled in our application by the <security:http-basic/> line.


You cannot define the security constraints of Spring Security in the applicationContext.xml file, because they need to be loaded up with the Servlet listeneer and the filter chain. They need to be in a proper WebApplicationContext defined with a Servlet listener, not the Servlet-related one. This is because the DelegatingFilterProxy will look for the root application context defined in the ServletContext that is loaded by the ContextLoaderListener.  If you define only applicationContext.xml, because the filters load first, before the servlets, the fiilter won’t be able to find any application context, so it won’t be able to load up correctly.


Extend now the contextConfigLocation context parameter, to be aware of the the new spring security configuration file security-context.xml:

web.xml – context-param extension


Hook in Spring security only for URLs related to the manifest:

Hook into Spring security



<!--Hook into spring security-->


The Spring security filter chain needs to be activated.



If you access a secured location via the browser, a standard HTTP authentication popup appears asking for the authentication details:


Put in rest/rest and you should receive the JSON response.


It’s fairly easy to test a secured REST with Basic Authentication via soapUI. See the following video to find out more:



Request resource with Basic authentication

GET http://localhost:8888/demo-rest-jersey-spring/manifest HTTP/1.1
Accept-Encoding: gzip,deflate
Accept: application/json
Host: localhost:8888
Connection: Keep-Alive
User-Agent: Apache-HttpClient/4.1.1 (java 1.5)
Authorization: Basic cmVzdDpyZXN0

Note the Authorization header which is constructed as follows:

  1. Username and password are combined into a string “username:password”
  2. The resulting string is then encoded using the RFC2045-MIME variant of Base64, except not limited to 76 char/line
  3. The authorization method and a space i.e. “Basic ” is then put before the encoded string.


Response – manifest details

HTTP/1.1 200 OK
Date: Tue, 03 Feb 2015 15:47:32 GMT
Content-Type: application/json
Access-Control-Allow-Origin: *
Access-Control-Allow-Methods: GET, POST, DELETE, PUT
Access-Control-Allow-Headers: X-Requested-With, Content-Type, X-Codingpedia
Vary: Accept-Encoding
Content-Encoding: gzip
Content-Length: 196
Server: Jetty(9.2.6.v20141205)

{"Implementation-Title":"DemoRestWS","Implementation-Version":"0.0.1-SNAPSHOT","Implementation-Vendor-Id":"org.codingpedia","Built-By":"Matei1.Adrian","Build-Jdk":"1.7.0_40","Manifest-Version":"1.0","Created-By":"Apache Maven 3.1.1","Specification-Title":"DemoRestWS","Specification-Version":"0.0.1-SNAPSHOT"}


Well, that’s it. Spring Security is a very powerful framework with a gazzilion of configuration options. In this post I just shown one of them, namely how to secure REST resources with Basic Authentication. Of course in a more realistic scenario you would store the users and roles in an LDAP directory, or database…

Note:If you decide to use Basic Authentication to secure your REST resources, please make sure they are called over HTTPS. The preferred way nowadays to secure REST resources is with OAuth. More on that on a later post.

Adrian Matei

Adrian Matei (ama [AT] codingpedia DOT org) is the founder of Podcastpedia.org and Codingpedia.org, computer science engineer, husband, father, curious and passionate about science, computers, software, education, economics, social equity, philosophy.
Notify of

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Inline Feedbacks
View all comments
Back to top button