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 www.mywebsite.com
- 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
themselves).
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
aaa/bbb/ccc.
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".
[...]
André
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
