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.

Part of the problem was (I guess) that the projects were created outside of Idea, so they had to be imported. Another thing that turned out to be a big problem was that there are a number of inter-dependencies between the projects (set up as plugin dependencies in BuildConfig.groovy). Now, here are the steps I had to go through to make a multi-sub-project Grails project working in IntelliJ Idea:

• First of all, create an empty top-level project (actively uncheck the 'Create Module' checkbox).
• Then, for each of the sub projects, create a new module. The tricky part here is that it turned out that you need to select 'Create from scratch..' option and select the root directory of each Grails app as module directory (and name). Then, just select 'Grails module', and you're done (for now)
• Now we need to set up the build paths manually. For each of the modules that have local libraries included in the lib directory, that directory needs to be added manually as a jar directory dependency of that module. Make sure you check the 'export' checkbox as well, so that the binaries are included when you build and when if this module is referenced from another module (see below).
• Next step is to manually remove and re-add each of the required plugins in each module. Be sure to re-add them one at a time; it didn't work to add multiple plugins at once
• Now if you have inter-dependencies between your modules (e.g. one app uses a plugin you made yourself, set up in BuildConfig.groovy), these need to be set up as module dependencies.
• Finally we're done. Now, double check the build path in the module settings window and make sure nothing is marked red. Try to build the project and you should be all set.

Obviously, the bad thing here is that it's an incredible amount of work involved in getting everything up and working. The good thing however is that once you have it all set up it works really well. Code navigation and even debugging a remote Grails application works as a charm. That said, I'm still not comfortable with how Idea works. It just feels awkward somehow. I can't wait for when the SpringSource guys get this working in Spring IDE so that I can get back to my IDE of choice.