Implement Finer Access Control than Spring Security - Mon, 04:09 PM Sep 1 2008

Spring Security (formerly the Acegi Security System) provides a powerful role based security for web applications. The developer can limit access to certain URL patterns to specific user roles; tasks such as restricting access to an administrative page to the administrators. For fine grain access control, Spring Security also offers a set of tags to include/exclude parts of a web page based on a user's role.

The Spring Security has a major limitation however, a user's roles must be known at compile time. This severely limits the number of user roles that can exist in a web application. For example, to enable/disable some control features of a blog to its owner, the security system must recognize each blog owner. There is no way to implement this type of access control with compile time values.

I implemented an access control system that recognizes runtime user roles with Spring Security and Acegi-JSF. Web pages use the "acegijsf:authorize" JSF tags from Acegi-JSF to include/exclude contents based on the current user's roles. Here are the implementation details:

• First step is to grant each user of the web application an unique role, for example "ROLE_[username]", in the database. This special role uniquely identifies each user to the security system.
• Next, download the Acegi-JSF Libs, these tags are JSF components that supports value binding with managed beans. (Note: I had to modify some source code in the jar file to make acegi-jsf-1.1.3.jar work with Spring Security 2.0, mostly to change some imports.) Include the acegijsf tags to the JSF pages with the following:

<%@ taglib uri="http://sourceforge.net/projects/jsf-comp/acegijsf" prefix="acegijsf" %>

• Surround the protected contents with the following tags (they work just like the Spring Security tags!)

<acegijsf:authorize ifALLGranted="">
<acegijsf:authorize ifAnyGranted="">
<acegijsf:authorize ifNotGranted="">

• Generate the appropriate user roles dynamically with managed beans in JSF and pass those values to the Acegi-JSF tags in the web pages.

JavaServer Faces Welcome File Access - Sun, 02:05 PM Jul 20 2008

Ideally, when a user accesses a web site via the domain name (e.g. www.csfalcon.com), the web server should take the user to the welcome page (e.g. index.jsp). In fact, this is the default behavior of Apache Tomcat. However, when JavaServer Faces is used for a web application, the default behavior of directing to index.jsp would cause errors if there are any JSF components in your welcome file. JSF is implemented using Servlet Filter, and it looks for special "clues" in the URLs to enable itself; clues in URLs such as /faces/* (default behavior).

Many examples I have seen on the web uses a simple index.jsp without any JSF components as the welcome file, and then uses html's meta tag to redirect the users to the real content of the web site.

<meta http-equiv="refresh" content="0;URL=/page.jsp">

This method works, however, I have notices it can cause problems with search engines. The major one that bothers me is the fact that Google PageRank is lost after the redirect; this can significantly hinder the seachability of your entire web site.

Here is a better solution I found.

• Edit the web.xml file so JSF looks for *.jsf extension to enable JSF components. I think you can have both /faces/* and *.jsf as the url pattern, but I prefer *.jsf for many reasons.

<servlet-mapping>
    <servlet-name>Faces Servlet</servlet-name>
    <url-pattern>*.jsf</url-pattern>
  </servlet-mapping>

• Edit the web.xml file so the welcome file of your web application is index.jsf.

<welcome-file-list>
    <welcome-file>index.jsf</welcome-file>
  </welcome-file-list>

• Put the contents of your main page in index.jsp, including any JSF components!
• Create a place holder file name index.jsf, you do not need to put any text in this file. This place holder stops the web server from complaining that the "actual" welcome file does not exist.

Now when a user accesses your site's domain name, the user is taken to the content with no delay and with PageRank your site deserves.

Beta Version Released - Sat, 06:04 PM Jun 14 2008

The Beta version of csfalcon.com is made public now (although I have been deploying bug fixes and improvements from time to time). The development has been a bit slow since I need to work on my research and Google Summer of Code project. But, I managed to complete the tasks I listed in Road to Beta.

The immediate plan is to hold off on development of new features, and focus on understanding and improving the existing system. I am pretty new at developing web application with JavaServer Faces, Spring and Hibernate. And since I was rushing to get csfalcon.com deployed, I didn't really put much effort into good designs and best practices. It's time to read books and apply improvements, after all the reason for me to develop csfalcon.com is to learn.

I will blog about JSF+Spring+Hibernate integration, Spring Security and the Selenium test infrastructure as soon as I feel I understand them well enough.

Road to Beta - Fri, 09:44 PM May 30 2008

Here is a list of things that need to be done before csfalcon.com is in the Beta stage.

• Bug fixes for existing features.
• Improve the look and feel of the website.
• Migrate contents from the previous versions to the new database.
• Create an automated testing infrastructure using Selenium.

The most challenging and probably most rewarding task on this list is the creation of the automated testing infrastructure. Manual testing of a website is labor intensive and usually incomplete; I cannot count the number of times a small change to the code broke another part of the website. Sometimes these bugs are not found until much later when someone uses the affected features. This time around I am going to use good software engineering practices throughout the development of csfalcon.com and share the experiences on this blog. Stay tuned!

Alpha Version Released - Tue, 04:01 AM May 27 2008

The Alpha version of csfalcon.com is made public today, this is considered the 3rd generation of csfalcon.com. The underlining framework is built with JavaServer Faces, Spring and Hibernate. Features implemented so far are Blog and Wiki, each capable of supporting public and private entries. csfalcon.com is now a personal website, the user accounts are no long publicly available. One of the development goals is to use existing open source components as much as possible, so far these are:

• MyFaces (Apache JSF Implementation)
• Spring
• Spring Security
• Hibernate
• InformationHidingURL Filter
• acegijsf
• YaWiki Engine (Wiki Rendering Engine)
• jRSS (RSS Feed Generator)

As can tell from the spartan look of the website, this version is far from feature complete. The early release is necessary to satisfy the blogging needs for my Google Summer of Code 2008 project. There will be much more development to come.