Listing 9 The J2EESecurityPhaseListener listens to any event but responds to RestoreView and InvokeApplication only

public void afterPhase(PhaseEvent phaseEvent)
    {
      PhaseId phaseid = phaseEvent.getPhaseId();

      if ( phaseid == PhaseId.RESTORE_VIEW||
        phaseid == PhaseId.INVOKE_APPLICATION )
      { ... }
}

The J2EESecurityPhaseListener uses an extra XML configuration file, faces-security-config.xml, to define JSF pages that require authentication, authorization, or secure communication with SSL. The faces-security-config.xml file is located in the WEB-INF directory like the JavaServer Faces faces-config.xml file.

The security PhaseListener parses the faces-security-config.xml file with the Apache Digester [DIGESTER] to create a Java security object that is subsequently cached in the application scope. The security object contains security information about the configured HTTP and HTTPS ports, whether or not to keep SSL after it's used the first time, and individual authentication, authorization, and SSL requirements for each page.

The PhaseListener determines page authorization only once per session for each JSF page (viewId) that a user requests. At successful authorization, a reference to the JSF page is cached in the session to improve performance on subsequent requests for the same resource.

A user who requests a protected page without first having been authenticated is redirected to an authentication servlet. The authentication servlet is configured in the web.xml deployment descriptor and protected by a J2EE security role that all users are members of. All JSF pages configured in the faces-security-comfig.xml file to require authorization implicitly also require authentication. If an unauthenticated user tries to access a page that requires SSL, a container-managed logon form is launched over HTTPS.

The faces-security-config.xml file consists of two parts:

• A global configuration section to provide HTTP and HTTPS port information and whether SSL communication should be kept once established. The keep-SSL-mode information overrides the individual page configuration for SSL.
• Multiple jsf-page elements to configure page and directory authorization. The page is identified by its viewId, which starts with a leading slash followed by the relative URI, not excluding the faces virtual mapping (for example, /protected/main.jsp). Directory names are indicated by an appended wildcard character '*' (for example, /protected/*).

For each protected page or directory, the developer defines the authentication, authorization, and SSL requirements. If a page requires SSL, but the current request protocol is HTTP, the J2EESecurityPhaseListener redirects the request to a configured HTTPS port. Similarly, if the protocol is currently HTTPS but the page doesn't require a secure channel and the keep-ssl-mode is set to false, the PhaseListener redirects the request to the HTTP port.

JSF pages and directories that require authorization have to reference the name of one or more J2EE security roles defined in the web.xml file. The role-concatenation attribute lets developers specify whether a user has to be a member of all the configured roles (AND) or only a single role (OR).

Because the security configurations are stored in an XML file, the page authentication strategy and the authorization definitions can be changed at any time without recompiling or redeploying the application.

To use the J2EESecurityPhaseListener in custom JSF applications, developers do the following

• Deploy the jsfj2ee-security-util.jar file as a library with the application.
• Create and configure the faces-security-config.xml file in the application WEB-INF directory.
• For protocol switching, configure the HTTP and HTTPS ports and ensure that the application server is set up to share a session between the two ports.
• Configure the authentication servlet in the web.xml file.
• Configure container-managed authentication and J2EE security roles in the web.xml file.

Once set up, the J2EESecurityPhaseListener lets developers apply authorization to any JSF page navigation - a forward or a redirect - while still using standard container mechanisms to handle authentication and role definition.

To improve default container-managed security, the J2EESecurityPhaseListener also lets developers configure page authorizations that use multiple J2EE roles, rather than having to define multiple roles to achieve fine-grained authorization in conventional container-managed security.

Completing the Page Authorization Picture with a Custom Property Resolver
The "limited view" security design pattern defines what users can view and access and lets them access accordingly. Protecting a page from unauthorized access alone isn't enough. UI components that initiate page navigation should be hidden if the user is not allowed access the navigation target. To set a component's rendered property to false, expression language (EL) can be used. The EL can be sourced from handcrafted managed beans defined as part of the application or more generically through a security-aware custom variable resolver. A sample resolver of this type is available for download at jsf-security.sourceforge.net/.

Summary
Without a doubt, JavaServer Faces is a great step forward for J2EE application development. Application security is, however, an important component in the development lifecycle and, unfortunately, this is where the current JavaServer Faces specification falls short. In the future, we would hope and expect that security integration, perhaps of a nature similar to that discussed in this article and the associated code, will be added to the specification.

The custom J2EESecurityPhase-Listener developed for this article uses container-managed security for the sake of simplicity, but it can be adapted to use either JAAS or a custom security provider. The source code for this PhaseListener based solution can be downloaded with this article.

References

• E. Burns, C. Schalk. JavaServer Faces: The Complete Reference. ISBN 0072262400
• D. Alur, J. Crupi, and D. Malks. Core J2EE Patterns: Best Practices and Design Strategies. 2d ed. ISBN 0-13-142246-4
• jsf-security.sourceforge.net/
• DIGESTER: jakarta.apache.org/commons/digester/