It’s Only Software

Interestingly, a month or so after I posted my 5 Minute Guide to Spring Security 2, a commonly asked question was asked on the Spring forums. I figured I’d address it here, because (once again in Spring/Acegi Security integration) the answer wasn’t really obvious.

Essentially, the question goes something like this:

The examples I can find using Spring Security show this “login.jsp” page. How can I pull Spring content into this page?

Typically, you might want to display data on the login page that’s provided by Spring service-layer beans, or tie into the i18n bundles you’ve configured, or tens of other possibilities.

Fortunately, this is possible with a few tweaks to your Spring configuration. In this post, I’ll assume you’ve started with the configuration I wrote up in the initial 5 Minute Guide to Spring Security.

First, as with any Spring action, you will need a controller to handle the Login page display (the form POST is handled by the Spring Security interceptor). A simple annotated controller might look like this:

/**
 * Simple mapping for login page.
 * 
 * @author Mularien
 */
@Controller
public class LoginController {
	private static Logger logger = Logger.getLogger(LoginController.class);
 
	@Autowired
	// stuff required to display header, footer, etc.
 
	@RequestMapping("/login.do")
	public void login() {
 
	}
 
	@RequestMapping("/accessDenied.do")
	public ModelAndView accessDenied() {
		return new ModelAndView("redirect:/index.do");
	}
}

Now, you can see where we’re going with this. We’ll need a corresponding “login.jsp” page in our views directory, so that the “login.do” mapping works. You’ll need to tweak your Spring Security configuration:

    <http auto-config="true" access-denied-page="/accessDenied.do">
        <intercept-url pattern="/login.do*" filters="none"/>  
        <intercept-url pattern="/app/*.do" access="ROLE_USER,ROLE_ADMIN"  />
        <intercept-url pattern="/admin/**/*.do" access="ROLE_ADMIN"  />
    	<form-login login-page="/login.do" authentication-failure-url="/login.do?login_error=1"
    	   default-target-url="/app/index.do"/>
    	<logout logout-success-url="/login.do"/>
    </http>

Note the references to “login.do” and “accessDenied.do” here – these are the mappings we set up in our login controller. Pay attention to the access rules we’ve assigned – the URL intercept for “/login.do*” has no authorization checks applied to it, this is important otherwise users won’t be able to access the login page!

Hope this helps someone! As always, your comments are appreciated.

This post is to expand on some of the thoughts I posted on the SpringSource Blog in response to Rod Johnson’s excellent description of the SpringSource business model and its commitment to development of open source software.

Now that SpringSource has shown an ability to crank out new product releases on a seemingly weekly basis, I wanted to reflect on where Spring is positioned in the Java open source community, and how open the Spring Core project is to work done by the public.

The hypothesis of my experiment occurred to me when I happened to be reviewing Spring JIRA assignments one day. I was curious whether, following the bug assignments, the majority of development on the “Spring Core” projects (including Spring MVC and what we would consider “classic Spring”) is performed solely by SpringSource employees.

I decided to go about verifying this and would like to present my findings. Note that this is a purely objective study of a particular widely used open source project, and shouldn’t be construed as an opinion on the findings.

Edit Sept 22, 2008 Please note that although the publishing of this post by freakish timing occurred less than 24 hours after the announcement by SpringSource, I want to be clear that this article was drafted and published before I was aware of this news. As such, please don’t misread this investigation as a “response” to the announcement.

Since SpringSource is obviously a private company, I determined the list of employees by consulting publicly available information sources. Anyone is welcome to refute the claims in this article.

I have no direct working relationship with anyone at SpringSource; however, to verify the facts cited in my study, I did email an advance copy of the article to Juergen Hoeller, Spring Project Lead. Juergen kindly took the time to review it and clarify a couple facts that I wasn’t able to discern through public information. Juergen has always been friendly and considerate in the dealings we’ve had through Spring JIRA or the Spring forums, and I appreciate the help!

Read on for the analysis…
Continue reading “How Open Source is Spring?: An Analytical Investigation”

Since I spend a lot of time working with Spring, one of the many blogs in my daily read list is the SpringSource Team Blog, both articles and comments. I have gotten really tired, however, of the constant SEO spammers hitting the SpringSource blog.

It’s unfortunate that with SpringSource’s multi-million dollar funding rounds ($15M raised this summer, and $10M previously raised), they can’t find the resources to upgrade their very dated WordPress install with one that is more spam resistant, nor has anyone from the company even responded publicly to the many calls for fixing this issue.

Although I’ve used Acegi Security in the past, I hadn’t tried it since it was renamed Spring Security and folded into the Spring Portfolio. I decided to approach its integration into a typical Spring web application with the eyes of a new user and write up my notes as a 5 minute guide to Spring Security.

Pretending to be a new user, I found the suggested steps a bit bewildering. Let’s take these one at a time, and I’ll try to help you out where the instructions are unclear:

1. First of all, deploy the “Tutorial Sample”, which is included in the main distribution ZIP file.

Aside from the weird packaging of Spring Security, it’s not clear which file this is. You should be deploying spring-security-samples-tutorial-2.0.x.war to your servlet container in the usual fashion. In the case of Tomcat, for example, use the deployment tool or drop this into your webapps directory. You should see the tutorial application in your browser. Let’s move to step 2…

2. Next, follow the Petclinic Tutorial , which covers how to add Spring Security to the commonly-used Petclinic sample application that ships with Spring.

This is pretty straightforward. The only error I found was that there is a reference to %spring-sec-tutorial%\WEB-INF\applicationContext-security-ns.xml. This should be applicationContext-security.xml instead. Note that I didn’t actually try this part of the tutorial with the Petclinic application, since I had my own test app I wanted to integrate with.

And here’s where the fun starts. Once you get past the convention over configuration convenience, you will need to customize Spring Security. One of the first things I looked for in the documentation was what all the bits in the XML namespace did. When this product was Acegi security, you could be pretty sure of looking at the Javadoc and getting documentation. Not so with XML configuration! While the Spring Framework documentation includes an excellent appendix with a reasonable level of detail on each of the namespaced XML declarations, Spring Security has nothing like this.

With convention over configuration, good documentation of the defaults becomes especially important, and it’s unfortunate the documentation isn’t really adequate in this area.

That said, I’ll try to cover a basic scenario here where we integrate Spring Security, using database-backed authentication, into an existing Spring web application. Here’s what I wanted for my example:

• Database-backed authentication
• Users have a single “role” – either plain user, or admin
• Customized login page

It’s a bit hard to cover this in 5 minutes, so I have skipped some of the stuff I hope you know already, such as use of Spring XML namespaces, and configuring simple JDBC DataSources. Please let me know if you miss this stuff!

Getting Started

I would suggest getting started with the applicationContext-security.xml that is found in the tutorial sample, and trimming it down a bit. Here’s what I got when I trimmed it down:

<?xml version="1.0" encoding="UTF-8"?>
 
<!--
  - Sample namespace-based configuration
  -
  - $Id: applicationContext-security.xml 3019 2008-05-01 17:51:48Z luke_t $
  -->
 
<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">
 
	<global-method-security secured-annotations="enabled">
	</global-method-security>
 
    <http auto-config="true">
        <intercept-url pattern="/**" access="IS_AUTHENTICATED_ANONYMOUSLY" />
    </http>
 
    <!--
    Usernames/Passwords are
        rod/koala
        dianne/emu
        scott/wombat
        peter/opal
    -->
    <authentication-provider>
        <password-encoder hash="md5"/>
        <user-service>
            <user name="rod" password="a564de63c2d0da68cf47586ee05984d7" authorities="ROLE_SUPERVISOR, ROLE_USER, ROLE_TELLER" />
            <user name="dianne" password="65d15fe9156f9c4bbffd98085992a44e" authorities="ROLE_USER,ROLE_TELLER" />
            <user name="scott" password="2b58af6dddbd072ed27ffc86725d7d3a" authorities="ROLE_USER" />
            <user name="peter" password="22b5c9accc6e1ba628cedc63a72d57f8" authorities="ROLE_USER" />
	    </user-service>
	</authentication-provider>
</beans:beans>

This makes a good baseline for the modifications we’re going to make. But first…

Mapping XML Elements to Java Code

I found it very helpful at this point, before messing with the XML, to know where the Java code was that corresponded to the available XML elements. The basic class that Spring Security uses for mapping XML elements to beans is SecurityNamespaceHandler. The code in this class simply delegates XML elements to bean definition parsers. It’s easy to follow along and map XML elements to Java code in this way. Unfortunately, don’t expect extensive commenting in the Java code to help you

web.xml Changes

I agree with the Spring Security documentation and found it easier to extract the security-related stuff into its own XML configuration file. This allows you to play XML tricks and not require namespace-tagging for the security elements. First off, you have to include a reference to applicationContext-security.xml in your [Spring] initialization parameters in your web.xml file:

	<context-param>
		<param-name>contextConfigLocation</param-name>
		<param-value>
			/WEB-INF/spring-app-servlet.xml
			/WEB-INF/applicationContext-security.xml
		</param-value>
	</context-param>

Next, as instructed by the Spring Security getting started guide, you need to add the filter mapping. In my case, this went right after the <context-param> end tag, since I didn’t have any other filters:

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

This default mapping will run all requests to your application through Spring Security. Now we’re done with web.xml, and we move on to…

Database-Backed Authentication

In my case, my application was already configured to use a JDBC DataSource, so pointing Spring Security at my JDBC data source was as easy as modifying the authentication-provider element to reference my already configured Spring bean:

    <authentication-provider>
	    <jdbc-user-service data-source-ref="dataSource"/>
    </authentication-provider>

Now, the immediate question I asked is – OK, what does the convention over configuration assume my database tables look like? If you look at the documentation of the JDBC authentication provider, you would expect to see that information there, but you’d be wrong.

Instead, you have to look at the SQL queries that are hard-coded in the JdbcDaoImpl class and infer the schema structure for yourself. This article has a graphical depiction of the basic schema down in section 5.4.

If you want to configure the queries that are used, simply match the available attributes on the jdbc-user-service element to the SQL queries in the Java class I referenced above. In my example, I wanted to simplify my schema by adding the user’s role directly to the user table. So I modified the XML configuration slightly as follows:

  <jdbc-user-service data-source-ref="dataSource" 
    authorities-by-username-query="select username,authority from users where username=?"/>

This allowed me to put values in the ‘authority’ column like ‘ROLE_ADMIN’ or ‘ROLE_USER’, which translate directly into Spring Security roles!

Configuring URL authorization

Mapping URLs to roles is really easy. In your http element, simply put successive elements like this:

        <intercept-url pattern="/admin/*.do" access="ROLE_ADMIN"  />
        <intercept-url pattern="/**.do" access="ROLE_USER,ROLE_ADMIN"  />

Note here that the ‘access’ attribute values directly correspond to the values returned by the second column of the authorities-by-username-query. The ‘.do’ mapping is what I arbitrarily chose for my application – you may have to adjust depending on what your application’s Spring-managed URLs look like.

Configuring and Branding Spring Security-managed Pages

Finally, I wanted to figure out where the pages related to Spring Security should be configured, so that I could modify them if I needed to. Somewhat oddly, Spring Security ships with a default login page whose HTML markup is located in a class file – DefaultLoginPageGeneratingFilter. We would (obviously) like to replace this with our own custom page. Since we are authenticating everything passing through the Spring servlet, we must use a JSP for this.

Add the following to the http tag in the security configuration file:

<form-login login-page="/login.jsp" />

Now you need to put the login.jsp page in your web application (generally in the WEB-INF directory). The basic structure of the page you’re creating will look like this:

<%@ page import="org.springframework.security.ui.webapp.AuthenticationProcessingFilter" %>
<%@ page import="org.springframework.security.ui.AbstractProcessingFilter" %>
<%@ page import="org.springframework.security.AuthenticationException" %>
 
...
<form action="j_spring_security_check">
	<label for="j_username">Username</label>
	<input type="text" name="j_username" id="j_username" <c:if test="${not empty param.login_error}">value='<%= session.getAttribute(AuthenticationProcessingFilter.SPRING_SECURITY_LAST_USERNAME_KEY) %>'</c:if>/>
	<br/>
	<label for="j_password">Password</label>
	<input type="password" name="j_password" id="j_password"/>
	<br/>
	<input type='checkbox' name='_spring_security_remember_me'/> Remember me on this computer.
	<br/>
	<input type="submit" value="Login"/>
</form>

The names of the form elements and form action must match what is shown here otherwise your login form will not work!

Note also that this is a plain ol’ JSP page, and not under Spring control. It is likely that you could play with the servlet filter patterns in web.xml to bring these pages under Spring control, but that is a topic outside the scope of this brief tutorial.

There are a couple other pages you will want to configure.

Access Denied: This is the page the user will see if they are denied access to the site due to lack of authorization (i.e. tried to hit a page that they didn’t have access to hit, even though they were authenticated properly). This is configured as follows:

    <http ... access-denied-page="/accessDenied.jsp">
     ...
    </http>

Default Target URL: This is where the user will be redirected upon successful login. This can (and probably should) be a page located under Spring control. Configured as follows:

    <http ... >
    ...
        <form-login ... default-target-url="/home.do"/>
    ...
    </http>

Logout URL: The page where the user is redirected upon a successful logout. This can be a page located under Spring control too (provided that it allows anonymous access):

    <http ... >
    ...
    	<logout logout-success-url="/home.do"/>
    ...
    </http>

Login Failure URL: Where the user will be sent if there was an authentication failure. Typically this is back to the login form, with a URL parameter, such as:

    <http ... >
    ...
        <form-login ... authentication-failure-url="/login.jsp?login_error=1"/>
    ...
    </http>

Putting it Together

Here’s what my whole sample Spring security configuration looked like when I was done:

<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.5.xsd
                        http://www.springframework.org/schema/security http://www.springframework.org/schema/security/spring-security-2.0.1.xsd">
 
	<global-method-security secured-annotations="enabled">
		<!-- AspectJ pointcut expression that locates our "post" method and applies security that way
		<protect-pointcut expression="execution(* bigbank.*Service.post*(..))" access="ROLE_TELLER"/>
		-->
	</global-method-security>
 
    <http auto-config="true" access-denied-page="/accessDenied.jsp">
        <intercept-url pattern="/login.jsp*" filters="none"/>  
        <intercept-url pattern="/admin/editUser.do" access="ROLE_ADMIN"  />
        <intercept-url pattern="/admin/searchUsers.do" access="ROLE_ADMIN"  />
        <intercept-url pattern="/**.do" access="ROLE_USER,ROLE_ADMIN"  />
    	<form-login authentication-failure-url="/login.jsp?login_error=1" default-target-url="/home.do"/>
    	<logout logout-success-url="/home.do"/>
    </http>
 
    <authentication-provider>
        <jdbc-user-service data-source-ref="dataSource" authorities-by-username-query="select username,authority from users where username=?"/>
    </authentication-provider>
 
</beans:beans>

Wrap-Up

Ironically, just as I was drafting this article, a smart colleague of mine happened to come to me telling me about all the problems he was having getting started with Spring Security. He complained about the lack of detailed documentation on the XML, and the fact that the getting started documentation really wasn’t comprehensive (both complains that I had as well). Note that this colleague also happened to be responsible for implementing Acegi Security with Spring in a prior project that we worked on together – so he was intimately familiar with the underlying technology. He ended up going back to the Java-based configuration mechanism in frustration!

Hope this helps you out and I always appreciate hearing your comments and questions.

Related Articles

• Juggling Java has a very brief article on customizing Spring Security.
• Bart van Riel has a great tutorial on Acegi Security, which has some relevant bits around the database schema that you might find interesting.

Displaytag supports easy display of formatted number columns using the format attribute on <display:column> – however, it’s not really well documented on the Displaytag site. Here’s how to do simple number formatting without requiring a decorator class:

<displaytag:column property="amount" title="$ Amount" format="{0,number,#.##}"/>

This will display a decimal formatted to a maximum of 2 decimal places!

This simple change in Spring 2.5.2 and above lets you remove boilerplate code that you have probably written for simple JDBC queries performed with the generics-aware SimpleJdbcTemplate (read my earlier 5 Minute Guide to… if you don’t know what this is). Change this:

new ParameterizedRowMapper<String>() {
			@Override
			public String mapRow(ResultSet rs, int rowNum) throws SQLException {
				return rs.getString("State");
			}
		}

Into this:

new ParameterizedSingleColumnRowMapper<String>()

The fully qualified class name is org.springframework.jdbc.core.simple.ParameterizedSingleColumnRowMapper. Neat! If you’re interested in where this came from, you can have a look at the JIRA issue SPR-4320.

As a frequent contributor to the Spring Framework user forums, I have noticed a common trend among people new to Spring MVC – they really don’t understand how to use JSTL and EL in their Spring-driven JSPs.

Although Spring MVC supports flexibility in choosing a view technology, in my [back of the napkin] estimate, at least 80% of the time it is paired with JSP and JSTL. Unfortunately, since JSP was pushed out about 4-5 years ago, a lot of the information that you find on the web is extremely dated, often going back to JSTL 1.0 syntax (or, gasp, using scriptlets!). In this article I’ll clear up the confusion around how to use JSTL with various app servers and webapp versions.
Continue reading “How to Reference and Use JSTL in your Web Application”

One of the most irritating limitations of plain JDBC is that queries with a variable number of parameters are notoriously painful to deal with. The most common case of this is with the IN clause, which by definition is intended to accept a variable length argument list. JDBC, for those who don’t know, does not allow variable-length bound parameters.

Having worked with Spring’s Hibernate abstraction (HibernateTemplate) for some time, I have gotten used to Spring’s value-added feature of expanding Collections bound to HQL parameters (it’s a shame that Hibernate doesn’t natively support this, AFAIK). I was pleasantly surprised to find out that Spring offers JDBC support for this feature as well. Here’s a simple set of examples…

Continue reading “Auto-Expanding Collections as JDBC Parameters with Spring SimpleJdbcTemplate”

I have noticed a trend recently among some folks in the Java world, where it is simply taken for granted that an ORM provider (usually Hibernate) will be automatically inserted in the technology stack of any new project. Quite often, this happens with little to no technical justification or analysis. If you’re reading this and nodding your head, this should be frightening to you. The reason is that if the use of an ORM isn’t required, it can cause projects (especially small ones) to have unneeded complexity. Additionally, abstraction without understanding what’s underneath can set a dangerous level of ignorance on the part of developers, who will simply collapse when the abstraction breaks and critical thinking through the abstraction is required to solve a problem.

In that spirit, I recently worked on a personal project to learn how one can write dead-simple plain old JDBC applications using only Spring Framework 2.5 without an ORM layer. Spring 2.5 has many features that provide some of the convenience of ORM libraries (simple mapping from ResultSets to Objects), some convenience above and beyond ORM libraries (mapping from ResultSets to primitives!*), and removes some of the complexity (caching, cascading, etc.). For applications with fewer tables than you have fingers on your hand, this can greatly ease development.

I’ll assume you already know how to work with Spring, and at least know (or can dredge up) the basics of JDBC. We’ll work through a simple example, mapping the ubiquitous “Person” table to a Person object, and back again through an insert operation. Hopefully this will open your mind to non-ORM solutions. I promise that in 5 minutes (or less!) you will be amazed at the things you can do with simple JDBC

Continue reading “5 Minute Guide to Spring and Simple[r!] JDBC”

Tomcat 6 does not ship with an implementation of JSTL. I decided to write up this quick start guide, since it’s really, really hard for new folks to know how to get started with Spring MVC (which is very often combined with JSTL) on Tomcat 6.

Sadly, Sun’s JSTL site does not even point you at the actual reference implementation of JSTL 1.2 (at least there’s no very obvious link that I have been able to find – but what good would a Sun web site be if it was easy to find what you were looking for? ).

The Apache Jakarta Taglibs project is the source of JSTL 1.0 and 1.1 reference implementations, but it is no longer maintained and will never implement JSTL 1.2.

The JSTL 1.2 reference implementation has been folded into the Glassfish application server. It seems that Sun in its infinite wisdom has decided to make the reference implementation almost impossible to find. The link to “Reference Implementation” on the JSR-052 page points you to the Sun Java EE download page (argh!)

So, how do you get this installed on Tomcat?

• Download the latest version of Glassfish V2 application server here.
• Unzip/install to a directory
• From the “lib” directory of the install, copy as follows:
  • appserver-jstl.jar: Place in the WEB-INF/lib directory of your web application. This is preferable because you can ensure that the correct version of JSTL lives with your application. Note you may run into classloader issues when running on application servers other than Tomcat which supply their own (conflicting) JSTL implementations. In this case, remove this JAR from your web application, and move it into {tomcat-install}/lib.
  • javaee.jar: In the {tomcat-install}/lib folder. This will make the JSTL 1.2 libraries available to all web applications.

Note that placing javaee.jar in the app server lib directory isn’t really the best way to go about this, but Tomcat will ignore the JAR if it’s included in your webapp due to the rule in section 9.3.2 of the Servlet 2.3 spec (in fact, it will ignore any JAR file completely if it contains the class javax.servlet.Servlet). For further reference, you can see the classloader code. You will see the following error when your webapp is started up if you have javaee.jar in WEB-INF/lib (assuming appropriate logging is enabled):

INFO: validateJarFile({path-to-webapp}\WEB-INF\lib\javaee.jar) – jar not loaded. See Servlet Spec 2.3, section 9.7.2.
Offending class: javax/servlet/Servlet.class

For you Spring MVC’ers trying to get started with the latest versions of Tomcat and JSTL, hopefully this helps you!