[TriLUG] Apache: modifying REMOTE_USER (w/ Tomcat)

[Owen Berry]

Here's an implementation I have working on my FC3 box. This will take
the user agent header and print it out in caps. The mod_perl
PerlHeaderParserHandler phase handler uppercases the environment
variable, and then passes processing back to Apache. Then there is a
simple script running under ModPerl::Registry, which could be a plain
old CGI, and emulates Tomcat in your case, which prints out the user
agent header.

Apache Config file (/etc/httpd/conf.d/testhandler.conf):

PerlModule TestHandler
<Location /testhandler>
    SetHandler perl-script
    PerlHeaderParserHandler TestHandler
</Location>

Alias /testhandler /home/testhandler
<Directory /home/testhandler>
    SetHandler perl-script
    PerlResponseHandler ModPerl::Registry
    PerlOptions +ParseHeaders
    Options +ExecCGI
</Directory>

Perl handler code (/etc/httpd/lib/perl/TestHandler.pm):

package TestHandler;

use Apache2;
use Apache::Const;
use Apache::RequestRec ();
use APR::Table;

sub handler{
    my $r = shift;
    my $headers = $r->headers_in();
    $headers->{'User-Agent'} = uc($headers->{'User-Agent'});
    return OK;
}
1;

Perl ModPerl::Registry script (/home/testhandler):

#!/usr/bin/perl

use strict;
use CGI ();

my $q = new CGI();
print $q->header;
print $q->start_html(-title=>'Test'),
          $q->p("Running: ".$q->user_agent()),
      $q->end_html;

Not so bad, was it? Let me know if you have questions.

Owen

On Tue, 2005-12-06 at 14:06 -0500, William Sutton wrote:
> Just for giggles...can you write an Apache/mod_perl handler that performs 
> the username translation and then hands off to the Java app?
> 
> -- 
> William Sutton
> 
> 
> On Tue, 6 Dec 2005, Jeremy Portzer wrote:
> 
> > Hello TriLUG Apache and/or Tomcat gurus,
> > 
> > I am encountering a vexing problem regarding the deployment of a J2EE web
> > application running inside Tomcat 5, with Apache HTTPD 1.3 as the
> > front-end web server.
> > 
> > The issue surrounds authentication via Shibboleth.  The basic auth 
> > workflow is as follows:
> > - Unauthenticated request comes in from the client
> > - "Require valid-user" directive in HTTPD configuration forwards request 
> > to the Shibboleth module (via Authtype Shibboleth, implemented by 
> > mod_shib)
> > - Shibboleth module handles authentication and sets the REMOTE_USER 
> > variable in the HTTPD request if auth is successful
> > - Request continues through to mod_jk (Jakarta Connector) and is received 
> > by Tomcat for processing
> > - The Java application in Tomcat reads REMOTE_USER and proceeds
> > accordingly.
> > 
> > This is generally working well.  But the wrinkle is that the Shibboleth 
> > origin (directory server, think like LDAP), has mixed-case usernames in 
> > it.  So, the username returned into REMOTE_USER might be something like 
> > SmithJ or JonesK.
> > 
> > The problem is that the Java application expects all usernames to be
> > lowercase.  It has its usernames stored in a database in all lowercase
> > format and its case-sensitive comparison causes the application to fail.  
> > (Test users created in the directory server in all lowercase work fine.)
> > 
> > Clearly there are several ways of resolving this:
> > * Fix the Java app so it handles the case mismatch.  This is not easily 
> > done becaues it's a third-party closed source app, but this would be 
> > optimal.
> > * Fix the usernames in the directory server so they aren't mixed-case to 
> > begin with.  This is not desired as the central directory is used by many 
> > other applications, and the mixed-case format is desired by the directory 
> > administrators.
> > * Configure something in Shibboleth to automatically lowercase the 
> > usernames through the "Attribute provider" that translates information for 
> > HTTPD.  This has been deemed impossible by several apparently 
> > knowledgeable folks on the Shibboleth discussion list.  I am not that 
> > familiar with Shibboleth so I'm taking them on their word here.
> > 
> > So, the option I'm trying to consider is if there's a way of modifying 
> > REMOTE_USER in Apache HTTPD "between" the step of obtaining it from the 
> > Shib module and then having the request processed by mod_jk.  I've studied 
> > the HTTPD documentation, and while there are several rules for setting 
> > environment variables, none of them seem to have access to string 
> > functions that would allow me to lowercase and then set the variable.
> > 
> > Relevant Apache configuration snippets:
> > 
> > #snip generic shib configuration info
> > <Location /webapps>
> >         AuthType shibboleth
> >         require valid-user
> > </Location>
> > 
> > #further on down, after generic mod_jk configuration info
> > JKMount                         /webapps/*      ajp13
> > 
> > 
> > Another option presented to me is to write a Tomcat filter which could be 
> > installed ahead of the J2EE app that could intercept the REMOTE_USER 
> > variable and perform the necessary translation.  Unfortunately I am not 
> > familiar with Java or Tomcat filters.
> > 
> > Thanks for any ideas.  Can this be done in Apache at all?  Would I need to 
> > write a new Apache module, and if so, can that be done in Perl or other 
> > scripting language?
> > 
> > Regards,
> > 
> > Jeremy Portzer
> > 
> >