Washington Mailman

This case study illustrates how an application with built-in
authentication services can be integrated with a
container-based WebISO system so that local and non-local users
can self-select which kind of authentication is appropriate to
them: either the container-based WebISO mechanism for local
users or the original built-in authentication mechanism for
non-local users.

In this case study, the University of Washington (UW) wanted to
integrate new web-based email discussion list management
software with its local WebISO system. Mailman was the package
needing integration. Pubcookie was the WebISO system. The goal
was to augment Mailman specifically to use Pubcookie to
authenticate UW users by local UW NetIDs, while continuing to
use Mailman's built-in authentication system, based on email
addresses and membership passwords, to authenticate non-UW
users.

These dueling authentication requirements prevented a typical
container-based solution of simply protecting the entire
Mailmain application with Pubcookie. Doing so would not have
allowed non-UW users to use Mailman, since they wouldn't have
UW NetIDs with which to authenticate. It also would have
over-applied authentication to public pages, for example
Mailman's "listinfo" pages which display information about
individual email lists. All public pages should remain
unauthenticated, as they are in Mailman to begin with, and
again this precluded a typical container-based approach of
placing Mailman within a Pubcookie-based container. Thus,
another solution would have to be found.

The best integration solution (and the one adopted by UW
developers) would be the one that minimized changes to Mailman
itself, so that Mailman could continue to display login forms
as needed for non-UW users and more generally to initiate
authentication when and where it was already required. Only now
it would be modified to use two different underlying
authentication mechanisms, depending on the choice of each
user. In the case of UW users, Mailman would have to initiate
Pubcookie-based authentication without itself being put into a
Pubcookie-protected container. In the case of non-UW users,
Mailman would simply initiate its existing authentication
mechanism.

This task was accomlished by introducing a simple "stub"  
application along side of Mailman. This "stub" application is
deployed within a Pubcookie-protected directory so that it can
collect authentication information (REMOTE_USER) from Pubcookie
and forward it into Mailman. The "stub" application
accomplishes the forwarding process by setting a SHA1 encrypted
cookie with a broad enough scope to reach the main Mailman
application. The presence of this new cookie, which contains
the user's UW NetID, allows the integrated Mailman application
to vector between the two authentication mechanisms. If it's
present, Mailman has authenticated a local UW user. If it's
not, Mailman continues with its pre-existing authentication
mechanism. (Technically speaking, most of Mailman's
authentication-related functionality happens in and around
calls to Mailman's interal WebAuthenticate() function, and this
is where most of the integration work was focused.)

While fairly straightforward, the modifications to Mailman
involving the "stub" application represent only what was needed
to pass authentication information from a Pubcookie-based
WebISO container into Mailman. In fact, other modifications
were scattered throughout Mailman to make it all work
correctly, including: user interface changes to help users
self-select the appropriate login method, new code to manage
UW-NetID-to-email-address translations required by Mailman,
authorization policy changes, and others. However, these
additional modifications provide no insights into the 
WebISO-specific integrations issues and therefore have been 
omitted. 

This case study simply illustrates what can be done with the
container-based WebISO model, even when much of the
authentication timing and logic is still controlled by the
application.