Now, if you want to apply security in a Grails application you are typically pointed in the direction of the Grails Acegi Plugin, which does a rather decent job at applying basic security to your Grails application. It quickly falls short however when you need to start doing something more than the bare basics (which you pretty much always need to do); even though the plugin is based on Spring Security, far from everything in the original framework is supported in the plugin, and hooking in custom components is pretty much out of the question. In addition to this, the Acegi Plugin is haunted by a couple of pretty annoying bugs.

Bottom line: for any real-world scenario you will most likely want to fall back to the original, i.e. use the original Spring Security framework in your Grails application. Since Grails is Spring-based it shouldn't be all that much work to set that up, right? Well basically yes, but as I set out do to it I ran into a number of problems before I got it right, so I thought I might as well line out the steps and pitfalls.

1. Download and Install the Spring Security jars

Typically, for the basic setup you should need only the spring-security-core.jar and spring-security-core-tiger.jar, but depending on your requirements you might need to include more of the Spring Security binaries. Place the jars in your lib directory of your Grails application.

2. Install Templates

Spring Security is based on an HTTP filter chain, which needs to be declared in the WEB-INF/web.xml file of the web application. This file is normally automatically generated for you by Grails, but for the event that you need more control (such as this occasion) you can have the default file generated for you to edit. The command for this is grails install-templates. This will generate a number of files, and the web.xml will be ready for editing under src/templates/war.

3. Add the Spring Security Filter Chain

There will be a number of filters defined in the web.xml file already. Add the Spring Security filter after the other filter definitions, but before the filter-mapping entries (all the filter definitions need to be placed before the filter-mapping ones, or else evil things will happen with any additional filters generated by Grails and we'll get in trouble when we deploy in tomcat).

<filter>
	<filter-name>springSecurityFilterChain</filter-name>
	<filter-class>org.springframework.web.filter.DelegatingFilterProxy</filter-class>
</filter>

Now, after the other filter-mapping entries, add the filter-mapping for the Spring Security filter:

<filter-mapping>
	<filter-name>springSecurityFilterChain</filter-name>
	<url-pattern>/*</url-pattern>
</filter-mapping>

4. Spring Security Configuration

Now we're ready to add the Spring Security configuration XML. Note that this configuration needs to be placed in grails-app/conf/spring/resources.xml. I initially tried to put it in WEB-APP/WEB-INF/applicationContext.xml but due to the Grails ApplicationContext loading magic that attempt failed spectacularly. We'll start out with a minimal Spring Security configuration just to get things going; for more information the configuration topic I'll refer to the reference documentation.

<beans xmlns="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.4.xsd"
        xmlns:sec="http://www.springframework.org/schema/security">
        <sec:http>
                <sec:intercept-url pattern="/**" access="ROLE_USER"/>
                <sec:http-basic />
        </sec:http>
        <sec:authentication-provider>
                <sec:user-service>
                        <sec:user name="mattias" password="12345" authorities="ROLE_USER"/>
                </sec:user-service>
        </sec:authentication-provider>
</beans>

Another note of caution here: If there is anything incorrect in your resources.xml Grails will happily and silently ignore this and go ahead and start anyway. Therefore, whenever you start doing stuff with your own custom Spring configuration in a Grails app it is imperative to make sure to configure your logging so that Spring warning and error messages are logged properly or you'll be completely in the dark trying to figure out what went wrong.

All done

As it turns out this wasn't as bad as expected. You're now all set to unleash the full power of Spring Security on your Grails application.

Basic Spring Remoting Configuration

In the general situation all you need to do is create a DispatcherServlet (just as you would with any Spring MVC application), add an Exporter on the server side and reference a ProxyFactoryBean on the client.
On the server side:

web.xml
<context-param>
<param-name>contextConfigLocation</param-name>
<param-value>/WEB-INF/applicationContext.xml</param-value>
</context-param>
<listener>
<listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
</listener>
<servlet>
  <servlet-name>demo</servlet-name>
  <servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
    <init-param>
<param-name>contextConfigLocation</param-name>
<param-value>/WEB-INF/demo-servlet.xml</param-value>
    </init-param>
    <load-on-startup>1</load-on-startup>
</servlet>
 
<servlet-mapping>
  <servlet-name>demo</servlet-name>
  <url-pattern>/*</url-pattern>
</servlet-mapping>
 

demo-servlet.xml - exposes bean 'helloService' as remote service
<bean name="/hello"
    class="org.springframework.remoting.httpinvoker.HttpInvokerServiceExporter">
<property name="service" ref="helloService" />
<property name="serviceInterface"
      value="se.jayway.demo.server.HelloService" />
</bean>
 

On the client side:

clientContext.xml
<bean id="helloService"
  class="org.springframework.remoting.httpinvoker.HttpInvokerProxyFactoryBean">
<property name="serviceUrl"
      value="https://remote-host:8080/security-remoting/hello" />
<property name="serviceInterface"
      value="se.jayway.demo.server.HelloService" />
</bean>
 

Now, in the client application all you need to do is ask for the 'helloService' bean and you will be handed a proxy that talks to the target service on the server without the server or the client knowing anything about it.

Securing the Remote Service

Now, in many cases you'll want to apply some security restrictions on the exposed HTTP service. Being in the Spring world the natural choice for this purpose will be Spring Security. Far from the complications of its predecessor Acegi, Spring Security configuration is now a matter of very few lines of XML code:

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

demo-servlet.xml - additions to the original file above; default with one hard coded user
<beans
  xmlns="http://www.springframework.org/schema/beans"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xmlns:sec="http://www.springframework.org/schema/security"
  xsi:schemaLocation=
        "http://www.springframework.org/schema/beans 
 
http://www.springframework.org/schema/beans/spring-beans.xsd
 
http://www.springframework.org/schema/security
 
         http://www.springframework.org/schema/security/spring-security-2.0.xsd">
...
<sec:http realm="Hello App">
  <sec:http-basic/>
  <sec:intercept-url pattern="/**" access="ROLE_USER" />
</sec:http>
<sec:authentication-provider>
  <sec:user-service>
    <sec:user name="someuser" password="somepassword" authorities="ROLE_USER" />
  </sec:user-service>
</sec:authentication-provider>
 

Note that we're defining the Spring Security XML schema in the schema definition.

clientContext.xml
<bean id="helloService"
  class="org.springframework.remoting.httpinvoker.HttpInvokerProxyFactoryBean">
<property name="serviceUrl"
      value="https://remote-host:8080/security-remoting/hello" />
<property name="serviceInterface"
      value="se.jayway.demo.server.HelloService" />
<property name="httpInvokerRequestExecutor">
    <bean class="org.springframework.security.context.httpinvoker.AuthenticationSimpleHttpInvokerRequestExecutor  />
  </property>
</bean>

The AuthenticationSimpleHttpInvokerRequestExecutor will make sure that any Spring Security applied on the client side will be transferred to the server side using Basic HTTP Authentication. The filters and the XML configuration on the server side will make sure the Authentication headers are inspected and checked against the valid principals and credentials.

Applying SSL

As most of you probably know, Basic HTTP Authentication is pretty much the same thing as sending the authentication information over the network in plain text. This is why you will typically want to use encrypted connections whenever you are working with this type of authentication. This gets us into the core of this post, because it's here it becomes tricky.

In the ideal world you would just configure your web server to expose the service over HTTPS, change the target URL on the client side and be on your way. The reality however is slightly more complicated.

The problem is that you the built-in HttpURLConnection class on which the AuthenticationSimpleHttpInvokerRequestExecutor relies is very picky when it comes to certificates. What you want to do when working with SSL in Spring Remoting is to use the CommonsHttpInvokerRequestExecutor, which relies on Commons HttpClient - a more flexible and capable HTTP client. Now, the problem with this is that then you cannot use the AuthenticationSimpleHttpInvokerRequestExecutor anymore - they plug into the HttpInvokerProxyFactoryBean at the same extension point.

It boils down to this: if you want to use Spring Remoting and Spring Security over SSL you will need to implement your own HttpInvokerRequestExecutor:

 
public class BasicAuthenticationCommonsHttpInvokerRequestExecutor extends
  CommonsHttpInvokerRequestExecutor {
 
  @Override
  protected PostMethod createPostMethod(HttpInvokerClientConfiguration config) throws IOException {
    PostMethod postMethod = super.createPostMethod(config);
 
    Authentication auth =
        SecurityContextHolder.getContext().getAuthentication();
 
    if ((auth != null) && (auth.getName() != null) &&
          (auth.getCredentials() != null)) {
      String base64 = auth.getName() + ":" + auth.getCredentials().toString();
      postMethod.setRequestHeader("Authorization", "Basic " +
          new String(Base64.encodeBase64(base64.getBytes())));
    }
 
    return postMethod;
  }
}
 

Now all you need to do is specify this implementation as HttpInvokerRequestExecutor for your client ProxyFactoryBean and you're all set:

clientContext.xml
<bean id="helloService"
  class="org.springframework.remoting.httpinvoker.HttpInvokerProxyFactoryBean">
<property name="serviceUrl"
      value="https://remote-host:8080/security-remoting/hello" />
<property name="serviceInterface"
      value="se.jayway.demo.server.HelloService" />
<property name="httpInvokerRequestExecutor">
    <bean class="se.jayway.demo.security.BasicAuthenticationCommonsHttpInvokerRequestExecutor"  />
  </property>
</bean>