Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • Tomcat (5.0.24+ for Sakai 1.5, 5.5 used for Sakai 2.0)
  • Sakai 1.5.0,1, 2.0
  • Backend (assuming MySQL 4.1 or Oracle)

For Sakai 2.0, the compatible Tomcat version has now been determined to be 5.5.x, thus this needs to be accounted for in the design process.

AUTHENTICATION PROCESS (Sakai 1.5.0,1.5.1, 2.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 modifications: Modifications to the framework of Sakai have not been implemented and proven to work in Sakai 1.5 as a workaround. The drawback to this option is modification/maintenance of Sakai source code.

...

The strategy proposed for implementing authentication in Sakai was to provide a proof of concept for the Sakai 1.5, Tomcat 5.0.28+, and Linux configuration. This was created on felix.ucdavis.edu:8100. This was a success (felix) using the Apache 2.0 + mod_jk connector configuration, however porting to Windows seemed to have issues with mod_perl compatibility. An ideal solution has since been A solution was found using a servlet filter and modifying the code at the Sakai level, however this was most straightforward in Sakai 1.5.

TECHNICAL SOLUTION-- DESIGN ASPECT

The design of the technical solution found is described below:

Sakai 1.5 and Sakai 2.0:
-strike-The loginservlet class was extended to a servlet called the DistAuthLoginServlet. The DistAuthLoginServlet preserves the same logic that the LoginServlet has, with exception to any password lookup/recognition information. Because the LoginServlet is used to capture form passwords, this logic can no longer be used and only DistAuth handles password information. Above is not the only difference between the DistAuthServlet and LoginServlet, the main difference is that the DistAuthLoginServlet replaces the "getRemoteUser" with the Kerberos name from the AuthUser cookie.

The LoginServlet is used for inherent Sakai accounts (e.g. admin, etc.), while the DistAuthLoginServlet is the login that is protected by DistAuth. In addition to these modifications, other modifications need to be incorporated in the Sakai framework for DistAuth to be configured correctly. See the "HOW TO CONFIGURE DISTAUTH AND SAKAI 1.5" section below.strike

HOW TO CONFIGURE DISTAUTH AND SAKAI 1.5.0,1.5.1. 2.0

The following are instructions for adding DistAuth login to Sakai 1.5 (This is assuming a login page with both DistAuth and Sakai Login together, version 2 below)

...