tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <"George>
Subject tomcat, realms and tomcatAuthentication=false
Date Thu, 20 Apr 2006 20:29:53 GMT
I'm considering modifying tomcat to allow it to accept remote_user from
apache via mod_jk, but provide a way to use an existing role-based realm

If necessary, I am looking into modifying Tomcat to do this, but I'd 
really rather not reinvent this wheel if a) it's not necessary (I have 
searched for an existing way, but there is always the possibility I
overlooked something) or b) if 
someone out there has already done it. 

If I do do it, I would like to try to do it in an extensible way that would
be generally useful, hopefully not just to me.  I'd like to find out from
those wiser in the ways of these things if what I plan is doing evil to the
compliance with the container spec.

Basically, this started with me trying to get pubcookie to work with my
existing realm implementation and apps.  Pubcookie sets remote_user in
Apache.  If you set tomcatAuthentication=false in the coyote connector, it

remote_user from mod_jk to Tomcat.   This works fine.  However, you get 
no roles--you need to roll your own roles (sorry) in each app.  I'd 
really like to (and assume others would as well) allow Apache (or whatever)
to set remote_user, and then use that with a nice, modular, pre-built 

authentication/realm implementation.  It would mean having to do some
parallel configuration in apache to match web.xml security constraints, but
we already have to do similar things to make mod_jk work, anyway.

It appears the connector builds its own Principal, Ajp13Principal, and 
sticks it into the request, but it knows nothing about implemented 
realms, so it ignores them.  I'm guessing I'd need to modify 
AuthenticatorBase to recognize some type of flag passed in the request 
(from the connector setup), and some generic realm password, so it can 
call the authenticate method and fill in the roles.  Basically, it would
involve two new connector parameters, tomcatAuthmixed, and (possibly)
tomcatAuthmixed password.  The authenticator would (possibly) use the
generic password for all externally authenticated accounts, relying on the
external program for security, and all usernames would have to exist in the
existing realm user table.  (I think this opens up interesting possible uses
with the SSO valve for using both externally and internally authenticated
users..but that's another story).

So my questions are basically:  is there a better way?  1) that doesn't 
involve altering Tomcat or 2) has already been done or 3) alters Tomcat 
in a better way? 

Sorry this is so long, and thanks for any wisdom. 

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message