Related Topics: Java EE Journal, Apache Web Server Journal

J2EE Journal: Article

Effective Page Authorization In JavaServer Faces

Application security - the art of applications defending themselves - represents an important line of defence

Listing 5 Indicating that a Web resource requires SSL

<user-data-constraint>
     <transport-guarantee>CONFIDENTIAL</transport-guarantee>
</user-data-constraint>

Though J2EE Web resources can be configured to require HTTPS this way, the J2EE specification doesn't demand that Web containers respond by automatically switching protocols. Instead, J2EE containers usually return an HTTP error message to indicate a failed user request. Individual J2EE containers like Apache Tomcat provide native support for switching between the HTTP and HTTPS protocol. However, you ought to be aware that such solutions aren't portable to other J2EE containers.

Page Navigation in JavaServer Faces
So we've seen how basic container-managed security is configured through the use of logical application roles protecting a URL pattern. Now let's look at how JSF manages page navigation and how the principles of container-managed security can be applied.

Page navigation in JavaServer Faces is defined in the WEB-INF\faces-config.xml file, where the JSF NavigationHandler component uses it.

The application developer configures navigation in JSF either as a server-side forward or, if the <redirect/> element is included in the navigation case, as a browser redirect.

Listing 6 JSF navigation case issuing a redirect request for page navigation

<navigation-case>
     <from-outcome>success</from-outcome>
     <to-view-id>/Departments.jsp</to-view-id>
     <redirect/>
</navigation-case>

Server-side forwards are the de facto default implementation of navigation cases in JSF, but such navigation harbors two side effects: first, the URL won't change, and so pages in the application aren't bookmarkable; and secondly, there's no new submission of a URL pattern for container-managed security to be applied to. As a consequence, if you've implemented container-managed security, you'll have to use <redirect/> explicitly on any navigation cases that have to trigger a security check across role boundaries.

It should be clear by now that authorizing pages and implementing a secure channel for communication isn't easy to achieve in JavaServer Faces. And using JAAS instead of container-managed security offers no better solution. The answer lies in a combined approach: a reusable custom security implementation specifically designed to work with JSF based on JAAS or container-managed J2EE security.

Where Does Security Belong in JavaServer Faces?
As we've mentioned, JSF has no real security infrastructure built into it and this leaves the developer to wonder where and how to implement security. The examples that address user authentication in JSF (using JAAS, for instance) don't cover the important task of page authorization. (See Figure 1)

The authorization enforcer security pattern demands that authorization be handled in a central location. For many Web applications, this central location is a ServletFilter associated with the application front controller. In JSF, though, security is best implemented using the built-in extension points provided by the JavaServer Faces architecture.

The two candidate approaches for implementing security in JSF are:

  • A custom ViewHandler that decorates the default ViewHandler and also adds security checks to the createView and restoreView methods
  • A PhaseListener that adds security evaluation to the restoreView and invokeAction phases
Adding security to a Viewhandler doesn't appear to be an ideal solution because there's no guarantee that a security ViewHandler will be executed before any other custom ViewHandlers that have been registered. If another ViewHandler is present and writing to the servlet response stream then security-related actions such as redirecting a request to the HTTPS port would result in illegal state exceptions. So it seems that a custom PhaseListener is the better approach to adopt.

Developing a JavaServer Faces PhaseListener for Security
JavaServer Faces executes in a rich request lifecycle composed of a sequence of individual phase events: Restore View, Apply Request Values, Process Validation, Update Model Values, Invoke Application, and Render Response. PhaseListeners in JavaServer Faces are Java classes configured in the faces-config.xml file and notified when a specific phase event of interest occurs. (See Figure 2)

To execute custom logic before and after a specific event, custom application code is added to the beforePhase and afterPhase methods of a PhaseListener. Both methods accept an input argument of a PhaseEvent to provide information about the calling phase, for example, a phase ID. The third method developers have to implement is getPhaseId. The getPhaseId method is used to declare which phases the listener is actually interested in being notified about.

Listing 7 Custom PhaseListener listening to any event and implementing the JSf PhaseListener interface

public class J2EESecurityPhaseListener implements PhaseListener
{
     public SecurityPhaseListener() { }
     public void afterPhase(PhaseEvent phaseEvent) { }
     public void beforePhase(PhaseEvent phaseEvent){ }
     public PhaseId getPhaseId() {return PhaseId.ANY_PHASE;}
}

An application can have more than one PhaseListener configured. PhaseListeners are configured in the <lifecycle> element of the faces-config.xml configuration file.

Listing 8 PhaseListener configuration in faces-config.xml

<lifecycle>
    <phase-listener>
       com.groundside.jsf.J2EESecurityPhaseListener
    </phase-listener>
</lifecycle>

Java IDEs like Oracle JDeveloper provide visual editors to simplify this configuration of the faces-config.xml file.

A J2EE security PhaseListener - J2EESecurityPhaseListener
The J2EESecurityPhaseListener is a custom PhaseListener that implements page authorization for the JSF restoreView and invokeAction phases using container-managed J2EE security roles. JSF doesn't let PhaseListener register for multiple selected events. Either a PhaseListener registers for one specific event or it registers for all events. So the J2EESecurityPhaseListener listener is registered to listen to any phase, but responds only to the RESTORE_VIEW and INVOKE_APPLICATION phases.


More Stories By Duncan Mills

Duncan Mills is senior director of product management for Oracle's Application Development Tools - including the JDeveloper IDE, and the Oracle Application Development Framework. He has been in the IT industry for the past 19 years working with Oracle, Java, and a variety of more obscure programming languages and frameworks along the way. Duncan is the co-author of the Oracle Press book: Oracle JDeveloper 10g for Forms and PL/SQL Developers - a Guide to Web Development with Oracle ADF.

More Stories By Frank Nimphius

Frank Nimphius is a principal product manager for application development tools at Oracle Corporation. As a conference speaker, Frank represents the Oracle J2EE development team at J2EE conferences world wide, including various Oracle user groups and the Oracle Open World conference.

Comments (6) View Comments

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.


Most Recent Comments
y_alomoush 09/01/08 04:29:19 PM EDT

Hi Duncan and Frank,

Thanks for your great efforts.

It is a job well done. In fact,I have installed the module and plugged it to my own application for evaluation purposes.However, I have found a scenario where a user can access into a unauthorized page, I don't know if I can call it as a bug or not.

The scenario is as the following:
1-start the application by calling a page that requires authentication and authorization.
2-the system shall direct you to the login page.

3-enter a correct username/password but not authorized to access that page.

3-system shall redirect you to error page using the sendError method.

4-call the same page again (using the same session). the system strangely forward you to the page that you are not authorized to access.(because the page is already cached as an authorized page)

I think after the page is redirected to the error page the handleSecurity method must return, in this case, false instead of retuning true, this in order not to cache an unauthorized page.

Thank yo once again.

keerthi 09/21/06 10:22:56 AM EDT

Hi Duncan and Frank,

This article is really an interesting one. I found it at a right moment of time as I was trying to implement Page level security in a Project based on JSF.
I was wondering the article is based on Container-Managed Security or reading roles from web.xml. I have a requirement where I need to read the roles from database and not from web.xml, can I achieve this security feature by implementing the points mentioned in this article.
Awaiting for your response.
Thanks and Regards,
Keerthi.

SYS-CON Italy News Desk 08/10/06 05:42:31 PM EDT

Application security - the art of applications defending themselves - represents an important line of defence in an overall in-depth security strategy. Web applications that follow the Model-View-Controller (MVC) architecture can, and should, have security implemented on all three layers. Normally it's the controller component that handles page authorization in MVC, the view layer that hides controls and information based on user authorization, and the model that enforces the business rules and input validation. However, it's up to the developer, based on an individual security policy and the programming technology used, to decide where to put security. Using pluggable validator components in JavaServer Faces (JSF), for example, developers may decide to verify user input on the view layer as well as on the model layer.

AJAXWorld News Desk 08/10/06 05:26:41 PM EDT

Application security - the art of applications defending themselves - represents an important line of defence in an overall in-depth security strategy. Web applications that follow the Model-View-Controller (MVC) architecture can, and should, have security implemented on all three layers. Normally it's the controller component that handles page authorization in MVC, the view layer that hides controls and information based on user authorization, and the model that enforces the business rules and input validation. However, it's up to the developer, based on an individual security policy and the programming technology used, to decide where to put security. Using pluggable validator components in JavaServer Faces (JSF), for example, developers may decide to verify user input on the view layer as well as on the model layer.

JDJ News Desk 07/26/06 05:18:34 PM EDT

Application security - the art of applications defending themselves - represents an important line of defence in an overall in-depth security strategy. Web applications that follow the Model-View-Controller (MVC) architecture can, and should, have security implemented on all three layers. Normally it's the controller component that handles page authorization in MVC, the view layer that hides controls and information based on user authorization, and the model that enforces the business rules and input validation. However, it's up to the developer, based on an individual security policy and the programming technology used, to decide where to put security. Using pluggable validator components in JavaServer Faces (JSF), for example, developers may decide to verify user input on the view layer as well as on the model layer.

JDJ News Desk 07/26/06 04:40:02 PM EDT

Application security - the art of applications defending themselves - represents an important line of defence in an overall in-depth security strategy. Web applications that follow the Model-View-Controller (MVC) architecture can, and should, have security implemented on all three layers. Normally it's the controller component that handles page authorization in MVC, the view layer that hides controls and information based on user authorization, and the model that enforces the business rules and input validation. However, it's up to the developer, based on an individual security policy and the programming technology used, to decide where to put security. Using pluggable validator components in JavaServer Faces (JSF), for example, developers may decide to verify user input on the view layer as well as on the model layer.