'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 <firstname.lastname@example.org> To: <email@example.com> 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.