Versions Compared

Key

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

...

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

  • -strike 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 has now been determined to be determined5.5.x, thus this needs to be accounted for in the design process.

...

OPTION & NOTES

Apache-Tomcat connector

Catalina Valves/Realms

Tomcat Interceptors

Servlet filter

Sakai modifications

Programming Notes

Already created with Shibboleth, but needs to be modified/tested with Sakai

Specific to Catalina API's for Tomcat version

Specific to Tomcat API'sTested,

no longer a possibility (due to setRemoteUser()) remoteUser() not set, however alternative means found of setting the user

No mods yet

Time to implemement

Least

Most

Most

More

Not determined

Meets requirements?

Yes

Yes

Yes

YesNot

determinedmodifications made

Any dependencies?

Running Apache, and Apache/Tomcat versions

Tomcat version, conf files and API

Tomcat version, conf files and API

Servlet 2.3+ API

Sakai version, need to manage Sakai code

...

The strategy proposed for implementing authentication in Sakai is to provide a proof of concept for the Sakai 1.5, Tomcat 5.0.28+, -strike Apache 2.0, and Linux configuration (in progress). If this works, utilize this implementation for Sakai. The possibility of using Servlet filters is no longer a possibility due to the inability to write to the RemoteUser. A screenshot was provided as a mockup for the authentication model UI (login button replaces username and password textboxes in SiteNavServlet). 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 found using a servlet filter and modifying the code at the Sakai level.

TECHNICAL SOLUTION-- DESIGN ASPECT

The design of the technical solution found is described below:

Sakai 1.5:
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.

h2: HOW TO CONFIGURE DISTAUTH AND SAKAI 1.5

The following are instructions for adding DistAuth login to Sakai 1.5 (This is assuming a login page with both DistAuth and Sakai Logins together)

  • Put the UCDDistAuth.jar in the common areas where Tomcat needs to find them (common-lib, shared-lib) This is available from Scott Amerson at IET.
  • Put the DistAuthLoginServlet.java file in the ..\sakaidev\chef-tool\src\java\org\sakaiproject\tool\authn directory. This is available from Scott Amerson at IET.
  • Put the new login.vm (assuming you haven't changed the out of box version) in ..\sakaidev\chef-tool\src\webapp\vm\authn. An example page vm file is provided as an attachment.
  • Add the following to the web.xml in the sakaidev\chef-tool\src\webapp\WEB-INF directory
    <!?servlet declaration?

<servlet>

<servlet-name>

ucdlogin

</servlet-name>

<servlet-class>

org.sakaiproject.tool.authn.DistAuthLoginServlet

</servlet-class>

<load-on-startup>1</load-on-startup>

</servlet>

<!?further down, add the mapping?

<servlet-mapping>

<servlet-name>

ucdlogin

</servlet-name>

<url-pattern>

/ucdlogin/*

</url-pattern>

</servlet-mapping>

  • Add the following params to the ..\Tomcat 5.0\conf web.xml to declare the DistAuth Filter and mapping.. Basically these are configurable pieces that not everyone will need, but we should put them in. ProtectionLevel is most important (2 is default, 3 is AFS)
    <filter>

<filter-name>myfilter</filter-name>

<filter-class>edu.ucdavis.security.distauth.AuthenticationFilter</filter-class>

<init-param>

<param-name>LoginURL</param-name>

<param-value></param-value>

</init-param>

<init-param>

<param-name>InvalidCookieURL</param-name>

<param-value></param-value>

</init-param>

<init-param>

<param-name>InvalidLoginURL</param-name>

<param-value></param-value>

</init-param>

<init-param>

<param-name>InvalidTokenURL</param-name>

<param-value></param-value>

</init-param>

<init-param>

<param-name>InternalErrorURL</param-name>

<param-value>Error.html</param-value>

</init-param>

<init-param>

<param-name>TimeoutInterval</param-name>

<param-value>3600</param-value>

</init-param>

<init-param>

<param-name>TokenPath</param-name>

<param-value>/afs/ucdavis.edu/common/authinfo/</param-value>

</init-param>

<init-param>

<param-name>LogPath</param-name>

<param-value></param-value>

</init-param>

<init-param>

<param-name>LogFile</param-name>

<param-value>C:\distauth.log</param-value>

</init-param>

<init-param>

<param-name>ValidateUserAgainstDB</param-name>

<param-value>0</param-value>

</init-param>

<init-param>

<param-name>DatabaseQuery</param-name>

<param-value></param-value>

</init-param>

<init-param>

<param-name>ProtectionLevel</param-name>

<param-value>2</param-value>

</init-param>

<init-param>

<param-name>PassThrough</param-name>

<param-value>0</param-value>

</init-param>

<init-param>

<param-name>LogoutURL</param-name>

<param-value>https://secureweb.ucdavis.edu:443/form-auth/logout?</param-value>

</init-param>

<init-param>

<param-name>SendBackURL</param-name>

<param-value>https://secureweb.ucdavis.edu:443/form-auth/sendback?</param-value>

</init-param>

<init-param>

<param-name>LookupPath</param-name>

<param-value>/</param-value>

</init-param>

</filter>

<filter-mapping>

<filter-name>myfilter</filter-name>

<url-pattern>/tunnel/sakai-chef-tool/ucdlogin/*</url-pattern>

</filter-mapping>

  • Rebuild chef-tools module in Sakai (or full Sakai if you haven't made significant changes). Redeploy to Tomcat?just copying the WAR file doesn't seem to be enough. Verify that the source codes being changed are indeed modified at the Tomcat level. I have not found a maven goal that does this specifically..
  • Add top.login=false and container.auth=true to the sakai.properties file (this will turn off the password field on the login page)
  • Restart Tomcat: test that when you hit login (you shouldn't be localhost, use your IP so that the domain cookie is set correctly and can be seen), that the form that has the "DistAuth log in" button is there. When you click this button, you should be taken to DistAuth. Check error logs for the debugging code that I have in Cookies/Filters, etc.

Screenshots are provided for 2 scenarios:
1. )login button replaces username and password form boxes on the site Login, takes you to a central login for both DistAuth and Sakai admin.
2. )Dist Auth login and login buttons appear on site Login. Each will take you to a different location to authenticate.