'Ravenizing' an application using container-managed security

The following post to the University of Washington's Pubcookie mailing list is a good description of a well tried approach to using 'container-managed security' (such as that provided by the various Ucam Webauth webserver plugins) with an application that comes with its own authentication mechanism. See also Washington Mailman for a different writeup of what is in effect the same trick.

To apply what follows to Ucam Webauth (and hence Raven), just read 'Ucam Webauth' where it says 'Pubcookie' and 'AAAlwaysDecode' where it says 'PubcookieNoPrompt'. Where it says 'an external LDAP data source' you could use lookup, but that's outside the scope of this Wiki.

From: Christos Ricudis <pubcookie@komodino.itc.auth.gr>
To:  <pubcookie-users@u.washington.edu>
Date: Fri, 25 Aug 2006 10:56:53 +0300
Subject: [pubcookie-users] Re: Integrating Pubcookie into phpscheduleit

nathan dors wrote:

> Integration efforts with packages that don't support external
> authentication via the standard REMOTE_USER environment variable can vary
> dramatically. Often to the worser end of the dramatic sphere. You have to
> figure out and subvert how and when the package presents its own login
> page. And you have to figure out how the user's identity is stored (in the
> app's database and in its session info) and map the REMOTE_USER value into
> that.
>

It gets worse with bigger applications. We are working with Joomla in
particular, and it's absence of provisions for integration with external
authentication systems makes integrating with pubcookie a mess. You have to
account for the fact that usually not ALL of the site's content need to be
protected by pubcookie. We could not separate "private" and "public" content
through simple URL matching and merely protect the former.

The solution I came up with was to put the entire site under pubcookie,
while allowing non-authenticated access using the PubcookieNoPrompt
directive. A session with no AUTH_TYPE and REMOTE_USER variables present is
mapped to a guest, non authenticated user.

When the user tries to access protected content, is redirected to an
internal Authentication module of the application (that normally presents
the login page and checks the user's credentials). Instead of presenting the
normal Joomla login page, we redirect the user to a dummy
pubcookie-protected .cgi,  passing it an encoded URL pointing to where the
user was before asking to authenticate.  Upon succesfull pubcookie
authentication, the .cgi simply redirects the user back to the point he was
before the authentication request, with updated credentials.

Now we were to the point that we could separate protected and non-protected
content. The next problem we had to solve was that Joomla required all of
it's users registered in it's internal database. So, whenever we encountered
a pubcookie-authenticated user not existing in the database, we had to
auto-register the user through an external LDAP data source.

It's rather awful, but it works.

There are a few applications that allow easier tying to an existing SSO, and
some external data providers allow you to interact with their login
procedures. We liked the way MSDN-AA works. They manage licenses through a
web-based system called ELMS, which has special provisions for circumventing
it's normal login procedure in the case an institutional SSO exists - so
it's possible to tie pubcookie with it, even if none of ELMS resides in our
own servers.