Spring Security: the Basics

Posted Feb 25, 2010 // 0 comments
Jed:

I recently implemented Spring Security on a large J2EE application. Our customer had some new requirements that the existing hodge-podge of container security and custom code could not handle. While what we ended up with turned out to be fairly complex, I built it up one step at a time from fairly simple components. Later posts will deal with that, for now, we’ll start by implementing Spring Security in the simplest way possible.

We are using Spring Security 2.0.x.

The first step is to download Spring Security

The next step is to read the manual for an overview.

You’ll need to make sure you have the Spring Security JARs in the classpath. I decided to put them in the server classpath because there are a lot of them and there is no need to reload them on each deploy, but this is an implementation choice. There is an implicit/undocumented dependency on Spring; you will need to download Spring and add some of its JARs to the classpath as well. This is a minimal list of JARs required to run Spring Security 2.0.4:

  • aopalliance.jar
  • commons-codec-1.3.jar
  • spring-aop.jar
  • spring-beans.jar
  • spring-context.jar
  • spring-core.jar
  • spring-security-acl-2.0.4.jar
  • spring-security-core-2.0.4.jar
  • spring-security-core-tiger-2.0.4.jar
  • spring-security-taglibs-2.0.4.jar
  • spring-tx.jar
  • spring-web.jar


To enable Spring Security for your web application, add the following elements to web.xml:
<filter>
  <filter-name>springSecurityFilterChain</filter-name>
  <filter-class>org.springframework.web.filter.DelegatingFilterProxy</filter-class>
</filter>
<filter-mapping>
  <filter-name>springSecurityFilterChain</filter-name>
    <url-pattern>/*</url-pattern>
  </filter-mapping>
<filter>
<listener>
  <listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
</listener>
<listener>
  <listener-class>org.springframework.security.ui.session.HttpSessionEventPublisher</listener-class>
</listener>

Spring Security’s configuration is done via an XML configuration file, which by default is named applicationContext-security.xml and is expected to be in the web application’s WEB-INF directory. You can change these by adding an additional element to web.xml telling Spring where to find it. I wanted mine to be picked up from /WEB-INF/classes instead:
<context-param>
  <param-name>contextConfigLocation</param-name>
  <param-value>
    /WEB-INF/classes/applicationContext-security.xml
  </param-value>
</context-param>

Here’s a basic Spring Security configuration:
<?xml version="1.0" encoding="UTF-8"?>

<beans:beans xmlns="http://www.springframework.org/schema/security"
             xmlns:beans="http://www.springframework.org/schema/beans"
             xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
             xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.0.xsd
                 http://www.springframework.org/schema/security http://www.springframework.org/schema/security/spring-security-2.0.1.xsd">

  <http auto-config="true">
    <intercept-url pattern="/login*.jsp*" filters="none"/>
    <intercept-url pattern="/images/**" filters="none"/>
    <intercept-url pattern="/includes/**" filters="none"/>
    <intercept-url pattern="/**" access="ROLE_USER"/>
    <form-login login-page="/login.jsp" always-use-default-target="true"/>
  </http>

  <authentication-provider>
    <user-service>
      <user name="admin" password="admin" authorities="ROLE_USER"/>
    </user-service>
  </authentication-provider>
</beans:beans>

We use the Spring Security namespace configuration to require authentication for all URLs that are not login or image/CSS/javascript requests. There is one role, ROLE_USER, that one must have to access the bulk of the application. The form-login element specifies a default page where all users will land upon successful login regardless of the original request; leave off the always-use-default-target attribute to allow a user to continue to the original destination. Our authentication provider is a stub that allows a single user to access the site.

This is fine for testing to ensure you have the basic components working, but is not particularly useful otherwise. Read on to see how to turn this into something more realistic.

About Jed

Jed Prentice is a senior software engineer with 15 years of experience developing business applications in a variety of industries. He is an expert in the field of object-oriented software development specializing in distributed systems and ...

more >

Read Jed's Blog

Comments

Post new comment

The content of this field is kept private and will not be shown publicly.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.
  • Allowed HTML tags: <a> <strong> <code> <p> <img> <ul> <ol> <li> <h2> <h3> <h4> <b> <u> <i>
  • You may insert videos with [video:URL]

More information about formatting options

CAPTCHA
This question is for testing whether you are a human visitor and to prevent automated spam submissions.