my dog learned polymorphism*
The moose likes Tomcat and the fly likes FORM based authentication problem Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Murach's Java Servlets and JSP this week in the Servlets forum!
JavaRanch » Java Forums » Products » Tomcat
Bookmark "FORM based authentication problem" Watch "FORM based authentication problem" New topic
Author

FORM based authentication problem

Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 15950
    
  19

OK, it's my turn! I've been working with FORM-based authentication since about 2000 on Windows, Linux, Solaris and maybe even the odd IBM iSeries. No problems. Until now.

I have one (and only one) server at a particular hosting provider that is positively off the wall. When I access a secured resource, it doesn't present the login form. Instead it pops up a Dialog, meaning it's attempting BASIC instead of FORM. It does authenticate - only valid user IDs and passwords are accepted. However, it doesn't honor security roles!

We upgraded the OS, I installed a fresh copy of Tomcat and the latest Sun, er, Oracle JVM. No change. I switched the proxy off Apache, set up a firewall redirect from port 443 to 8443 to compensate, verified that 443 wasn't being listened to and 8443 belonged to Tomcat. Checked the 8443 Connector parameters. All good.

This is an app that works just fine on my desktop and development server, although I don't route through Apache on those systems. I've got other systems at the same hosting service that don't have a problem with form-based authentication. I'll admit that since there are other fingers in this particular pie, there may be things going on I don't know about, but if there ARE, I need to know them, and I haven't a clue.

Anybody ever seen anything like this before?

Customer surveys are for companies who didn't pay proper attention to begin with.
Christophe Verré
Sheriff

Joined: Nov 24, 2005
Posts: 14687
    
  16

web.xml is correctly deployed, isn't it ? It contains the form authentication settings ?


[My Blog]
All roads lead to JavaRanch
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 15950
    
  19

Nothing so simple, alas. My desk, test and production WARs are the exact same file. Only production misbehaves.
Jaikiran Pai
Marshal

Joined: Jul 20, 2005
Posts: 9915
    
158

Tim Holloway wrote:
We upgraded the OS, I installed a fresh copy of Tomcat and the latest Sun, er, Oracle JVM. No change. I switched the proxy off Apache, set up a firewall redirect from port 443 to 8443 to compensate, verified that 443 wasn't being listened to and 8443 belonged to Tomcat. Checked the 8443 Connector parameters. All good.
....
I'll admit that since there are other fingers in this particular pie, there may be things going on I don't know about, but if there ARE, I need to know them, and I haven't a clue.




Maybe enabling the AccessLogValve on that Tomcat instance might give a hint probably. At the very least it will prove that the request is infact being handled by that instance.


[My Blog] [JavaRanch Journal]
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 15950
    
  19

Doesn't seem to be much doubt that what security applies is being handled by Java, since there's no other place where the necessary config to validate userid/passwords in the database occurs. But the Valve idea is a good one. I have been wondering if the actual Realm processing isn't being completely bypassed and the login is somehow being presented by old DIY security code that wasn't destroyed back when I first overhauled this puppy. Tracing URL requests may prove instructive.
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 15950
    
  19

I found it:


This was SUPPOSED to enhance performance in JSF. Without it, roughly a Megabyte of JavaScript code is repeatedly downloaded per page because Tomcat ruthlessly suppresses cacheing directives when SSL is in use (there's a reason for it, but not one that applies here).

What is ALSO decided to do on this particular server was silently force the BASIC authenticator to be used instead of the FORM authenticator. So I've turned it off for the moment and now I have to see if there's a related option for form-based authenticators.

What makes this really bizarre is that the cache suppression suppression is a characteristic I don't want on login (authentication), but on post-login pages where I'm already authenticated. But that little nuance doesn't seem to be accounted for.
 
 
subject: FORM based authentication problem
 
Similar Threads
Tomcat authentication and RACF
how to redirect to success page in tomcat using its lapd configuration
Socket bind failed
How to enable SSL for only one site in Tomcat
Tomcat HTTP to HTTPS redirect with VIP issue