A Java geek

Servlet 3.0 is not only about the replacement of the web.xml deployment descriptor by annotations. In this article, we’ll see what improvement it makes in the realm of security.

In Servlet 2.5 (and before that), declarative security was about the following features:

• authentication method (BASIC, FORM, etc)
• authorization to differents parts of the application (web application resources)
• data confidentiality and integrity
• session time-out

Servlet 3.0 adds standardized ways regarding two configuration items.

The first parameter is how the session id is sent from the client to the server, so as for the latter to recognize the same session. Earlier in my carreer, I learnt that the first time an application server sends a response back to the client, it passes a cookie back and also appends to the URL, both referencing the unique jsessionid. Now, as soon as the second request is passed to the server, the latter knows the client accepts cookie or not and uses the appropriate mechanism: in essence, the strategy can be sumed up by “cookies first but fallback to URL rewriting if not possible”. Granted, there was a time when you couldn’t count on your client’s browsers to have cookies allowed. Nowadays, URL rewriting is first seen as a way to makes session hijacking easy as pie – even with HTTPS – since the id belongs to the URL. Hell, you’ll even find it in the logs! Servlet 3.0 aims to allow us to force the cookie strategy. The web.xml fragment to take care of this is the following:

<session-config>
  <cookie-config>
    <secure>true</secure>
  </cookie-config>
</session-config>

Moreover, cookies themselves can be unsafe since they can be accessed by most browsers JavaScript engine, thus allowing client code to read it. Yet, a subset of browsers let us configure the engine so as to disable JavaScript access (read and/or write) for this cookie. Servlet 3.0 let compliant application server mark cookies as HttpCookie, which does the trick. Even if this feature is completely implementation dependent, it helps cover a part of our security worries. It’s achieved with the nex web.xml snippet:

<session-config>
  <cookie-config>
    <http-only>true</http-only>
  </cookie-config>
</session-config>

Need for security are most often rediscoverd at the end of the development phase, when it costs much to implement. Moreover, some (if not most) securing nodes are a sysadmin’s responsibilities (configuring the 3rd-party LDAP, HTTPS, etc.). For example, the two previous capabilities were implementation dependent. This leaves security a very obscure field for young (and not-so-young) developers. I think that enhancements such as those provided by Servlet 3.0 tend to increase mutual understanding between developers and sysadmins.

In this article, I will show you that Spring dependency injection mechanism is not restricted solely to Spring-managed beans, that is Spring can inject its beans in objects created by the new keywords, servlets instantiated in the servlet container, and pretty anything you like. Spring classical mode is to be an object factory. That is, Spring creates anything in your application, using the provided constructor. Yet, some of the objects you use are outer Spring’s perimeter. Two simple examples:

• servlets are instantiated by the servlet container. As such, they cannot be injected out-of-the-box
• some business objects are not parameterized in Spring but rather created by your own code with the new keyword

Both these examples show you can’t delegate to Spring every object instantiation.

There was a time when I foolishly thought Spring was a closed container. Either your beans were managed by Spring, or they didn’t: if they were, you could inject them with other Spring-managed beans. If they weren’t, tough luck! Well, this is dead wrong. Spring can inject its beans into pretty much anything provided you’re okay to use AOP.

In order to do this, there are only 2 steps to take:

• Use AOP
• Configure object creation interception

Use AOP

It is done in your Spring configuration file.

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xmlns:context="http://www.springframework.org/schema/context"
  xsi:schemaLocation="http://www.springframework.org/schema/beans

http://www.springframework.org/schema/beans/spring-beans-2.0.xsd

http://www.springframework.org/schema/context

	http://www.springframework.org/schema/context/spring-context-2.5.xsd">

  <This does the magic />
  <context:spring-configured />

  <-- These are for classical annotation configuration -->
  <context:annotation-config />
  <context:component-scan base-package="ch.frankel.blog.spring.outcontainer" />

</beans>

You need also configure which aspect engine to use to weave the compiled bytecode. In this cas, it is AspectJ, which is the AOP component used by Spring. Since i’m using Maven as my build tool of choice, this is easily done in my POM. Ant users will have to do it in their build.xml:

<project xmlns="http://maven.apache.org/POM/4.0.0"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
    http://maven.apache.org/maven-v4_0_0.xsd">
...
  <properties>
    <spring-version>2.5.6.SEC01</spring-version>
  </properties>
  <dependencies>
    <dependency>
      <groupId>org.springframework</groupId>
      <artifactId>spring-aop</artifactId>
      <version>${spring-version}</version>
    </dependency>
    <dependency>
      <groupId>org.springframework</groupId>
      <artifactId>spring-aspects</artifactId>
      <version>${spring-version}</version>
    </dependency>
    <dependency>
      <groupId>aspectj</groupId>
      <artifactId>aspectjrt</artifactId>
      <version>1.5.4</version>
      <scope>test</scope>
    </dependency>
  </dependencies>
  <build>
    <plugins>
      <plugin>
        <groupId>org.codehaus.mojo</groupId>
        <artifactId>aspectj-maven-plugin</artifactId>
        <configuration>
          <complianceLevel>1.5</complianceLevel>
          <aspectLibraries>
            <aspectLibrary>
              <groupId>org.springframework</groupId>
              <artifactId>spring-aspects</artifactId>
            </aspectLibrary>
          </aspectLibraries>
        </configuration>
        <executions>
          <execution>
            <goals>
              <goal>compile</goal>
            </goals>
          </execution>
        </executions>
      </plugin>
    </plugins>
  </build>
</project>

Configure which object creation to intercept

This is done with the @org.springframework.beans.factory.annotation.Configurable annotation on your injectable object.

@Configurable
public class DomainObject {

  /** The object to be injected by Spring. */
  private Injectable injectable;

  public Injectable getInjectable() {

    return injectable;
  }

  @Autowired
  public void setInjectable(Injectable injectable) {

    this.injectable = injectable;
  }
}

Now with only these few lines of configuration (no code!), I’m able to inject Spring-managed beans into my domain object. I leave to you to implement the same with regular servlets (which are much harder to display as unit test).

You can find the Maven project used for this article here. The unit test packaged shows the process described above.

To go further:

• Aspect-oriented programming
• Aspect Oriented Programming with Spring
• The AspectJ™ Programming Guide
• Using AspectJ to dependency inject domain objects with Spring
• org.springframework.beans.factory.annotation.Configurable API