URL Filtering_AuthN

Requirements

For every defined gradebook application page, three conditions implicitly need to hold:

Is there an authenticated user?

Has a gradebook been selected?

Does this user play an authorized role in this gradebook?

When any of these conditions don't hold, the requested page shouldn't display. At the minimum, an error message should be displayed instead. Most useful web applications will remember the requested URL, redirect the user to a different URL (to login or to select a gradebook), and then return to the originally requested page.

Options

There are (at least) 4 ways to perform these standard checks.

A) Define a JSF ViewHandler decorator for the application. Its "createView" method can check for properly set session-scoped properties and quasi-redirect the user by calling "createView(context, aDifferentJsf)".

This is the usually recommended pure-JSF approach. Unfortunately, only one ViewHandler can be defined application-wide. Since the Gradebook has to work embedded in Sakai and in tandem with Samigo, it seems risky to rely on any feature that can't be scoped by URL path. Decorating the NavigationHandler is a similar approach with the same problem.

B) Define a servlet filter (or multiple servlet filters) and configure them in "web.xml". They can check for properly set session-scoped properties and forward the request as needed.

This is the usually recommended pure-JSP approach. On the minus side, it breaks us out of JSF-land. Very much on the plus side, servlet filters can be mapped and chained. Also, it's able to protect any pure JSP or servlet code that happens to show up.

C) Define one or more JSF PhaseListeners and add them to the application Lifecycle. Either in the beforePhase or afterPhase, it might check for problems in PhaseId.APPLY_REQUEST_VALUES and deal with them in PhaseId.RENDER_RESPONSE. Or maybe do both in PhaseId.RESTORE_VIEW?

Like servlet filters, this approach can be split across concerns (i.e., one listener for the authn check and another for the authz) and can be chained with other handlers. There's no built-in way of configuring a URL mapping, but it would be simple enough to hardcode one.

The main problem I know with it is that I don't know much about it yet, having no experience or sample code.

D) Somehow do the checks in backing beans on each page and try to deal gracefully with the poor results. (The JSF life cycle does not let a rendering bean trigger a redirect. That can only happen while processing an action.)

Gradebook approach

We do need to be able to test authn/authz workflow even when running standalone. Embedded in Sakai, we're hoping that Sakai will handle the authn / gradebook-exists checking for us. That being the case, the Sakai integration would simply yank those generic checks out. A Samigo-Gradebook standalone combination would have to agree on a TBD shared approach.

That suggests using a low cost option for basic authn checking, so it can be discarded or replaced without losing a lot of schedule time.

That leaves us only the more page-specific authz to worry about: making sure instructors can't see the student page and students can't see the instructor page. (In the Baseline Sakai 2.0 Gradebook, those are the only real roles.) Failing that check would send the browser to a gradebook-specific error page (and generate an error log message).

Again, I'm inclined to take the lowest-cost option. For this team, that would be servlet filters scoped by directory path.

Example:

<filter>
	<filter-name>StudentRoleFilter</filter-name>
	<filter-class>org.sakaiproject.tool.gradebook.ui.RoleFilter</filter-class>
	<init-param>
		<param-name>role</param-name>
		<param-value>student</param-value>
	</init-param>
</filter>
<filter-mapping>
	<filter-name>StudentRoleFilter</filter-name>
	<url-pattern>studentView.jsf</url-pattern>
</filter-mapping>

We hope this will support standalone deployment without interfering with the framework's authn-wrapping scheme. Members of the Gradebook integration teams will need to help us test that hope.