Form-Based Distributed Authentication in Sakai

PROBLEM OUTLINED

Form-Based Distributed Authentication is needed in Sakai, for both versions 1.5 and 2.0. This document outlines the best possible solution for implementing this method of authentication in Sakai, as outlined by Scott Amerson (IET) in accordance with feedback from various parties. These parties include Yale, Indiana, and the Sakai Development Team.

The possible solutions are outlined further in this document, in a matrix detailing various issues related to each implementation strategy. Also detailed in this document, is the high level overview of the authentication mechanism in Sakai.

This documentation is assuming the software that will be used for the implementation of authentication in Sakai is:

• Apache 2.0
• Tomcat (5.0.24+, but not 5.5)
• Sakai 1.5.0 (or 1.5.1 if available)
• Backend (assuming MySQL 4.1 or Oracle)

For Sakai 2.0, the compatible Tomcat version is yet to be determined, thus this needs to be accounted for in the design process.

AUTHENTICATION PROCESS (Sakai 1.5.0)

In summary, Sakai allows for Tomcat container authentication ("container.auth" setting in sakai.properties) to be enabled as well as customization of various interfaces (UserDirectoryProvider in particular) within Sakai to support authentication. Sakai authentication is now supporting an LDAPDirectoryProvider, and with each provider interface there are options to edit/store/ and modify users. By setting the "container.auth" parameter accordingly, Sakai is configured to trust remote user.

Sakai uses the following steps in its authentication process:

Sakai checks "container auth":
*If Sakai trusts container, it then checks remote user vs user information (doesn't care about password). If this check passes, then done. If not, checks for providers (see below):

*If doesn't trust container, then it first checks the password. If the password fails, then it relies on the provider (only one can be implemented) to provide a means of maintaining user information. It is from then on that the provider either fails the authentication, or decides to store user information in Sakai

The implementation of Sakai at UCD, the latter path given will not be used because of the ability to incorporate DistAuth in the process early. A discussion of Form-Based DistAuth process is out of scope of this document, however the specific implementation strategy taken to incorporate Form-Based DistAuth into Sakai must meet the following requirements:

1. Check for the presence of Cookie values "AuthUser" and "DA1"
2. Set the remote user value accordingly, for Sakai's use
3. Record the returnURL for the sendback from DistAuth

IMPLEMENTATION ALTERNATIVES

Below is a table defining the alternative strategies for implementing Form-Based DistAuth in Sakai:

The following options have been explored as possible solutions to the Sakai authentication problem. Here is a brief explanation of the given option:

Apache-Tomcat connector: The mod_jk2 connector implementation used for Shibboleth may be modified for this given implementation in Sakai (mod_jk connector should be used instead).

Catalina Valves/Realms: Tomcat inherently has a "single-signon" authentication valve which can be used when users are moving between webapps and should not be required to be authenticated again. Other custom implementations of valves and security realms may be implemented.

Tomcat Interceptors: Specific interceptors for different types of requests (e.g. JSPRequestInterceptor, etc.) may be implemented in order to trap the request before any process on the application server runs. Interceptors call a series of methods (10) per hit, so the performance may be an issue as well.

Servlet Filters: Filter requests that invoke servlets in a webapp. Sakai's architecture inherently invokes many servlets per pageload, so this may not be optimal.

Sakai modifications: Modifications to the framework of Sakai have not been implemented. The drawback to this option is modification/maintenance of Sakai source code.

TECHNICAL SOLUTION

The strategy proposed for implementing authentication in Sakai is to provide a proof of concept for the Sakai 1.5, Tomcat 5.0.28+, Apache 2.0, and Linux configuration (in progress). If this works, utilize this implementation for Sakai. At the same time, still explore the possibility of using filters (as Yale/CAS implementation proves) as an alternative.

A screenshot was provided as a mockup for the authentication model UI (login button replaces username and password textboxes in SiteNavServlet).