In short, this release upgrades to Spring Security 2.0.5, and contains a fix for configurable support for session fixation attack prevention.

Although there are some high-level introductory/overview slides up front, the bulk of the presentation is a build-it-from-scratch session that shows how to use FlexBuilder to put together a simple Flex app (the obligatory Twitter client).  It also shows how to work with a library project, and then goes on to create an AIR application using a shared component.  Towards the end, I’m firing up FlexMonkey to show how to test the Flex app we built and how to generate the scripts and AS3 code needed to integrate those tests in a CI build.

The slides are here. There are not that many, but there are some useful links on the last slide.

The Flex projects built during the presentation are here.

Please give it a whirl and let me know if you have any comments and/or questions!

Docs and release notes are here: http://www.grails.org/Stark+Security+Plugin

• allow for simple listening/handling of Spring Security authentication/authorization events
• allow the application to participate/intercept at various points of the Spring Security filter chain.
• various defect fixes

Updated docs and release details are available here: http://www.grails.org/Stark+Security+Plugin

• Enable arbitrary password encoding algorithms, on a DAO provider basis
• Allow for tweaks to authorization mappings in StarkSecurityConfig.groovy without app restart.
• Let user install the plugin but defer configuration (this used to result in exceptions on app startup).

The 0.2.2 bug-fix release solves an issue with custom url mappings not responding to the authorization mappings in controllers. With this fix, any custom mappings in UrlMappings will resolve to the authorization mappings of the eventual controller target.

Documentation (including upgrade instructions, release notes, etc.) is here: http://www.grails.org/Stark+Security+Plugin

As always, comments/questions/suggestions are much appreciated!

• Lock-down or ‘pessimistic’ approach. Instead of leaving the web application open and relying on configured rules to lock down certain areas, the Stark Security plugin locks down everything by default. Developers open up access on a controller-method basis as they are coding the controllers.
• Authorization mappings by convention. The determination of which roles can access which URLs is declared by convention in every controller, right next to the eventual URL end-points (controller methods). This makes for very straight-forward implementation and maintenance of the security rules.

Version 0.1 is available by simply running this from within your Grails project:

grails install-plugin stark-security

Documentation is available at the Stark Security Plugin page at the Grails plugins web site.

To make a long story short, I have since upgraded the plugin to the latest version of SpringSecurity (2.0.4 at the time of writing). The plugin is available here as part of a demo application (just like in the previous post):

SpringSecurityGrailsPluginDemo.zip

Prior to doing this update, I reviewed the latest Grails plugins available for both JSecurity and Acegi (yes, it should be renamed ‘SpringSecurity’). Although they are now considerably easier to configure and do provide LDAP authentication alongside simple DAO authentication, they still lack some important aspects of web application security that I was attempting to address:

• Pessimistic authorization scheme. Default to no access for anybody to anything, open up holes as needed. This may not work for everybody, but my goal is to reduce the risk of leaving unintended content out there (given how easy it is to implement a Grails controller method).
• Ease of implementation. A developer should readily be able to configure a controller method to a certain security level at the time of feature implementation. While I believe security should be an implementation-time decision, it should NOT be an obstacle to rapid and agile development.
• Good maintainability. When Grails controllers are re-factored or removed, it should be obvious what changes need to be made from a security perspective. Changes in controller structure should not result in hours of tracing down security rules.

To get a better understanding of how my plugin addresses those concerns, please read the original post. None of the logic posted in that original article has changed, only the internals of the plugin itself to accommodate for the upgraded SpringSecurity libraries.

After reviewing some of the other MVC frameworks out there (PureMVC mostly), we decided to stick with Cairngorm but to expand its use to the full extent it was intended. In our mind, that meant to have Cairngorm events/commands handle all user gestures (unless they were trivial, component-local gestures like re-sorting a datagrid, etc.). This worked great, and we were pretty happy with the emerging structure of the application except for one thing: we didn’t like the ViewHelper/ViewLocator pieces. It seemed too cumbersome and overly structured for the simple task of having a command communicate with a view. We also didn’t like to control views from commands via the ModelLocator (as also suggested by the Cairngorm docs), as we had tried that in the earlier version and it quickly became a disastrous mess of spaghetti bindings that were incredibly hard to unravel, much less maintain.

To make this process simpler, we came up with a different approach: view facades. These facades are essentially ViewHelpers, but we eliminated the ViewLocator by making the facades singletons attached directly to the view. A sample makes this clearer. Consider a command GetBookDetails. We want this command to contact the server and get the details for a particular book. During this process, the view should show a progress or “loading…” view, to be switched out for the actual book details view when the loading is complete. That command could look like this:

    public class GetBookDetailsCommand implements ICommand {
 
        public function execute(event:CairngormEvent):void {
            var bookEvent:GetBookDetailsEvent = event as GetBookDetailsEvent;
 
            BookViewFacade.getInstance().showLoadingView();
 
            // Load the book details from the server here, using a custom HTTPServiceEvent of ours...
            var bookServiceEvent:HTTPServiceEvent = new HTTPServiceEvent('book_get', BookModelLocator.getInstance(), 'book', 'book');
            bookServiceEvent.params = {id: bookEvent.bookId}
            bookServiceEvent.addCommandStatusListener(onBookResult);
            bookServiceEvent.dispatch();
        }
 
        private function onBookResult(statusEvent:CommandStatusEvent):void {
            BookViewFacade.getInstance().showBookDetailsView();
        }    
    }

Notice the two calls to BookViewFacade, controlling the visible view in our BookView component. That component (BookView) would look something like this:

. . .    
    <view:BookViewFacade id="facade" bookView="{this}"/>
 
    <container:ViewStack id="viewStack" width="100%" resizeToContent="true">
 
        <container:HBox id="VIEW_LOADING" width="100%">
            <control:Label htmlText="Loading..."/>
        </container:HBox>
 
    	<container:VBox id="VIEW_BOOK_DETAILS" width="100%">
            <control:Label htmlText="{MainModelLocator.getInstance().book.title}"/>
            <control:Label htmlText="{MainModelLocator.getInstance().book.title}"/>
            . . .
    </container:ViewStack>
. . .

Notice the declaration of the view facade BookViewFacade, where the view references itself. The facade is a singleton, implemented along these lines:

    public class BookViewFacade {
 
        public var bookView:BookView;
        private static var instance:BookViewFacade;
 
        public function BookViewFacade():void {
            instance = this;    
        }
 
        public static function getInstance():BookViewFacade {
            return instance;
        }
 
        public function showLoadingView():void {
            bookView.viewStack.selectedChild = bookView.VIEW_LOADING;
        }
 
        public function showBookDetailsView():void {
            bookView.viewStack.selectedChild = bookView.VIEW_BOOK_DETAILS;
        }
 
    }

The view is thus abstracted from the commands, but can be readily manipulated by singleton-access to the view facade and its methods. You can then easily work with views from within the Cairngorm framework, without the need for maintaining ViewLocators, etc.

With the first version of the app, we quickly realized that a monolithic SWF soon becomes too large to load over not-so-fast internet connections. By modularizing the app, loading of content that is not immediately needed can be deferred until later. There is an excellent presentation/demo of what modules are and how to use them at Alex Harui’s blog.

To get around the complexities of modules and ApplicationDomains, we decided to simply load all modules into the top-level ApplicationDomain. We also wanted to handle deep-linking in a standard way across all modules. We use URLKit to do most of this work — there’s a detailed explanation of how URLKit works here.

We started by creating a base class that extends ModuleLoader. It looks something like this:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36

    public class ModuleLoaderBase extends ModuleLoader {
 
        protected var isReady:Boolean = false;
 
        public function ModuleLoaderBase() {
            super();
            applicationDomain = ApplicationDomain.currentDomain;
            this.addEventListener(ModuleEvent.READY, onReady);
        }
 
        protected function onReady(event:Event):void {
            isReady = true;
        } 
 
        /**
         * This function is called from ModuleBase when upon module creationComplete event.
         */
        public function onModuleCreationComplete():void {
            initializeDeepLinking();
            MainApplicationFacade.getInstance().appEnabledQueuePop(true);
        }
 
        /**
         * This is where sub-classes can implement deeplinking using urlKit.
         */
        protected function initializeDeepLinking():void {
        }
 
        /**
         *  Add a noCache parameter to the module URL to force the browser to reload the module.
         */
        public override function set url(u:String):void {
            super.url = u + "?nocache=" + new Date().time.toString();
        }
 
    }

Notice on line 7 how we’re pointing the application domain of the module loader to the current or top-level domain. So all modules we’re using simply load their class definitions into the top-level ApplicationDomain. We can do this as long as we’re not concerned with unloading modules. If that is a need, this strategy will not work and you’d have to implement a more complex solution (probably using a “shared classes” module as outlined in the presentation linked above).

Using this base class, we then create a new module loader class for each one of our modules. For instance, here’s one that loads a book details module:

<module:ModuleLoaderBase
    xmlns:url="http://www.allurent.com/2006/urlkit"
    xmlns:module="com.acme.core.module.*"     
    xmlns:mx="http://www.adobe.com/2006/mxml">
 
    <mx:Script>
        <![CDATA[
 
            import com.acme.module.IBookDetailsModule;
            import mx.binding.utils.BindingUtils;
 
            [Bindable] public var bookId:String;
            private var module:IBookDetailsModule;
 
            protected override function initializeDeepLinking(): void {
                module = this.child as IBookDetailsModule;
                mx.binding.utils.BindingUtils.bindProperty(module, "bookId", this,  "bookId");
                mx.binding.utils.BindingUtils.bindProperty(this, "bookId", module,  "bookId");
            }
 
 
        ]]>
    </mx:Script>
 
 
 
    <url:UrlRuleSet id="urls">
        <url:UrlValueRule id="valueRule" urlFormat="/*" sourceValue="bookId"/>
    </url:UrlRuleSet>      
 
</module:ModuleLoaderBase>

Notice the use of an interface (IBookDetailsInterface) to get a handle on the loaded module. This enables us to “talk” to the module without compiling it into the main application (the entire reason for going with modules in the first place). Also note the two-way binding of the bookId property into and out of the module. This enables us to set the bookId property on the module loader or the module, and the change will be reflected either way in the browser nav bar.

So now on to the actual module. First, we have a base class that all modules extend from:

    public class ModuleBase extends Module {
 
        public function ModuleBase() {
            super();
            this.addEventListener(FlexEvent.CREATION_COMPLETE, onCreationComplete);
        }
 
        private function onCreationComplete(event:Event): void {
            var loader:ModuleLoaderBase = ModuleLoaderBase(this.parent);
            loader.onModuleCreationComplete();
        }
    }
}

Really, the sole purpose of this base class is to call the onModuleCreationComplete function on the module loader base class. This so that our urlKit properties can be created at the appropriate time.

The sample BookDetailsModule then looks like this:

<module:ModuleBase
    xmlns:mx="http://www.adobe.com/2006/mxml"
    xmlns:module="com.acme.core.module.*"
    implements="com.acme.module.IBookDetailsModule">
 
    <mx:Script>
        <![CDATA[
 
            import com.acme.book.event.GetBookDetailsEvent;
 
            private var _bookId:String;
            [Bindable] 
            public function get bookId():String {
                return this._bookId;
            }
 
            public function set bookId(newValue:String):void {
                this._bookId = newValue;
                if (bookId) {
                    new GetBookDetailsEvent(bookId).dispatch();
                }
            }
 
        ]]>
    </mx:Script>
 
    <container:ViewStack id="viewStack" width="100%" resizeToContent="true">
 
        <container:HBox id="VIEW_LOADING" width="100%">
            <control:Label htmlText="Loading..."/>
        </container:HBox>
 
        <view:BookDetailsView id="VIEW_DETAILS" width="100%"/>
 
    </container:ViewStack>
 
</module:ModuleBase>

So when the module has loaded and receives a change in the bookId property, the module is responsible for the logic of going out to get the data (dispatches the GetBookDetailsEvent). All logic related to displaying book details is then contained in the module and is not loaded until explicitly referenced by the main app.

In the main application, the module can then be used like this:

. . .
        <container:ViewStack id="viewStack" resizeToContent="true" width="100%">
 
            <view:HomePageView id="VIEW_HOME_PAGE" label="home"/>
 
            <module:BookDetailsModuleLoader id="VIEW_BOOK_DETAILS" 
                url="BookDetailsModule.swf" label="bookDetails" 
                width="100%" height="100%"/>
. . .

In this case, when the VIEW_BOOK_DETAILS module loader is selected as the current child in the viewstack, the module is loaded. You can now use the urlKit features to load the details for a particular book (with id 12) by deep-linking your browser to:

http://myhost/myapp/#/bookDetails/12

Or you can reference the module via the module loader in code:

. . .
VIEW_BOOK_DETAILS.bookId = 12;
VIEW_BOOK_DETAILS.loadModule();
...

In real life, you’d probably also have a view facade or command that ends up setting the bookId property and selecting the VIEW_BOOK_DETAILS as the active view in the viewstack. That way, you can very simply load up the book details from code, even from another module.

Clearly, there’s a bunch more “meat” behind the real application than what is shown here, but hopefully this demonstrates a solution to working with modules and deep-linking. If not, please post comments with questions and I’ll follow up.

The standard Acegi plugin for Grails provides a basic implementation of the Acegi security framework for the Grails web stack.  It does a nice job of setting up a basic filter chain that can be rather cumbersome to establish from scratch.  It comes hard-wired with a simple DAO-based authentication provider, and includes the pieces needed to create a rudimentary security scheme for your Grails application.

But the standard plugin is not very flexible, and does not provide alternate means of authentication (such as LDAP).  It is also cumbersome to configure, and it is difficult to manage authorization mappings.  I also didn’t like the “optimistic” authorization scheme (anything not locked down is publicly available).  This article demonstrates a security plugin implementation for Grails that meets a higher level of security requirements.

Basic Acegi Security Concepts

Let’s first define some security terminology for the purposes of this discussion.  Specifically, there are two components of web security that will be discussed here — authentication and authorization:

• Authentication is the process of verifying a user’s identity, typically done using a simple username/password combination.  When a user is successfully authenticated, Acegi places an authentication token on the HTTP session.  This token contains some information about the authenticated user, including the list of “granted authorities” or “roles” that the user is endowed with.  The authentication token remains active for the life of the HTTP session, or until the user explicitly logs out.
• An authorization scheme determines which URLs or resources an authenticated user has access to.  For each HTTP request, Acegi compares the list of roles on the authentication token to the roles that are granted access to the target of the request.  If a match is not found, the user is denied access to the resource.

This sample plugin is set up with an AnonymousProcessingFilter, which means that an anonymous authentication token is placed on the session with the initial HTTP request.  This token is associated with only one, anonymous role.  This means the authorization scheme works for general access, by assigning that anonymous role to those resources that should be publicly available.

Higher-level Requirements

The standard Acegi plugin for Grails does not provide enough flexibility, configurability, or maintainability for a non-trivial production environment.  These are the most important pieces I felt were missing:

• Flexible configuration.  It should be easy to set up, and to get a quick overview of the configuration settings.  Also, environment-specific configuration is a must.
• Multiple authentication providers.  Provide LDAP authentication in addition to the standard DAO implementation.
• Pessimistic authorization scheme.  Default to no access for anybody to anything, open up holes as needed.  This may not work for everybody, but my goal is to reduce the risk of leaving unintended content out there (given how easy it is to implement a Grails controller method).
• Ease of implementation.  A developer should readily be able to configure a controller method to a certain security level at the time of feature implementation.  While I believe security should be an implementation-time decision, it should NOT be an obstacle to rapid and agile development.
• Good maintainability.  When Grails controllers are re-factored or removed, it should be obvious what changes need to be made from a security perspective.   Changes in controller structure should not result in hours of tracing down security rules.

A Solution

I wanted a security plugin that would perform those two basic tasks of authentication and authorization, while conforming to the five major requirements outlined above.  The simplest way to explain the implementation is to walk through the various pieces and their usage step by step in a sample Grails application.

Install the Demo

Start by expanding the demo zip file in a directory of your choosing.  All further project-related paths in this article will assume that you are currently in that top-level install directory.

Notice how there are two grails projects: demo and demo-acegi.  The former is the sample application, while the latter is the acegi plugin.

You will need Grails installed to be able to run the demo, but that’s not needed for the purposes of this discussion.

Configuration

The configuration of the acegi plugin is governed by the application that uses it.  So we’ll find the acegi settings for our demo application in the application’s standard configuration file (acegi-plugin-demo/demo/grails-app/conf/Config.groovy).

There are three sets of configuration variables:  The first three variables set up some of the URLs that Acegi needs under various conditions.  The second set of variables sets up the DAO authentication providers, while the last set configures the LDAP authentication providers:

acegi.loginFormUrl='/access/notAuthorized'
acegi.logoutUrl='/access/logout'
acegi.sessionExpiredUrl='/access/sessionExpired'
// These are the DAO user details services
acegi.daoServices=[
    'DemoDAO': [
        daoService: 'userLookupService',
        processesUrl: '/j_acegi_security_check',
        alwaysUseDefaultTargetUrl: false,
        authenticationSuccessUrl: '/loginCredentials/list',
        authenticationFailureUrl: '/access/authenticationFailure'
    ]
]
// These are the LDAP authentication services
acegi.ldapServices=[
    'DemoLDAP': [
        url: 'ldap://your.ldap.url/dc=mycorp,dc=local',
        managerDn: 'CN=Some Title,CN=SomeGroup,DC=mycorp,DC=local',
        managerPassword: 'mypassword',
        userSearchBase: '',
        groupsPath: 'OU=Groups,OU=Production',
        processesUrl: '/j_acegi_security_check_ldap',
        alwaysUseDefaultTargetUrl: false,
        authenticationSuccessUrl: '/loginCredentials/list',
        authenticationFailureUrl: '/access/authenticationFailure'
    ]
]

As the configurations for the plugin are specified in the standard Config.groovy file, you can obviously make the settings environment-dependent in the standard fashion by placing them in the appropriate environment section of that file.

Notice that most of the configuration settings are URLs, and most of those point to various methods on the AccessController — this is a controller in the application, not the plugin. That means the application has full control of the various URLs pointed to by Acegi.

DAO Authentication

Under Acegi, DAO authentication is based on the DaoAuthenticationProvider class.  In essence, this provider users a ’service’ to look up a ‘user’ to be authenticated.  The service implements the UserDetailsService interface, which brings back an implementation of UserDetails to represent the user.  There are comments in the Acegi API documentation to explain these classes/interfaces in detail.

The DAO authentication provider used in our plugin is more or less the same as used by the standard Acegi plugin for Grails, except our plugin makes it more configurable.  The actual domain classes and the UserDetailsService are provided by the application, not the plugin.  Since Acegi deals with interfaces and doesn’t need to know anything about the back-end implementation of these items, this provides maximum flexibility.

In the configuration settings for the demo DAO authentication provider, notice the daoService variable.  Its value is set to userLookupService, which is a Spring bean reference to a Grails service declared by the demo application.

That service looks like this:

import org.acegisecurity.userdetails.UserDetails
import org.acegisecurity.userdetails.UsernameNotFoundException
import org.springframework.dao.DataAccessException
import org.acegisecurity.userdetails.UserDetailsService
 
class UserLookupService implements UserDetailsService {
 
    def UserDetails loadUserByUsername(String userName) throws UsernameNotFoundException, DataAccessException {
        User user = User.findByUsername(userName)
        if (user) {
            log.debug("User found for ${userName}: " + user)
            return user
        }
        log.info("User NOT found: ${userName}")
        throw new UsernameNotFoundException("User not found.");
    }
 
}

This is about as basic an implementation of the Acegi UserDetailsService as it gets.   It simply looks up a UserDetails object based on the username passed in.  The UserDetails object is used by Acegi to create the authentication token mentioned above.

In the demo application, the UserDetails interface is implemented by the Grails domain class User, which has a one-to-many relationship to Role.  Thus, these two Grails domain classes, User and Role, form the basis for the Acegi DAO authentication token in our demo application.  These domain classes are found in the conventional Grails directory, acegi-plugin-demo/demo/grails-app/domain.

In summary, the implementation of the DAO service is completely determined by the application, not the plugin.  As long as a valid UserDetails object is returned, the actual implementation of the daoService bean is irrelevant.

LDAP Authentication

Our plugin’s implementation of an LDAP authentication service is merely offering a convenient way to configure a standard Acegi LdapAuthenticationProvider.  There are no additional pieces required by the application beyond the configuration settings as provided in acegi-plugin-demo/demo/conf/Config.groovy.

One thing to keep in mind is that the group names configured in the LDAP system must match the role names used in your application. Acegi inserts the text ‘ROLE_’ to at the beginning of each group name retrieved from LDAP and forces the rest of the group name text to all upper-case. For instance, if you have a group in your LDAP system named ‘SuperUser’, the role in your authorization mappings should read ‘ROLE_SUPERUSER’.

Authorization

In order to reach the goals of easy development and maintainability, it is essential to standardize the definition of url-to-authorization mappings.  In other words, use a convention to determine which roles are permitted to access a URL.

In the standard acegi plugin, these authorization mappings are established by manually entering rules in a database table.  That table is read by the plugin at start-up, and all authorization decisions are based on those rules.  The authorization mappings must be configured, in no direct relation to the resources they govern.

I found this to be cumbersome and error-prone – a developer working on a controller method had to enter database rows to govern the security access to the code she was working on.  To determine the access level of a particular controller’s methods, you had to do a rather complex database query.  When the rules got more fine-grained, it became very hard to determine which rule actually applied to which resource.

It would be better to have the authorization mappings defined in the controllers themselves.  The access-level of a URL would then be directly determined right next to the URL end-point that it governs, in a conventional location.

As an example, let’s examine the controller acegi-plugin-demo/demo/grails-app/controller/UserController.groovy in the demo application:

class UserController {
 
    static authorizations = [
        index: [Role.ADMIN_USER],
        list: [Role.ADMIN_USER],
        show: [Role.ADMIN_USER],
        create: [Role.ADMIN_USER],
        save: [Role.ADMIN_USER],
        edit: [Role.ADMIN_USER],
        update: [Role.ADMIN_USER]
    ]
. . .

The controller declares a simple map with its methods as keys and a list of roles as values.  In this case, only users with the ADMIN_USER role are granted access to these methods.

There are some URLs in a Grails application that do not correspond to a controller method.   These special-case mappings must be mapped somewhere else. It seemed the most logical place for that was in the UrlMappings class, as this class contains other mappings that direct traffic around the application.

As an example, let’s examine the demo application’s acegi-plugin-demo/demo/conf/UrlMappings.groovy:

class UrlMappings {
 
    static authorizations = [
        '/': Role.ALL_ROLES,
        '/js/**': Role.ALL_ROLES,
        '/css/**': Role.ALL_ROLES,
        '/images/**': Role.ALL_ROLES,
        '/logout': Role.ALL_ROLES
    ]
. . .

These mappings open up access for URLs in a path-based manner, including wild-cards (as supported by Spring’s AntPathMatcher).  The access paths are the keys and lists of roles are the values.

The authorization mappings declared in UrlMappings are fairly static, and should not be modified by developers.  While you could easily put sweeping rules around controllers in UrlMappings, that would defeat the purpose of our convention-based scheme that has the mappings in the controllers themselves.

In summary, authorization mappings are determined in two conventional places:

• Controllers. As almost every URI into the Grails application is through a controller method, this is the best place to maintain the authorization mappings.
• UrlMappings. Provides a way to establish authorization rules for urls or paths that are not tied to a controller or its methods, e.g. /css/** or /js/**.

Running the Demo

To start up the application, go to the demo application directory and start grails:

cd acegi-plugin-demo/demo
grails run-app

As the demo application uses a simple HQL database, it creates some bootstrap data in acegi-plugin-demo/demo/grails-app/conf/BootStrap.groovy to create a role and an initial admin user:

// Create a role for the demo application
new Role(authority: 'ROLE_ADMIN_USER', description: 'Administrative User').save()
 
// Create an admin user, and add the admin user role
def user = new User(username: 'adminUser', password: 'password'.encodeAsPassword())
user.save()
user.addToRoles(Role.findByAuthority('ROLE_ADMIN_USER'))
user.save()

Now point your browser to the home page of the application: http://localhost:8080/demo.

You will see two controllers listed — UserController and AccessController. Try clicking UserController. Notice how you are re-directed to the login page. This is Acegi re-directing you because you haven’t authenticated yet. Login using adminUser/password (as set up in the bootstrap data above), and you will be taken to the default action for the UserController. This demonstrates how the simple authorizations mappings we set up in UserController above determine how to allow access to controller methods.

Next Steps

This article covers the main goals and uses of an alternative Acegi plugin for Grails. It does not go into the details of the plugin implementation, nor does it do a terribly good job of explaining the meaning of the configurable URLs that are used by the Acegi decision process. It is my hope that the code/examples are self-documenting, but I can understand if things are unclear — especially if you are not already familiar with the workings of the Acegi framework.

This plugin can also be used with a finer-grained authorization scheme that associates permissions to roles. This allows an application to have fairly coarse-grained roles that rarely change, while finer-grained permissions maintained by the application are directly linked to access privileges on a very low level (like which buttons are enabled on a particular screen, etc.). But this is a topic for another post/article, so as not to confuse you further at this point.

Please post your comments/suggestions, and I will follow up with more posts as needed. I am planning a post on the inner workings of the plugin, but right now I’m spent…