Page History

...

You can check the Acegi documentation for detail about what jars to add. Let's talk about the configuration files, but first, a word about users and roles in Roller. In Roller, we have two global roles for users: 'admin' for the System Administrators who maintain the site and 'editor' for bloggers who login to blog. We use our URL structure to organize the Roller UI into sections for admin users and sections for editors. We store usernames and passwords in one database table and user roles in another. We rely on Acegi to protect the URLs we want to be protected and to authenticate users against our user tables.

What's going on in web.xml

First we add the Acegi Servlet Filter to Roller's web.xml because that's how Acegi works its magic. All of Acegi's functionality is then determined by the security.xml file described below. By default the Acegi filter is mapped to /* which means that it applies to all requests to the application.

We also use a Context Listener so we can programmatically initialize parts of Acegi. Here's why. It's great that Acegi is so flexible and you can do so much with security.xml, but in Roller we want our users to have to edit at most one and only one configuration file to get up and running. We want that file to be a simple name and value properties file and certainly not a complicated XML file that references beans defined in some Java API. So, for example, if you want to enable or disable any of the features below, you edit properties in your roller-custom.properties file and Roller uses those property values to initialize Acegi programmatically, i.e. by calling the Acegi Java API directly.

• Remember Me: allows users to say logged-in for two weeks or until they explicitly logout
• Force Secure Login: force HTTPS for login and password editing pages, HTTP for everything else 1
• Encrypted Passwords: turn off password encryption

Those features are a benefit of using Acegi instead of plain-old Servlet Authentication. With Servlet Authentication, we'd have to implement those features in Roller and some would be impossible because there is no way to dynamically configure authentication through the Servlet API.

For most Roller setups you'll never have to touch security.xml and you can do everything through your roller-custom.properties file, but for more advanced configurations like LDAP or SSO you will probably need to understand how to deal with Acegi and security.xml.

What's going on in security.xml

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.

...

The RollerUserDetailsService uses Roller's database layer to fetch user details. So, we don't have to ask our users to go through the tedious and error prone process of seting up a JDBC Realm as we would have had to do if we were using plain old Servlet Authentication.

What's going on in web.xml

We add the Acegi Servlet Filter to Roller's web.xml because that's how Acegi works its magic. 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.

We also need a Context Listener so we can programmatically initialize parts of Acegi. Here's why. It's great that Acegi is so flexible and you can do so much with security.xml, but in Roller we want our users to have to edit at most one and only one configuration file to get up and running. We want that file to be a simple name and value properties file and certainly not a complicated XML file that references beans defined in some Java API. So, for example, if you want to enable or disable any of the features below, you edit properties in your roller-custom.properties file and Roller uses those property values to initialize Acegi programmatically, i.e. by calling the Acegi Java API directly.

• Remember Me: allows users to say logged-in for two weeks or until they explicitly logout
• Force Secure Login: force HTTPS for login and password editing pages, HTTP for everything else 1
• Encrypted Passwords: turn off password encryption

Those features are a benefit of using Acegi instead of plain-old Servlet Authentication. With Servlet Authentication, we'd have to implement those features in Roller and some would be impossible because there is no way to dynamically configure authenticaition through the Servlet API.

For most Roller setups you'll never have to touch security.xml and you can do everything through your roller-custom.properties file, but for more advanced configurations like LDAP or SSO you will probably need to understand how to deal with Acegi and security.xml.

The end

1 security experts frown at Force Secure Login, but Roller site administrators want that option.