Securing a Grails Application with Acegi Security

Table of Contents

Introduction

This article discusses the integration of the grails-acegi plugin with a sample Grails application. As part of this integration, there are three major components which will be used – Groovy, Grails and Acegi Security.

Groovy is a powerful, high level language for the Java platform which compiles down to Java bytecode. It is similar in concept to Ruby or Python, however it is tightly integrated with the Java platform. This allows you to utilize a powerful and concise coding syntax while at the same time allowing you to stay on the JVM and protect your investment in the existing Java platform and surrounding libraries.

Grails is a full stack framework implemented in Groovy. Grails attempts to solve many pieces of the web development puzzle through both the Grails core technology and associated plug-ins. Out-of-the-box capabilities include:

• An Object/Relational Mapping (ORM) layer built on Hibernate
• An expressive view technology called Groovy Server Pages (GSP)
• A controller layer built on Spring MVC
• A command line scripting environment built on Gant, a Groovy-based version of Ant
• An embedded Jetty container which is configured for on-the-fly reloading of resources
• Dependency injection via the built-in Spring container
• Support for internationalization (i18n) built through Spring's MessageSource API
• A transactional service layer which utilizes Spring transaction management
• Extensive use of Domain-Specific Languages (DSLs)

Acegi Security is a powerful, flexible security solution for enterprise software, with a particular emphasis on applications that use Spring. Acegi provides comprehensive authentication, authorization, instance-based access control, channel security and human user detection capabilities.

This article assumes that you have completed the Grails tutorial found in Getting Started with Grails by Jason Rudolph, and have implemented the RaceTrack sample application. The grails-acegi plugin will then be integrated with RaceTrack to provide security for your application. Utilizing the grails-acegi plugin avoids the overhead of having to implement Grails interceptors in your application, provides more flexibility than interceptors, and also saves reimplementing your own security system by leveraging Acegi.

Setting up the RaceTrack sample application

First, you will need to download Grails 1.0, the grails-acegi-0.2 plugin and Java SE JDK 5.0 or greater.

At this point, you are assumed to have implemented most of the RaceTrack application as described in Getting Started with Grails. However, you do not have to complete the entire tutorial in order to test the grails-acegi plugin – all which is required are the domain classes and controllers, and scaffolding of the controllers is good enough for testing.

Figure 1 – Directory structure after creating the racetrack application

Your RaceTrack application directory should look like the one shown in Figure 1 above. Now, open up the \grails-app\domain folder:

Figure 2 – domain classes directory

As you can see in Figure 2, the "domain" directory only contains 2 domain classes: Race and Registration. Now, open up the \grails-app\controllers folder and confirm that it has a controller for each domain class as shown in Figure 3 below:

Figure 3 – Controllers directory

These controllers can be empty, scaffold controllers, e.g.:

  class RaceController { def scaffold = Race }
 
  class RegistrationController { def scaffold = Registration }

This is sufficient to get the application up and running. After you start the RaceTrack application, you should be able to see the 2 controllers you created in the controller list as in Figure 4 below:

Figure 4 – Index page before Grails-Acegi Plugin

Installing the Grails Acegi plugin

Next is the installation of the grails-acegi plugin so that the RaceTrack take advantage of the role-based security this plugin provides. In the command prompt , navigate to "racetrack" directory and run this command:

grails install-plugin [path-to]/grails-acegi-0.2.zip 

This command creates a plugin directory under the "racetrack" directory as in Figure 5 below:

Figure 5 – plugins directory created after installing the plugin

Creating the Acegi Security components

The next step is to create domain classes that will represent User Accounts and Roles. To begin this process, run the following command:

grails create-auth-domains AuthUser Role

This will create two domain classes (AuthUser and Role), set up the AcegiConfig class, and create the Login and Logout controllers. The AuthUser domain class will represent your users, so for every new user will create a new record in the Auth_User table. The Role domain class will represent security roles that every user is allowed to have – Roles will be assigned to AuthUsers. Both of these classes are shown in Figure 6 below.

The AcegiConfig class (Figure 7) defines the security configuration for your application. It contains the names of the user domain class (in this case AuthUser) and the role domain class (in this case Role), whether to use dynamic vs. static secured urls, and how to setup email alerts (turns them off or on).

Figure 6 – AuthUser.groovy, Role.groovy and Requestmap.groovy (used in AcegiConfig)

Figure 7 – AcegiConfig.groovy created

In order to create new AuthUsers, create new Roles and assign Roles to AuthUsers, we will have to run two commands. One will generate the CRUD controls for domains:

grails generate-manager

and the second to generate registration for controllers and domains:

grails generate-registration

These commands give the user the ability to register and create their username and password, and the default security role will be assigned to that user. The set of controllers generated can be seen in Figure 8 below:

Figure 8 – CRUD controllers (Login and Logout controllers are created when the Auth and Role domains are created)

Figure 9 – Controllers available after grails-acegi-plugin installation

Go to the RaceTrack homepage – it should look similar to Figure 9 above.

Configuring Acegi Security to secure the application

We will now create a User role and a Manager role – to do this, first click on RoleController, and then enter a Role Name of ‘user' and some sort of role description (Figure 10). Note that the RoleController will take care of converting ‘user' to ‘ROLE_USER', which is what it is called in the database and by Acegi's configuration. Repeat the same steps to create a manager role.

Figure 10 – Creating a user role

Go back to the home page, and click on UserController. Now, create a user with the ‘user' role, and another user with a ‘manager' role, as in Figure 11 below:

Figure 11 – Create a standard user, enable the account and assign the 'user' role

Our Roles and Users are now sufficiently configured, so the next step is securing the RaceTrack application. There are two ways to how you can secure your URLs: One is dynamically via RequestmapController, and the other is through editing the AcegiConfig.groovy file directly. The dynamic configuration is the recommended choice, so we will proceed with that.

Before we secure the application, we need to think about the access rules that should be present in the application. A manager is allowed read/write access to any page in the application, which means:

• /race/*
• /registration/*

A user is allowed read-only access to some of the pages, including:

• /race/list/*
• /race/show/*
• /registration/list/*
• /registration/show/*

These rules now need to be translated into entries in the Acegi request map using the RequestmapController. From the RaceTrack homepage, click on RequestmapController, and go to the ‘create a new requestmap' page. In the URL field enter "/race/**", and in the Role field enter "manager" (Figure 12) – this will create a rule which allows any user with the manager role to access all URLs under /race. Do the same thing for registration (URL: /registration/**).

Figure 12 – Manager access rules

As a note, a good practice is to grant all user rights to the manager role as well. Next the access rules for the user role will be created -- in the URL field enter "/race/list/**", and in the Role field enter "user, manager" (Figure 13 - note that roles are separated with a comma). This will create an access rule which allows both users and managers to access the race list page. Note that you will needed to specify both roles -- if you only assign this URL to the user role, it will override the previous rule for manager and will only allow the user role to access the page. Repeat the previous step for the rest of the rules defined previously – this will create all of the access rules for the race and registration pages.

Figure 13 – Creating rule for /race/list/** page – give access to users and managers

Testing

From the RaceTrack homepage, click on either RaceController or RegistrationController (the controllers for the views we secured). You will now notice that you have been automatically redirected to the Login page. If you first log in as a user with the manager role, notice that you will be able to view, create, update and delete anything on the race and registration pages.

Figure 14 – Logging in as a user

Return to the RaceTrack homepage and click on the LogoutController -- this will invalidate your user session and log you out. Click on LoginController again, but this time log in as a user with the user role.If you then go to the /race/list subpage (either by going directly to http://localhost:8080/racetrack/race/list or by navigating through the controller interface), you should be able to see the race/list view (Figure 15).

Remember that the access rules allow only managers to create new records, and users can only read data through the List and Show views – this means that if you try to click on New Race (http://localhost:8080/racetrack/race/create) while logged in as a user with the user role, Acegi will prevent you from navigating to that page, which prevents creation of a new record.

How does this work? Recall that we granted access to /race/* to a manager, but only granted access to /race/list/* and /race/show/* to a user. When a user with the 'user' role attempts to access the /race/create page, Acegi looks at the set of roles for the user and sees that they only have the 'user' role – since our Request map said that the user must have the 'manager' role to be granted access to this page, permission to access the page is denied.

As a side note, in a real application you will probably want to display a better error page than the default one (Figure 16).

Figure 15 – Race List view

Figure 16 – Access denied error page

Congratulations – you now have a fully secured instance of the RaceTrack application!