Page History

...

What's going on in security.xml

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 ...

/**=channelProcessingFilter,httpSessionContextIntegrationFilter,remoteUserFilter,authenticationProcessin
gFilter,rememberMeProcessingFilter,anonymousProcessingFilter,exceptionTranslation
Filter,filterInvocationInterceptor

Each item in the chain will be processed sequentially and be given its chance to affect the workflow. Here's what the various filters mean ...

channelProcessingFilter

The ChannelProcessingFilter is responsible for doing scheme enforcement. This means that if a request is supposed to be done over a specific scheme (http/https) and the current request is not using the right scheme, it will force the client to be redirected to the right scheme. We mainly use this to force https for logins and a few other things.

httpSessionContextIntegrationFilter

The HttpSessionContextIntegrationFilter is what Acegi uses to make sure a session is maintained across multiple requests. In Acegi the primary object that represents a client session is called a SessionContext and all other information about a session is available through that object. This filter is used to load/store the SessionContext object in the standard servlet HttpSession so that it is available between requests.

This filter must be early on in the chain.

remoteUserFilter

The SecurityContextHolderAwareRequestFilter, which we call the remoteUserFilter, is a filter which wraps the servlet request object using a custom Acegi request wrapper so that various authentication/authorization methods of the request are properly implemented to work with Acegi. This is how request.getUserPrincipal() and request.isUserInRole() are made to work.

authenticationProcessingFilter

The AuthenticationProcessingFilter is the filter which actual checks for submitted login credentials and uses them to attempt to setup a client session by creating an Authorization object. The Authorization object is Acegi's way of indicating a client session is authentic and it holds information about authentic client.

In a nutshell what this filter does is it looks for requests posted to the filterProcessesUrl, /roller_j_security_check in our case, and for those requests it uses the submitted information to try and login the client. Much of the work is delegated to supporting beans such as the authenticationManager to do the actual authentication bit, but in the end it is this filter which makes login possible.

rememberMeProcessingFilter

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.

...