Protecting Java applications with Acegi, Part 4: Securing JSF applications

Configurable security for JavaServer Faces applications

The first 3 parts of this series discuss how to use the Acegi security System to protect Java enterprise applications:

The 1th part explains how to implement a simple URL-based security system using the Acegi built-in filter.

Part 2nd shows how to write access control policies, store them in an LDAP directory server, and configure ACEGI to interact with LDAP servers to implement access control policies.

Part 3rd shows how to use Acegi to protect access to instances of Java classes in an enterprise application.

Part 4th discusses how to use Acegi to protect JavaServer Faces (JSF) applications running in the Servlet container. This article first explains the features that Acegi provides for this goal, and clarifies some common misconceptions about using Acegi and JSF. It then provides a simple web.xml file that can be used to deploy Acegi to protect the JSF application. Then delve into the Acegi and JSF components to see what happens when you deploy Web.xml files and users access JSF applications. A sample JSF application protected by Acegi is provided at the end of this article.

Add security without writing Java code

Review the first example ACEGI application in this series (see the "A Simple Acegi Application" section in part 1th). The application uses Acegi to provide the following security features:

Provides a login page when an unauthenticated user attempts to access a protected resource.

Direct redirection of authorized users to the required protected resources.

Provides an Access Denied page if the user is not authorized to access the protected resource.

Recall that you can get these features without writing any Java code. You only need to configure the Acegi. Similarly, in a JSF application, you should be able to implement the same characteristics from Acegi without writing any Java code.

Clarification of misunderstandings

Other authors seem to believe that integrating Acegi with JSF requires a JSF application to provide a login page. This view is not correct. It is Acegi's responsibility to provide a login page when needed. It is also Acegi's responsibility to make sure that the login page appears only once during a secure session. Authenticated and authorized users can then access a protected resource without having to repeat the logon process.

If you use JSF to provide a login page, there will be two major problems:

When needed, the login page is not provided with the Acegi feature. You must write Java code to implement all the logic to provide the login page.

At least some Java code needs to be written to transfer the user credentials (username and password) from the JSF login page to the Acegi.

The purpose of Acegi is to avoid writing Java security code. If you use JSF to provide a login page, you do not implement this purpose and raise a number of other Jsf-acegi integration issues, all of which stem from the fact that "Acegi is used to provide configurable security." If you try to use JSF to complete the work of Acegi, you will get into trouble.

The remainder of this article explains and demonstrates the development of JSF applications independent of Acegi, and later configures Acegi to protect JSF applications-without writing any Java code. First look at the Web.xml file, which you can deploy to protect the JSF application.