tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Warnier>
Subject Re: Single sign on issue with Tomcat and Apache
Date Thu, 05 Jun 2008 20:09:59 GMT

sridharmnj wrote:
> - there is only one Apache, and one Tomcat, on the same physical server
> yes
> - there are no Apache VirtualHosts (or there is only one), and there is 
> only one Tomcat <Host> section in server.xml
> Apache virtualhost is there, and tomcat host is <Host name="localhost"...
> - the back-end for the authentication is the same MySql database system, 
> and the same table.  In one case it is accessed by an Apache module 
> (mod_auth_mysql), in the other by some Java module under Tomcat (that's 
> my own weak point by the way, I'm not really a Java/Tomcat guy)
> yes, authentication is mysql database
> - there is only one single DNS domain (which simplifies certain issues)
> yes like
> - all authentication is of type "Basic", which means based on the 
> exchange of HTTP headers from browser to server.
> No, aaa is based on FORM authentication, and it should not be changed
> Hmm, I am sorry, if I mislead you. aaa is based on FORM authentication only
> and my client doesnot want to chage it.

As Johnny and I are telling you in different words but with the same 
meaning, you are mixing two different kinds of authentication, and 
Apache (and the browser) unfortunately never see the authentication that 
happens with the Tomcat FORM method.  And there is even no way, at the 
Tomcat level, to pass this information back to Apache (and neither does 
it need to be passed back to Apache, it should passed to the browser, 
see below).

Or, let me put this another way, there is no simple way, using just the 
standard Apache and Tomcat configuration and standard add-on modules.

If your client absolutely wants to keep the FORM authentication for aaa, 
and still wants to have a single-sign-on between the 3 areas 
aaa/ccc/bbb, then the other solution would be to change the 
authentication method for bbb and ccc.

One general solution, roughly outlined in one of my previous emails : do 
all the authentication(s) at the Apache level, and pass the Apache 
authentication to Tomcat.
You could do something, at the Apache level, that will authenticate the 
user always with a form (for aaa/bbb/ccc), and it could even be the same 
"look" as the login.jsp currently used on Tomcat/aaa.  And it would be 
single-sign-on for all aaa/bbb/ccc.
That would be the "cleanest" solution.
(Note : the Tomcat applications would still be protected and 
authenticated.  They just would no longer handle the login dialog 

Or, another solution : cut out Apache, and use Tomcat also as the HTTP 
server for the static pages of bbb.  If what happens on Apache is no 
more than serving static html pages for bbb, Tomcat can do that too. 
And this way, you could protect bbb by a Tomcat-level Basic 
authentication, and it would also fall within your Tomcat single-sign-on.

Or, leave Apache in-between, but have it pass all requests for "bbb" to 
Tomcat also (like it does for aaa and ccc), and serve the static pages 
from Tomcat, subject to basic authentication on Tomcat.  This way, after 
the first authentication, no matter where in aaa/bbb/ccc, Tomcat would 
know and keep the authentication even if you later switch between 

In Basic authentication, it is the browser basically that decides to 
send the "authorization : Basic U3JpZGabkyuUZXN0aW5n " header, in 
function of what it knows (that the realm "xxx" requires authorization). 
  It knows that, because in a previous attempt to access this same 
realm, it received a 401 response from the server, telling him 
"authorization required for realm "xxx".
But in your case, when the user accesses "aaa" first, the browser never 
receives a 401 response, so it never knows that it must send the 
"authorization" header, and it never does.
So when you go from aaa to bbb, it does not send the header either, even 
if the realm is the same, because it does not know (yet) that an 
authorization is required.  The result is that Apache sends back a 401 
response then, and the result of that is that the browser pops up the 
login dialog (again).
That's a bit simplified, but it's the essence.

On the other hand, Tomcat *never* sends any authentication information 
back to Apache.  When you access ccc first, it is Tomcat that sends the 
401 response to the browser, and that is how *the browser* then "knows".
Apache never "knows".



To start a new topic, e-mail:
To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message