...
The design of the technical solution found is described below:
Sakai 1.5 and Sakai 2.0: -
Background:
One solution that was found for Sakai 1.5, however not straight forward for Sakai 2.0. It is less than ideal, but just noted here as a solution that was found to work on both Windows and Linux. The details are provided below:
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.-.
Solution Found: For both Sakai 1.5 and 2.0
Keeping the requirements in mind (see Requirements doc), a better solution had to be found that didn't involve direct modification and maintenance of Sakai source code. The solution found is a combination of a Servlet Filter and Request Wrapper, each handling a portion of the filtering and request handling in conjunction with the existing Sakai Request Filter.
HOW TO CONFIGURE DISTAUTH AND SAKAI 1.5.0,1.5.1. 2.0
...