• Role-based access control
• Database-based authentication (passwords stored in database)
• Simple to use
• Good documentation
• Ability to model permissions for finer granularity authorization than role (nice to have)
• Captcha support (nice to have)
• OpenID support (nice to have)
• Facebook Connect support (nice to have)

From browsing the list of Grails plugins, it looks like there are two that fit the bill, each based on well-established Java security frameworks. Here are my notes on each:

JSecurity plugin

• Based on JSecurity framework (now Apache Ki)
• API includes classes for user, roles, and permissions.
• Support for role and permission-based authorization, which I prefer to use
• Quick Start Guide has example of users and roles being created
• Access control is declaratively configured, pointing to the controller & action
• AuthController is responsible for common auth functions (logout, login) & login page-
• Different authentication schemes (e.g. LDAP, database based auth) supported via realms
• Supports database-based authentication (passwords stored in database)
• OpenID support : not directly supported in JSecurity yet, but people have gotten it working at Grails level by integrating with OpenID plugin
• Documentation looks good, but not as much available as the Spring Security plugin

Spring Security plugin

• Based on Spring Security (Acegi security) framework
• Supports database-based authentication (passwords stored in database)
• Supports OpenID and Facebook connect for authentication
• Also supports LDAP, Kerberos, CAS, NTLM for authentication
• Support for role-based authorization
• User and Role Groovy classes are generated. These may be customized after generation (e.g. to add attributes).
• Generates a simple registration page with password confirmation and CAPTCHA support
• Pages and actions security mappings (which pages/actions should be access controlled) can be stored in database, as annotations in the Controller, or using the standard URL string mapping supported by Spring security
• Good documentation

Both plugins look very capable and meet my core requirements. Support for OpenID is a big plus for me so I went with Spring Security. I’ve been using it for about a week now. I may jot down some notes on it in a future post.

BTW, this to me is one of the huge advantages of dynamic language frameworks on the JVM; the ability to tap into mature, very full-featured existing Java frameworks, libraries, and drivers. This is particularly true for Grails, since it so heavily leverages existing frameworks (e.g. Spring, Hibernate).

The main obstacle I saw was that exception messages and stack traces were not descriptive of the root problem. It wasn’t that the error messages were poorly written, but the error that was reported wasn’t near the root cause of the problem. The reported error was a far-removed side effect of the actual problem. If you had messed up the definition of your GORM domain class, the application may start up fine and complain that some dynamic save method was undefined for the domain class when you tried to use it. You then had to do a good deal of trial and error until you isolated what change caused the problem. Having a robust set of unit tests for your application helped, but it still took a while to diagnose the problem.

I’ve been using Grails 1.1 betas lately, and it looks like the error reporting has gotten much better. When I’ve gotten errors, it was usually pretty clear what the cause was.

Officially, IDEA only supports Grails 1.0, but it’s working fine for me with some tweaks. Here’s what I did:

• Created the Grails 1.1 project outside of IDEA, using the grails command (not MVN plugin)
• Redefine GROOVY and GRAILS global libraries in IDEA to point to the latest versions of each
• Imported the existing Grails project into IDEA
• After installing some Grails plugins (specifically, the google-chart plugin), I found that they weren’t on the classpath and the grails launcher no longer worked. Apparently Grails 1.1 moved where the plugins are stored and IDEA hasn’t been updated for this yet. To get around it, I added <home dir>/.grails/1.1/projects/<my project> to the module’s content root for my project, and added the plugin’s source directory (plugins/google-chart-0.4.8/src/groovy in my case) as a source folder within the added content root.

The grails app launcher is working for me, and I’m not getting the compile problems I was getting before.