I'm running into a problem using form-based authentication with Tomcat 5.5.9 
behind a Cisco CSS load balancer, and I'm hoping someone can point me in the 
right direction.

We've got Tomcat deployed on 2 nodes, not clustered, but load-balanced via NAT 
distribution by the Cisco device.  We want the site traffic to be secured with 
SSL, but the SSL is actually terminated in the load balancer for efficiency and 
to offload the encryption/decryption burden from Tomcat.

We also planned to use J2EE container-managed authentication using the 
form-based option.  This is where we're having problems.

When we reference secure content within the target web app with an HTTPS 
address, Tomcat serves back the configured Login page just fine.  When we 
submit the Login form, however, and authentication succeeds, we are redirected 
to the original resource over HTTP instead of HTTPS.

Since the SSL terminates in the load balancer, the Cisco device actually routes 
the request to Tomcat on the standard HTTP port (8080).  It appears that, after 
successful authentication by the container via the Login form, Tomcat redirects 
the user to the original resource URL with the HTTP protocol instead of HTTPS, 
because Tomcat doesn't know about the HTTPS address intercepted by Cisco.  To 
Tomcat, the requests all come in looking like plain old HTTP.

Just for grins, I tried setting transport-guarantee = CONFIDENTIAL in my 
web.xml.  It didn't work, just created a Catch-22 where Tomcat tries to 
redirect to HTTPS but Cisco intercedes and forwards the request to Tomcat as 
HTTP.  I spoke with our Network engineers, and they don't believe they can do 
anything about this on the Cisco side.  They believe it's a web server / Tomcat 
issue.

Once I'm into the app, I can type the "s" after "http" in the browser's 
location bar to "switch back" to SSL.  Clicking links with relative URLs in the 
pages appears to stick with the HTTPS protocol after that.  It's only the 
initial container-managed login and redirection to the original requested 
resource that seems to cause the protocol switch.

Any advice is greatly appreciated.  Thanks!


Brian Burt
Enterprise Application Engineer
Gordon Food Service
e-mail: [EMAIL PROTECTED] 
office phone: 616-717-6972


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to