Page History

...

What's going on in security.xml

To configure Acegi to protect our URLs and to authenticate against the Roller user and role tables, we create a twisty maze of nested Java beans strung together by XML in the Acegi configuration file security.xml. You'll have to understand a bit about Spring and spend some time reading the Acegi Javadocs before you can write one yourself. I'll explain what Roller's does at a high-level.

filterChainProxy

The first thing you must understand about Acegi is that it uses its own filterChainProxy to define the series of events that are going to take place as part of the Acegi authentication/authorization workflow. So to add/modify/remove any functionality you must first make adjust the filterChainProxy, which is the first bean listed in the security.xml. In that bean you will see line like this which sets the chain we use ...

...

The RememberMeProcessingFilter is how we allow for "remembered" sessions.

anonymousProcessingFilter

exceptionTranslationFilter

filterInvocationInterceptor

Acegi's filter, which gets called first for each incoming request, checks to see if the request is authenticated. If it is, then Acegi wraps the incoming HttpServletRequest object to ensure that request.isUserInRole() and request.getUserPrincipal() return the right values. If not, then Acegi redirects the user to the login page and then back to the originally requested page on successful login or to the login error page on failure.

To configure Acegi to protect our URLs and to authenticate against the Roller user and role tables, we create a twisty maze of nested Java beans strung together by XML in the Acegi configuration file security.xml. You'll have to understand a bit about Spring and spend some time reading the Acegi Javadocs before you can write one yourself. I'll explain what Roller's does at a high-level.

When this filter is reached, if Acegi does not already have a valid Authentication for the client's session then it consults any configured rememberMeServices which are given a chance to attempt an "auto-login". This is basically the same thing as an SSO login. Normally you would do this by looking for a special cookie and value which you can use to identify the client as being authentic, then use that information to create and Authentication object.

In Roller's case this is done via one of Acegi's stock remember me tools which uses a hashed cookie to mark a session that can be "remembered".

anonymousProcessingFilter

The AnonymousProcessingFilter is meant to be the last filter in the authentication phase of the Acegi workflow. All it does is checks if the client session has a valid Authentication and if not it grants a simple anonymous Authentication. This is just Acegi's way of marking the client as officially anonymous.

exceptionTranslationFilter

The ExceptionTranslationFilter is used to translate exceptions into actions. We don't really use this much, but it is used to translate a failed authentication exception from the AuthenticationProcessingFilter into an action which sends the client to the "login failed" page. So it's looking for exceptions that happened earlier in the workflow and translates them into some kind of action if it finds them.

filterInvocationInterceptor

The FilterSecurityInterceptor is the filter which handles the authorization part of the Acegi security model. To define the URLs to be protected and the roles required for each, we configure a FilterSecurityInterceptor with the rules listed below in security.xml. The rules say that most URL patterns require either the admin or editor role, but the /roller-ui/admin and /rewrite-status URLs are only for admin users.

    /roller-ui/login-redirect**=admin,editor
    /roller-ui/profile**=admin,editor
    /roller-ui/createWeblog**=admin,editor
    /roller-ui/menu**=admin,editor
    /roller-ui/authoring/**=admin,editor
    /roller-ui/admin/**=admin
    /rewrite-status*=admin

As you would expect, this is the last filter in the chain because if a client gets past here then we assume they are authorized to access whatever they are requesting.

Acegi authentication providers

To setup Acegi to authenticate against the Roller database, we configure a Acegi ProviderManager, which has a Acegi DaoAuthenticationProvider, which has a RollerUserDetailsService, a Roller provided class that creates an Acegi UserDetails object by reading from the Roller database. That's how Acegi gets user and role information from Roller. And we configure various other beans to tell Acegi that the Roller login page is at URL /roller-ui/login.rol, the login error page is /roller-ui/login.rol?error=true and to configure Acegi's Remember Me feature.

...