I saw a plaintive wail on Twitter about using GMail as the smtp server to send error emails using a Log4j SMTPAppender in Grails. It turned out to be a little tricky (and a bigger solution than 140 characters would allow) so I thought I'd describe the process here.

Most of the properties are configurable as appender attributes (e.g. server name, auth username, etc.) but two important ones aren't. SMTPAppender creates a Properties instance with System.getProperties() as the default values and adds smtp properties to that. But you need to specify the smtp port (it will default to 25 otherwise) and you need to tell it to send a STARTTLS command. Both are configurable via system properties:

and if you add those calls to Config.groovy before the appender is instantiated then it will have the values available when it configures its JavaMail Session:

I've parameterized the properties to make them configurable for each environment or using an external configuration file.

Note that GMail has a limit of 500 emails per day, so if you generate a lot of errors in your app you could hit that limit.

The topic of delaying DataSource and SessionFactory creation until some point after startup has come up a few times on the Grails user mailing list so I thought I'd give it a shot. I got it working, but it's not pretty.

Grails (and Hibernate) will create up to three connections during initialization so the primary focus is to avoid those. In addition the DataSource will pre-instantiate connections, so we'll delay those as well.

The first connection required is for HibernateDialectDetectorFactoryBean, which uses connection metadata to figure out the dialect if it's not specified. This is a cool feature but problematic if you don't want early access to the database, and luckily the fix is simple: specify the dialect class in DataSource.groovy:

substituting the appropriate class name for your database.

The second connection will be for SpringLobHandlerDetectorFactoryBean, which uses connection metadata to determine if you're using Oracle and if so to use an Oracle-specific LobHandler. The fix here is also simple: override the lobHandlerDetector bean in grails-app/conf/spring/resources.groovy with the correct version for your database. It's a little different if you're using Oracle or another database.

If you're not using Oracle, redefine the bean as

and if you are, define it as

and omit specifying nativeJdbcExtractor if you're not using pooled connections (e.g. if you're using JNDI).

The third connection is for Hibernate and is used to initialize the Configuration. This one is more work and requires some custom code. It's also somewhat brittle in that it requires a copy/paste of the sessionFactory bean definition from Grails source with some modifications, so it will probably require changes to work with future version of Grails.

Here's the override for Grails 1.2:

and here's the override for 1.1:

DelayedSessionFactoryBean extends ConfigurableLocalSessionFactoryBean to create a wrapper for the SessionFactory that lazily creates the real SessionFactory. Add this to src/groovy:

To delay DataSource creation, we'll use Spring's DelegatingDataSource and build the actual DataSource from the values in grails-app/conf/DataSource.groovy the first time getConnection() is called:

This also requires an override in grails-app/conf/spring/resources.groovy:

This creates a BasicDataSource which is what Grails will use by default, but of course feel free to change it to c3p0 or some other provider.

The net effect of using these classes and overridden Spring bean definitions is that both the DataSource and SessionFactory will be lazily initialized on first use. One option might be to have an initialization page that accepts configuration overrides for the database url, username, etc. to allow an admin to start the app and choose the appropriate settings.

The source files shown here are available at DelayedSessionFactoryBean and DelayedDataSource, and grab resources.groovy as a sample to merge into your own resources.groovy.

It has taken way too long, but the Grails Spring Security plugin finally has ACL support. It's not officially available yet, but people have offered to beta test an early version of the plugin with ACLs, so you can download that here and report any issues back. Once it's stable I'll do an official release.

History

Stephan February did the first work adding ACL support to the plugin. Unfortunately at the time the plugin was based on Acegi 1.0.x and I had just converted it to use Spring Security 2.0. No one did the work to convert the ACL support to the new package layout and approach, so this wasn't used.

This is a frequently requested feature, so I created a feature request as a TODO item for myself. I found some time to work on this over the summer and created an initial GORM-based implementation (the standard Spring Security implementation uses JDBC). I was fortunate to be able to use this at a client project at InnoCentive which helped to flesh out the ideas and identify a few issues.

Around the same time, Phillip Merensky mentioned on the mailing list that he was working on an implementation. He wrote about his approach here and attached his version of the plugin to the JIRA issue. Phillip's work was very helpful; I've merged his version with mine for the current implementation.

Working with ACLs in Spring Security is complex but it will be easier to understand with a sample application.

Test Application

Create a test application

Download the plugin with ACL support here and install it:

As with any application using the plugin, you need to run the create-auth-domains script, plus generate-manager if you want the generated GSPs and generate-registration if you want basic registration support:

The ACL support uses domain classes but to allow customizing the domain classes (e.g. to enable Hibernate 2^nd-level caching) there's a script that copies the domain classes into your application:

The script takes no parameters since the package and names aren't configurable - the plugin code imports the domain classes.

Next, switch from using Requestmap entries in the database to using annotated controllers:

• delete grails-app/domain/acltest/Requestmap.groovy
• delete grails-app/controllers/RequestmapController.groovy
• delete the grails-app/views/requestmap directory and its GSPs
• delete Requestmap import from grails-app/controllers/RoleController.groovy
• in grails-app/conf/SecurityConfig.groovy, disable requestmaps (useRequestMapDomainClass = false) and enable annotations (useControllerAnnotations = true), and remove the requestMapClass property:
  security {
     active = true

     loginUserDomainClass = 'acltest.User'
     authorityDomainClass = 'acltest.Role'

     useRequestMapDomainClass = false
     useControllerAnnotations = true
  }

To enable ACL processing, set the useAcl attribute to true:

We'll need a domain class to test with, so create a Report domain class:

and add a name property for testing:

Working with ACLs

Probably the most important interface for ACLs is Permission. You can implement the interface yourself, but BasePermission has READ, WRITE, CREATE, DELETE, and ADMINISTRATION instances that should be sufficient for your needs.

The plugin provides a new service, AclUtilService, to grant and revoke permissions, and to check if permissions are granted. The service methods are:

• void addPermission(object, recipient, Permission permission) grants the specified permission to the recipient (either the login name or an Authentication) for the specified instance
• void addPermission(Class< ?> domainClass, long id, recipient, Permission permission) grants the specified permission to the recipient (either the login name or an Authentication) for the specified instance; use this overload to avoid loading the instance
• void deletePermission(object, recipient, Permission permission) removes the grant of the specified permission from the recipient (either the login name or an Authentication) for the specified instance
• void deletePermission(Class< ?> domainClass, long id, recipient, Permission permission) removes the grant of the specified permission from the recipient (either the login name or an Authentication) for the specified instance; use this overload to avoid loading the instance
• boolean hasPermission(Authentication authentication, domainObject, Permission permission) checks if the authentication has a grant of the specified permission for the specified instance
• boolean hasPermission(Authentication authentication, domainObject, Permission[] permissions) checks if the authentication has a grant of any of the specified permissions for the specified instance; the first one that is found is used, so the order of the array matters

Creating, editing, or deleting permissions requires an authenticated user. The default required role is ROLE_ADMIN for all actions, but this can be configured in SecurityConfig.groovy. Change the acl.authority.changeOwnership property to change who can call OwnershipAcl.setOwner(). Change the acl.authority.modifyAuditingDetails property to change who can call AuditableAcl.updateAuditing(). And change acl.authority.changeAclDetails to change who can call MutableAcl.deleteAce(), MutableAcl.insertAce(), MutableAcl.setEntriesInheriting(), MutableAcl.setParent(), or MutableAcl.updateAce().

You'll probably want to create an admin UI that uses AclUtilService and is aware of your secured domain classes and business rules.

Configuration

Configuring ACL support happens in two places; you configure Voters that have one or more associated permissions and a domain class (which can be an abstract base class), and you configure which service methods use which voters. Often there will be a 1-1 relationship between these but since they're separate, you can re-use the voters for multiple service methods. And you may not even need custom voters; if you only want to secure methods with roles, or if you only need return value checking, then you wouldn't configure any voters, but you'd still configure method restrictions.

There are two types of ACL checks; method return value and method parameter. The plugin creates two voters for return value checks, one for single values (AFTER_ACL_READ) and one for collections (AFTER_ACL_COLLECTION_READ). Each requires that the authenticated user have BasePermission.READ. An optimization would be to allow access to admins (who have been granted BasePermission.ADMINISTRATION); to configure this, redefine the beans in grails-app/conf/spring/resources.groovy:

Voters for method parameter checks (the first parameter of the specified type or a subclass is checked) can be configured either in SecurityConfig.groovy or in domain class annotations. Putting the configuration in SecurityConfig.groovy keeps everything in one place, whereas the annotations let you put the declarations where they apply, so they're self-documenting. Use whichever approach you prefer.

To configure them in SecurityConfig.groovy, use the acl.voters property, e.g.

which creates a 'write' voter and a 'delete' voter. The equivalent annotations would be:

Note that since you cannot use an annotation more than once, in a case like this where there can be multiple voter annotations for a domain class they need to be defined as attributes of a containing annotation (AclVoters). If you only have a single voter then you can annotate the class with that and omit the containing annotation.

The voter configuration should be fairly clear; there's a name parameter that's used as the Spring bean name (so it must be unique), a configAttribute parameter that's arbitrary but typically uses a naming convention where it starts with 'ACL_', and one or more permissions. The one limitation of annotations over the static configuration is that annotations cannot have Permissions as parameters, so Strings are used instead. This limits you to naming fields of the BasePermission class. If you have custom permission classes you'll need to use the static configuration.

Securing Service Methods

As with voters, there are two ways to define the access rules for service methods. You can define a static springSecurityACL property with configuration options, or annotate the class and/or individual methods.

Let's create a service to test ACLs:

and add some methods that work with Reports:

To configure the rules in one place, add a springSecurityACL property:

and the equivalent annotated version would be:

The configuration specifies these rules:

• getReportName requires that the authenticated user have either ROLE_USER or ROLE_ADMIN (but no ACL rules)
• getAllReports requires ROLE_USER and will have elements removed from the returned List that the user doesn't have an ACL grant for (thanks to AFTER_ACL_COLLECTION_READ); the user must have one of the permissions defined in the afterAclCollectionRead bean (by default BasePermission.READ) for each element in the list; elements that don't have access granted will be removed
• getReport requires ROLE_USER and will be denied (thanks to AFTER_ACL_READ) unless the user has one of the permissions defined in the afterAclRead bean (by default BasePermission.READ).
• updateReport has no role restrictions but must satisfy the requirements of the aclReportWriteVoter voter (which has the ACL_REPORT_WRITE config attribute), i.e. BasePermission.ADMINISTRATION or BasePermission.WRITE
• deleteReport has no role restrictions but must satisfy the requirements of the aclReportDeleteVoter voter (which has the ACL_REPORT_DELETE config attribute), i.e. BasePermission.ADMINISTRATION or BasePermission.DELETE
• createReport has no restrictions

To test this out we'll need some users; create those and their grants in BootStrap.groovy:

And to have a UI to test with, let's create a Report controller and GSPs:

But to use the controller, it will have to be reworked to use ReportService. It's a good idea to put all create/edit/delete code in a transactional service, but in this case we need to move all database access to the service to ensure that appropriate access checks are made:

Note that the controller is annotated to require either ROLE_USER or ROLE_ADMIN. Since services have nothing to do with HTTP, when access is blocked you cannot be redirected to the login page as when you try to access a URL that requires an authentication. So you need to configure URLs with similar role requirements to give the user a chance to attempt a login before calling secured service methods.

Start the app:

and open http://localhost:8080/acltest/report/list

Login as user2/user2 and you should only see reports #5 and #10. Logout via http://localhost:8080/acltest/logout and open the list page again, this time logging in as user1/user1. Now you should be able to see instances #1-4.

Verify that you can view #3 directly by clicking the id or opening http://localhost:8080/acltest/report/show/3. Also verify that you can edit #3 but cannot delete it.

Verify that you can view #4 directly by clicking the id or opening http://localhost:8080/acltest/report/show/4 and that can edit and delete it.

Verify that you can't view #7 directly by opening http://localhost:8080/acltest/report/show/7.

You can download the full sample app here and the plugin with ACL support here.

There isn't much documentation available for Spring Security ACLs, but I found this blog post to be very informative and thorough.

If you have questions or issues with the code, please email the Grails User mailing list so others who might be having similar problems can partipate in the conversation.

I was looking at a non-Grails Spring Security application that used hierarchical roles and wondered what it'd take to get this working with the Grails plugin. Turns out it's pretty simple.

Non-hierarchical roles are checked by a RoleVoter but to use hierarchical roles you need a RoleHierarchyVoter. Replacing the roleVoter bean in resources.groovy is all it takes.

RoleHierarchyVoter needs an implementation of RoleHierarchy and the default implementation in Spring Security is RoleHierarchyImpl which parses a String defining the hierarchy. For example, this configuration defines the hierarchy ROLE_SUPERADMIN > ROLE_ADMIN > ROLE_USER:

You can download a small demo app here that shows how it works. Unpack the app and run grails run-app, and then open http://localhost:8080/hierarchical/secure/. The app creates three users in BootStrap:

so you can login as each user to test the secured actions:

Logout in between by navigating to http://localhost:8080/hierarchical/logout. Although only one role is defined for each action, as the super admin you can access all three, as the admin you can access admin and user, and as the user you can only access user.

I'll make this part of the plugin at some point to make configuration simpler, but for now it's not much work to do it explicitly.

I did a talk on Grails clustering at the Groovy & Grails eXchange 2009 in London last week and wanted to put up the slides and the sample application and clustering scripts. This was the third time I've given a version of this talk (first at a Boston Grails meetup and again at SpringOne 2GX) so I'm way overdue getting this up.

I created a simple Grails app and installed the Spring Security plugin (to test web cluster login failover and to have domain classes for Hibernate 2^nd level caching) and the Quartz plugin to demonstrate support for multiple servers. The basic non-clustered version is here so you can compare it to the version that has the required changes here.

In no particular order, here are the relevant project files:

• There's a simple Quartz job in grails-app/jobs/ClusterTestJob that prints which instance it's running on to stdout every two seconds.
• grails-app/conf/QuartzConfig.groovy specifies jdbcStore=true to have the plugin configure job storage in the database instead of in-memory.
• Externalized configuration is enabled in grails-app/conf/Config.groovy using
  grails.config.locations = [
       "classpath:${appName}-config.groovy",
       "file:./${appName}-config.groovy"]

  which allows local dev environment configuration using a file name clustered-config.groovy in the root directory of the project, or prod configuration (e.g. to keep production database passwords out of source control) using a clustered-config.groovy in the classpath. Tomcat's lib directory is in its classpath, so that's a convenient place to put the file.

• In addition note that the Log4j file loggers are configured using ServerAwareFileAppender. Specifying the location of log files is tricky. If you leave the path out and make it relative, then files get created relative to the directory Tomcat is started from, which might not always be the same. But if you hard-code the path, it won't work cross-platform. So this class figures out if you're running in Tomcat or Jetty and if you're running in dev mode, and is also cluster-aware. Depending on how you're running it knows where the logs directory is and puts logs there.
• grails-app/conf/hibernate/hibernate.cfg.xml loads grails-app/conf/hibernate/Quartz.mysql.innodb.hbm.xml which has DDL for creating the tables needed for Quartz. Use the appropriate DDL for your database from one of the files in the Quartz plugin's src/templates/sql directory.
• Role.groovy has been customized to support the Hibernate 2nd-level cache:
  - implements Serializable
  - read-only cache configured in mapping (along with disabling optimistic locking since it's not needed)
  - custom list() and count() methods that optionally use the cache or bypass it
• User.groovy is also customized for the Hibernate 2nd-level cache:
  - implements Serializable
  - read-write cache configured in mapping
• grails-app/conf/spring/resources.groovy has the fix for GRAILSPLUGINS-1207
• src/java/ehcache.xml has caches configured for the domain classes. It's not distributed though since it'll be used in the development environment.
• scripts/_Events.groovy has code to delete unused jars (unrelated to clustering, just a good idea) and delete the version of ehcache.jar that comes with Grails since the app uses a newer version. It also replaces the non-distributed ehcache.xml with the distributed version from cluster_resources, and copies quartz.properties in case you need to customize those beyond the defaults.
• grails-app/conf/BootStrap.groovy has code to create the admin role and an admin user to test login

The files from Tomcat and the cluster scripts are available here. Untar them somewhere on the server where you want to create a cluster:

You'll see five scripts:

• cleanup.sh
• createCluster.sh
• createInstance.sh
• deploy.sh
• run.sh

These are combinations of bash scripts and an Ant build file (clusterTasks.xml). All of the scripts need a cluster root directory. You can either specify it for each script invocation (run the script without parameters to see the usage) or you can set the CR environment variable

The first script to run is createCluster.sh:

This will create the directory structure and copy the Tomcat jars and other shared files.

There's an empty clustered-config.groovy that you can use to customize the production deployment. One common use for this is to externalize database passwords. This can be done with JNDI, but I prefer a self-contained war file that doesn't require container-specific configuration. This is copied to $CR/shared/lib when you run createCluster.sh since it's shared by all instances.

Next you need to run createInstance.sh once for each cluster node on this server. The syntax is

createInstance.sh [server number] [instance number] [cluster root dir]

and you need to ensure that the server number and instance number combination is unique throughout the cluster. This is simple if you number each server and choose a unique instance number for each instance on that server, e.g.

on server one,

on server two, etc. So go ahead and create at least two nodes on this server:

Some files to note are $CR/shared/conf/server.xml and $CR/instance_X/conf/catalina.properties. Most values in server.xml have been replaced with ${} properties whose values are specified in catalina.properties. These property values are retrieved via System.getProperty() but Tomcat reads catalina.properties and sets system properties from there. Using this approach we can have one parameterized server.xml and allow per-instance customization of ports, etc. Another config file is $CR/instance_X/bin/setenv.sh which configures CATALINA_OPTS (and optionally other environment variables). Edit this file to change the heap or permgen memory for each instance.

Having created the instances, now you need to deploy a war. Download the test project and unpack it:

and run grails compile to trigger installation of the project's plugins. As mentioned in the presentation, there's a bug in the Quartz plugin that causes a problem in clusters since it tries to re-register jobs, so edit plugins/quartz-0.4.1/QuartzGrailsPlugin.groovy and change

to

Now you can build the war:

and use deploy.sh to deploy it to the cluster:

The name of the war isn't important since deploy.sh deploys as the root context (in $CR/shared/webapps/ROOT). Note that you only deploy a war once per server since it's shared by all instances on that box.

Next create the database:

The project has a modified version of the SchemaExport script that fixes a bug reading hbm.xml files, so run

and choose option [2] to use the project version instead of the Grails version (this bug is fixed in Grails 1.2). This will create a file called ddl.sql that you can use to create the tables. The generated script is designed to be used by Hibernate's schema export tool which ignores errors trying to drop foreign keys on non-existent tables but this will fail from the commandline, so edit the file and remove all of the DROP TABLE ... and alter table ... drop foreign key ... statements and run

Now that we've deployed the war and created the database, we can now start the instances using run.sh. The syntax is

run.sh [start|stop|run] [instance number]

so you would run

to start instance #1. Once it has successfully started you can start the other instances:

You should see output indicating that the instances are discovering one another.

The server logs are in a few different directories. $CR/instance_X/logs will contain that instance's catalina.out and localhost_access_log, and the two rolling Log4j logs configured in Config.groovy, X_clusterdemo.log and X_sql.log, prefixed with the instance number.

$CR/shared/logs contains the remaining Tomcat logs; admin, catalina, host-manager, localhost, and manager all prefixed with the instance number. instance_X.pid files are here also, containing the process id for each instance to help with shutting down individual instances.

There is no load balancing configured yet; this can be configured using hardware load balancers, Apache, etc. $CR/shared/conf/server.xml configures the jvmRoute attribute of the <Engine> element (worker${cluster.server.number}_${cluster.instance.number}) for use with mod_jk.

So for now to test the app we'll go to specific instances. Open http://localhost:8091/admin/ and since that controller is secured, it'll prompt you to login. Use the username and password configured in BootStrap.groovy (admin/p4ssw0rd) and you should be allowed to view the page.

To test session replication, kill this instance. Find the pid for instance 1 in $CR/shared/logs/instance_1.pid and run kill -9 to ensure there's no orderly cleanup:

You'll see messages in the logs for instance 2 indicating that instance 1 has disappeared:
org.apache.catalina.tribes.group.interceptors.TcpFailureDetector memberDisappeared. You'll also see that if Quartz wasn't running in instance 2 it now is.

Open http://localhost:8092/admin/ and you should still be logged in since your Authentication is stored in the HTTP session and was replicated.

To shutdown an instance, use run.sh with the stop argument:

You can use cleanup.sh to delete log files and temp files in the temp and work directories. This isn't required but it's convenient.

Some further reading:

• Tomcat 6 clustering docs
• Tomcat: The Definitive Guide
• Quartz JDBC information
• Ehcache xml documentation

Links and files:

• The PDF slides from the London talk
• Watch the video of the London talk
• The non-clustered application
• The clustered version
• The cluster files and scripts

I got back from the Groovy & Grails eXchange 2009 a few of days ago and wanted to get some thoughts down before the whole thing becomes a blur. It was quite a week - the conference was two days but I brought my wife and extended the trip into a small vacation. We did a bunch of tourist stuff including the Tower of London, the British Museum, Stonehenge, the cathedral in Salisbury, shopping at Oxford Street and Portobello Market, saw a play, etc. Wendy Devolder and her husband Nick graciously offered to meet us Saturday at Portobello Market since they live nearby. Portobello Market is huge but thanks to Wendy and Nick we saw a bunch of stuff we would have otherwise missed, including the amazing Mutate Britain: One Foot in the Grove street art and sculpture show.

There were even other attendees from Boston. My colleague Eugenia Harris (we work together at InnoCentive) was also there for the week so the three of us did a lot of the touristy stuff together, and four guys from Cantina Consulting were also there.

The talks were excellent, but the best thing about these conferences is the social interactions. I met a bunch of Groovy/Grails/Griffon folks in New Orleans at SpringOne 2GX and this was another opportunity to meet even more. I got to meet and talk to several Grails contributors and users including Peter Ledbrook, Marc Palmer, Tomas Lin, Robert Fletcher, Glenn Saqui, Luis Arias, Jakob Külzer, Stefan Armbruster, and Jeremy "The Human Grails Search Engine" Flowers.

The conference was very well run by Russ Miles and Wendy Devolder's crew at Skills Matter. The space was a little overbooked and would have been better with closer to 100 attendees but they were aware of that and are still getting used to the new location that they recently moved to. Other than that everything was smooth sailing, and they created a conducive environment for a bunch of Grails and Groovy geeks.

One particularly cool aspect was the speaker's dinner on Tuesday at the Slaughtered Lamb. It was fun talking to (and drinking with) Wendy, Nick, Peter, Tomas, and the rest of the folks there. Not having met people there in person, it was great to make some early introductions before the conference started.

The talks that I found most interesting involved stuff that I rarely use. I don't do much complex configuration management but I have in the past, so Russel Winder's Gant talk and Hans Dockter's Gradle talk were great to get a sense for the current state of the art in build tools. I also don't do much UI work, but I thought Tomas Lin's Flex talk and Sébastien Blanc's iWebkit talk were both pretty cool. They definitely make creating slick UIs look easy.

The highlight of the conference for me though wasn't actually part of the conference - Graeme Rocher and Peter Ledbrook's GGUG on Wednesday night on Grails internals. It was a rare opportunity to see a presentation from the two people who have contributed most significantly to Grails. We had a half hour break after a full day at the conference and they spoke and took questions for an hour and a half. It made for a long day, but the audience clearly would have stayed for hours more.

So all in all it was a blast. London was a lot of fun, and Skills Matter put on a great conference. We could use a Skills Matter here in Boston

You can download the PDF slides and watch the video here. I wrote up a post here showing how to use the sample apps from the talk.

This is the second in a series of posts making the demo applications that I used for my SpringOne 2GX presentations available. I'll describe here how to create a Grails application using the Spring Security plugin that authenticates users from LDAP. This is based on topics from the Demystifying Spring Security in Grails talk (you can download the presentation here) but wasn't shown there since I ran out of time.

Also refer to the plugin documentation for other tutorials here.

To create an application that authenticates users from LDAP, run

To make classpath management simpler in Eclipse/STS I create a grails-app/conf/BuildConfig.groovy (in Grails 1.1 apps; in 1.2 this is done for you) with the line

grails.project.plugins.dir='plugins'

to keep plugins in the project root like in 1.0.x but this is optional.

Next install the plugin:

Run the create-auth-domains script to generate the person, authority, and request map domain classes and also grails-app/conf/SecurityConfig.groovy:

The other two scripts that the plugin provides are optional and create CRUD pages (generate-manager) and basic user registration (generate-registration). It's a good idea to run generate-manager; run generate-registration if it's useful to you.

As with the previous post we'll use annotated controllers, so we'll need to configure that, and we can delete the request map class and CRUD pages. The plugin scripts currently asssume you'll be using request maps, so we have to run generate-manager and generate-registration before deleting these.

• delete grails-app/domain/com/burtbeckwith/springone2gx/Requestmap.groovy
• delete grails-app/controller/RequestmapController.groovy
• delete the grails-app/views/requestmap directory and its GSPs
• remove the com.burtbeckwith.springone2gx.Requestmap import from grails-app/controller/RoleController.groovy
• in grails-app/conf/SecurityConfig.groovy, disable requestmaps (useRequestMapDomainClass = false) and enable annotations (useControllerAnnotations = true), and remove the requestMapClass property:
  security {

     active = true

     loginUserDomainClass = "com.burtbeckwith.springone2gx.User"
     authorityDomainClass = "com.burtbeckwith.springone2gx.Role"

     useRequestMapDomainClass = false
     useControllerAnnotations = true
  }

In Eclipse or STS the steps to configure the classpath are:

• add PLUGIN_DIR/src/groovy as a source folder
• add PLUGIN_DIR/src/java as a source folder
• add PLUGIN_DIR/grails-app/services as a source folder
• add these jars from PLUGIN_DIR/lib
  • facebook-java-api-2.0.4.jar
  • jcifs-1.2.25.jar
  • spring-ldap-1.2.1.jar
  • spring-ldap-tiger-1.2.1.jar
  • spring-security-core-2.0.4.jar
  • spring-security-core-tiger-2.0.4.jar
  • spring-security-ntlm-2.0.4.jar
  • spring-security-openid-2.0.4.jar

Having done all that, let's create a secured controller to test annotations:

and add the import for the annotation, and annotate at the class level that you must be an admin to access this controller:

The controller has a redirect from the default action and a second action so we can test that all methods inherit the class-level annotation.

Next lets configure LDAP. To make this a self-contained demo, we'll use the excellent LDAP server plugin but obviously you'll need to configure the application to connect to your LDAP server.

Install the plugin by running

and add the necessary LDAP configuration option to grails-app/conf/SecurityConfig.groovy (at a minimum useLdap = true)

The LDAP plugin requires one or more configured LDAP servers in grails-app/conf/Config.groovy and we'll need just one:

The plugin will auto-load .ldif data files with user information, so put these records in grails-app/ldap-servers/d1/data/users.ldif:

dn: ou=groups,dc=d1,dc=example,dc=com
objectclass: organizationalUnit
objectclass: top
ou: groups

dn: cn=USER,ou=groups,dc=d1,dc=example,dc=com
objectclass: groupOfUniqueNames
cn: USER
objectclass: top
uniqueMember: cn=person1,dc=d1,dc=example,dc=com
uniqueMember: cn=person2,dc=d1,dc=example,dc=com
uniqueMember: cn=person3,dc=d1,dc=example,dc=com

dn: cn=ADMIN,ou=groups,dc=d1,dc=example,dc=com
objectclass: groupOfUniqueNames
objectclass: top
cn: ADMIN
uniqueMember: cn=person2,dc=d1,dc=example,dc=com

dn: cn=person1,dc=d1,dc=example,dc=com
objectClass: uidObject
objectClass: person
objectClass: top
objectClass: organizationalPerson
uid: person1
userPassword: {SHA}44rSFJQ9qtHWTBAvrsKd5K/p2j0=
cn: person1
sn: jones

dn: cn=person2,dc=d1,dc=example,dc=com
objectClass: uidObject
objectClass: person
objectClass: top
objectClass: organizationalPerson
uid: person2
userPassword: {SHA}KqYKj/f81HPTIeAUav2eJt85UUc=
cn: person2
sn: jones

dn: cn=person3,dc=d1,dc=example,dc=com
objectClass: uidObject
objectClass: person
objectClass: top
objectClass: organizationalPerson
uid: person3
userPassword: {SHA}ERnP037iRzV+A0oI2ETuol9v0g8=
cn: person3
sn: jones

Spring Security will by default convert LDAP groups ('groupOfUniqueNames') to roles, prefixing the group names with ROLE_, so this data creates three users; person1, person2, and person3 (with passwords 'password1', 'password2', and 'password3' respectively), all with ROLE_USER and person2 with ROLE_ADMIN.

Since LDAP is only managing authentication details we need local data in the database; create the corresponding entries in BootStrap:

Since LDAP is handling authentication, we can (partially) remove password-related fields from User.groovy along with other unused fields:

We need to leave in the passwd property since GrailsDaoImpl expects it but its value isn't important so we'll just hard-code it in the domain class. A custom subclass GrailsDaoImpl or a new implementation of UserDetailsService would remove this requirement.

Start the app using

and open http://localhost:8080/springone2gx_ldap/secure/ in a browser and it should prompt you to login. If you login as person1 or person3 you'll be denied access since those users only have ROLE_USER but person2 has ROLE_ADMIN and will be allowed.

After successful login it'll redirect to http://localhost:8080/springone2gx_ldap/secure/foo - verify that http://localhost:8080/springone2gx_ldap/secure/bar is also secured by going to that in your browser.

You can download a finished application based on this discussion here

This is the first in a series of posts making the demo applications that I used for my SpringOne 2GX presentations available. I'll describe here how to create a standard Grails application using the Spring Security plugin that authenticates users from a database. This was used in the Demystifying Spring Security in Grails talk (you can download the presentation here)

Also refer to the plugin documentation for other tutorials here.

To create a standard application that loads users from a database, run

To make classpath management simpler in Eclipse/STS I create a grails-app/conf/BuildConfig.groovy (in Grails 1.1 apps; in 1.2 this is done for you) with the line

grails.project.plugins.dir='plugins'

to keep plugins in the project root like in 1.0.x but this is optional.

Next install the plugin:

Run the create-auth-domains script to generate the person, authority, and request map domain classes and also grails-app/conf/SecurityConfig.groovy:

The other two scripts that the plugin provides are optional and create CRUD pages (generate-manager) and basic user registration (generate-registration). It's a good idea to run generate-manager; run generate-registration if it's useful to you.

There are three methods for securing URLs in the plugin and for this demo we'll use controller annotations, so we'll need to configure that. We can delete the request map class, controller, and CRUD pages since they won't be needed. The plugin scripts currently assume you'll be using request maps, so we have to run generate-manager and generate-registration before deleting these.

• delete grails-app/domain/com/burtbeckwith/springone2gx/Requestmap.groovy
• delete grails-app/controller/RequestmapController.groovy
• delete the grails-app/views/requestmap directory and its GSPs
• remove the com.burtbeckwith.springone2gx.Requestmap import from grails-app/controller/RoleController.groovy
• in grails-app/conf/SecurityConfig.groovy, disable requestmaps (useRequestMapDomainClass = false) and enable annotations (useControllerAnnotations = true), and remove the requestMapClass property:
  security {

     active = true

     loginUserDomainClass = "com.burtbeckwith.springone2gx.User"
     authorityDomainClass = "com.burtbeckwith.springone2gx.Role"

     useRequestMapDomainClass = false
     useControllerAnnotations = true
  }

The current plugin is monolithic - it has support for several authentication mechanisms (OpenID, Facebook, etc.) If you're not using these you can delete that code and associated jar files. This is completely optional, and you can always add them back by extracting them from the plugin zip.

If you're not using OpenID, here are the steps to remove that code:

• delete the org.codehaus.groovy.grails.plugins.springsecurity.openid package: PLUGIN_DIR/src/groovy/org/codehaus/groovy/grails/plugins/springsecurity/openid
• delete these jars
  • openid4java-0.9.2.jar
  • spring-security-openid-2.0.4.jar
  • xmlsec-1.3.0.jar
  • htmlparser-1.6.jar
  • commons-httpclient-3.0.1.jar
  • openxri-client.jar
  • openxri-syntax.jar
• in LoginController.groovy
  • delete def openIDConsumer
  • delete def openIDAuthenticationProcessingFilter
  • delete the openIdAuthenticate() action
  • remove the config.useOpenId part in the auth() action

If you're not using Facebook, here are the steps to remove that code:

• delete the org.codehaus.groovy.grails.plugins.springsecurity.facebook package: PLUGIN_DIR/src/java/org/codehaus/groovy/grails/plugins/springsecurity/facebook
• delete these jars
  • facebook-java-api-2.0.4.jar
  • json-20070829.jar
• in LoginController.groovy
  • remove the config.useFacebook part in the auth() action

If you're not using Kerberos, here are the steps to remove that code:

• delete the org.codehaus.groovy.grails.plugins.springsecurity.kerberos package: PLUGIN_DIR/src/groovy/org/codehaus/groovy/grails/plugins/springsecurity/kerberos

If you're not using LDAP, here are the steps to remove that code:

• delete the org.codehaus.groovy.grails.plugins.springsecurity.ldap package: PLUGIN_DIR/src/groovy/org/codehaus/groovy/grails/plugins/springsecurity/ldap and PLUGIN_DIR/src/java/org/codehaus/groovy/grails/plugins/springsecurity/ldap
• delete these jars
  • spring-ldap-1.2.1.jar
  • spring-ldap-tiger-1.2.1.jar
• in LoginController.groovy
  • remove the config.useFacebook part in the auth() action

If you're not using CAS, here are the steps to remove that code:

• delete these jars
  • cas-client-core-3.1.1.jar
  • spring-security-cas-client-2.0.4.jar

Even if you don't use NTLM it's best to leave it in - the jars and code aren't large and it's more complicated to remove than just deleting.

In Eclipse or STS the steps to configure the classpath are:

• add PLUGIN_DIR/src/groovy as a source folder
• add PLUGIN_DIR/src/java as a source folder
• add PLUGIN_DIR/grails-app/services as a source folder
• add PLUGIN_DIR/lib/spring-security-core-2.0.4.jar
• add PLUGIN_DIR/lib/spring-security-core-tiger-2.0.4.jar
• add PLUGIN_DIR/lib/spring-security-ntlm-2.0.4.jar
• add PLUGIN_DIR/lib/jcifs-1.2.25.jar

Having done all that, let's create a secured controller to test annotations:

and add the import for the annotation, and annotate at the class level that you must be an admin to access this controller:

The controller has a redirect from the default action and a second action so we can test that all methods inherit the class-level annotation.

Hitting this controller will require a login, so lets add code to BootStrap to create a user:

Start the app using

and open http://localhost:8080/springone2gx/secure/ in a browser and it should prompt you to login - use the username and password from the user created in BootStrap.

After successful login it'll redirect to http://localhost:8080/springone2gx/secure/foo - verify that http://localhost:8080/springone2gx/secure/bar is also secured by going to that in your browser.

The 'secure' controller blocks access, but anyone can access the role or user controller - open http://localhost:8080/springone2gx/user/list to verify that. So let's finish locking down the app.

Add the same annotation to UserController and RoleController that you added to SecureController:

Up to now we've assumed that all access should be allowed unless it's explicitly blocked. This is appropriate for many applications, but you might want to take the pessimistic approach of denying access unless it's allowed. That's simple to do.

Set controllerAnnotationsRejectIfNoRule to true in grails-app/conf/SecurityConfig.groovy, and since we can't annotate CSS/JavaScript/images/etc., we'll need to allow access to those using the controllerAnnotationStaticRules property:

Users won't be able to log in now, since you're now allowing access to LoginController. That's easy to do: add an annotation:

IS_AUTHENTICATED_ANONYMOUSLY means that any access is allowed - "anonymous" logins as well as real logins. Do the same for LogoutController, and CaptchaController and RegisterController if you're using the registration features of the plugin.

Using this approach, new controllers will be inaccessible until you annotate them. If you need the pessimistic approach, this is preferred to the alternative that controllers accidentally allow full access because you forgot to lock them down.

You can download a finished application based on this discussion here

The User/Role many-to-many relationship in the Grails Spring Security plugin is modeled using the standard GORM mapping approach, i.e. using hasMany and belongsTo. As I pointed out here this is a performance concern when you have a large number of users, since granting a new user a popular role (e.g. ROLE_USER) will cause all other users with that role to be loaded from the database.

To fix this in the current plugin would be a breaking change, but I'm planning on creating a new plugin that will use Spring Security 3 once it's released, so I thought I'd write up some notes on how to fix the many-to-many mapping for current users. It's only a few steps.

The first is to map the join table, so you'll need to create a UserRole domain class (I'm assuming that your person class is named User and your authority class is named Role - translate as appropriate):

Some notes on this class:

• it has to implement Serializable since it's a Hibernate composite primary key class
• the mapping block settings ensure that the table DDL is the same as that for the autogenerated join table, so you won't need to update your database
• the hashCode and equals methods are just suggestions; feel free to re-implement

Next remove static hasMany = [people: User] from Role and static hasMany = [authorities: Role] and static belongsTo = Role from User.

While we don't want to map the Role's User collection, we still need convenient access to the User's roles, so next add a utility method to User to mimic what we removed when deleting the hasMany. While we're here let's add a hasRole method:

If you're using the plugin-generated CRUD pages (created via grails generate-manager) you'll want to remove the User listings from views/role/show.gsp:

and views/role/edit.gsp:

Then in RegisterController.groovy change

to

and finally in UserController.groovy, change (in two places)

to

and

to

And that's it. You shouldn't need to make any database changes, since the new code will map to the existing tables just like the old code. If you've used the addToPeople and removeFromPeople dynamic many-to-many methods elsewhere in your code you'll need to convert those to use the UserRole helper methods, but otherwise the impact should be fairly minor.