Security Redirect - NavigationHandler Decorator

[Carlos Fernandez <ca...@digitalfocus.com>]

I am porting a sample blog application to JSF to get a better feel for the
API.

Two features of the application require the user to be logged-in prior to
using.  The use case is pretty straight forward.

1- All of the application options are displayed at all times as links.
2- Only logged in users can access protected features (e.g. replying to an
existing blog entry and creating a new thread).
3- If an anonymous user attempts to access a protected feature they should
be redirected to the login page.
4- Once they successfully login they should be redirected to the feature
they attempted to access in step 2.

This doesn't seem to be a good fit for the "enabledOnUserRole" attribute
that the myfaces X components have.  Since I want the link enabled, but the
requests "routing" to be altered.

In a request based web application I would ordinarily write a servlet
filter. If it caught a request to a secure resource, it would:
 - check for the user object in session
 - if the user object didn't exist, it would save the requested url and the
query string as a request param.
 - forward the request to the login page.
 - the login page would save the original request as a hidden field
 - after a successful login, the controller would redirect the user to the
URL originally requested passing along the query params

This solution was predicated on two facts:
- The secured resources were always accessed via distinct http GETs.  So a
user requesting a reply to an existing blog always took the form of
http://myURL/reply.do?blogEntryId=123.  An unsecured controller would never
simply include the contents of a secured resources (e.g. a reply) in its own
response.
- All request state was contained between the URL and query string.

Granted, this solution is limiting, it satisfies the use case I normally
face.

Please note that this used custom security - there was no use of the JAAS,
J2EE security etc.

When I went trolling around for suggestions on an appropriate solution in
JSF, I kept running across variations of a specialized Navigation Handler.

The custom navigation handler is very similar to the one found at
http://www.jsftutorials.net/jsfNavigation/jsf-login-navigation-redirect.html
.

A sample action method:

public String replyToThisBlogEntry() {
	//get the data row selected from the DataModel object
	Entry replyTo = findActiveEntry();

	//pass the entry that the user is replying to,
      //to the reply pages backing object
	ReplyHandler replyHandler = findReplyHandler();
	replyHandler.setReplyTo(replyTo);

	return "reply";
}

My problem with the custom NavigationHandler solution is that the original
resource requested, in this case "reply", requires a certain amount of state
above and beyond the original handleNavigation() arguments - fromAction,
outcome and viewId.  In this case, the ReplyHandler must have a reference to
the correct Entry object.  Other action methods may even more elaborate
implementations.

Should I attempt to copy over the request scope attributes (which should
include the effected managed beans) when forwarding to the login view, and
then restore these request scope attributes when forwarding to the secure
resource?  That seems a bit convoluted - and a bit dependent on how the
underlying jsf implementation stores the request scope attributes.

Am I going about this the wrong way - trying to fit a request framework peg
in an event framework hole?  Should I handle the security in the action
method itself and then store the entry object (or any other applicable
request state) in the login handler?  This seems a bit cumbersome and would
require special handling for each secure feature added.

Any suggestions?

TIA for any help!

Carlos