Thank you very much for your informative comments. In terms of breaking an application into single servlets, I agree that there would need to be strong reasons for doing it, and the clear one that springs to mind is the requirement to have different authn methods for each, None, Form, and http basic. But I take your point on board.
I really want to leverage as much flexibility between apache and tomcat but keep the dependencies and configuration to a minimum. I dream of a time where I can be lazy in the future. (Fat chance) Is there a lack of form-based authentication module (production ready) for apache or am I just really bad at finding things? I would really like to force apache to do as much as possible of the ssl and authn and leave tomcat to handle the actual work! Regards, Tony On Mon, 16 Nov 2009 21:07 +0000, "Pid" <p...@pidster.com> wrote: > On 16/11/2009 17:53, Anthony Jay wrote: > > Hi, > > I am in need of some advice. My current setup is a web application > > running on Jboss which serves static and dynamic content, jsp, > > servlets and xml on two non load balanced servers (hot spare using > > mysql replication). It currently uses Http Basic Authentication over > > SSL. This has been fine to date but since I dont use any of EJB or > > related features I think that it is overkill for my application, as > > well as being unflexible w.r.t. deployment and content management as > > the whole site is deployed as a single EAR. Initially it was > > fantastic as it was simple and easy to maintain but now every change > > requires a full build. > > > > I am researching porting my site to Apache 2.2 and Tomcat, and hope to > > gain the following. > > 1. Serve the static content from apache e.g. images, clips sound, text > > files etc. > > 2. Install a CMS to offload content managment to others and also blog > > functionality, Wordpress seems to be the tool of choice for ease of > > usage and widespread usage, this seems to work fine in my test > > environment. > > > > 3. Maintain current servlet and jsp (including xml) functionality on > > tomcat. Instead of one super application I can deploy servlets as > > seperate applications and update them seperately. > > One servlet per application probably isn't an optimal solution. > Breaking a single large app into smaller components may be worth it - > very much depends on your application. > > > 4. Use connectors such as mod_jk to load balance and provide failover. I > > already have heartbeat and mod_jk installed on in high availabilty mode > > using workers in a test environment and this is working as expected. > > (Apache 2.2 and tomcat 6 running on centos 5.3). > > > > At this point I have hit a brick wall w.r.t. what to do next. I have > > been researching this for the past two weeks and the more I learn the > > more I seem to be confused. > > What are you confused about? > > > There is so much documentation on some > > things but almost none on others. I always fear that if there is nobody > > asking questions about a certain topic it either means that a) There are > > no problems using the technology or b) Nobody is using it at all. > > There are lots of questions about mod_jk on this list each week. > Sometimes they're even different ones. ;) > > > My main issue now is about how the authentication works between Tomcat > > and Apache. > > It's one way, Tomcat, as an 'inner' component, can defer to > authentication set at the outer level in Apache HTTPD. > See the "tomcatAuthentication" attribute of the AJP connector. > > http://tomcat.apache.org/tomcat-6.0-doc/config/ajp.html > > Tomcat can't pass it's authenticated principal up to HTTPD. > > > > I would like to use both Form based and http basic authentication on > > protected resources running on both apache and tomcat. > > You would probably need to seperate those parts into separate > applications as FORM and BASIC can only be set once in each web.xml. > > (You can of course duplicate the same class or jar in differently > configured web apps.) > > > i.e. Form based for humans and httpbasic for XML requests over ssl. > > I have a user database in mysql containing username and password, roles > > are in another table but these could be merged if required. > > > > I also am confused by mod_jk and mod_proxy_ajp, they, seem to have much > > feature overlap. mod_proxy_ajp in my view suffers terribly from the > > missing "*.jsp" wildcard capability but has a much simpler configuration > > and better future prospects as it is bundled with apache 2.2. > > They offer similar, largely overlapping functionality, you choose one or > the other. > > mod_proxy_ajp can of course handle "*.jsp", when combined with > mod_rewrite and the [P] proxy rewrite command. > > RewriteRule ^/(.+)\.jsp(.+)? ajp://tomcathost/$1.jsp$2 [P,L] > > > In terms of authentication, which should I use, mod_auth_mysql and > > mod_auth_dbm (or mod_auth_form in future or something else?) and why? > > Up to you. > > > In terms of single sign on how can I make the user experience seamless > > between static content-managed pages and jsp/servlets? Will mod_jk > > handle sso? This does not seem clear to me in all the pages I read. If I > > configure form based auth in a login.jsp page will this be relayed to > > apache after a redirect? > > If you're using FORM (or BASIC) as your primary auth, then HTTPD should > only serve unprotected content, as additional auth will be required. > > > What is best practise and what should I be doing? If there is some hard > > to find documentation out there with pointers and tips I would > > appreciate a few links. Expert advice is appreciated. > > Tony > > Sounds like you've got the right idea so far. > > > p > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > > For additional commands, e-mail: users-h...@tomcat.apache.org > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
