Many thanks!! I am planning to follow the below approach only.
>>> 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. I am planning to move bbb (Apache static pages) to Tomcat and make it Tomcat Basic authentication. So I can access aaa/bbb/ccc. This seems to be the best solution for me. (Because, there are some other applications which are running on tomcat and this may be useful for future enhancements also) Now I am looking on feasibility of moving those pages to Tomcat. Thanks to you all and thanks to the wonderful forum. awarnier wrote: > > > > 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] > > > -- View this message in context: http://www.nabble.com/Single-sign-on-issue-with-Tomcat-and-Apache-tp17633391p17678997.html Sent from the Tomcat - User mailing list archive at Nabble.com. --------------------------------------------------------------------- To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
