Mailing-List: contact users-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Users List" <users@tomcat.apache.org>
Received-SPF: pass (nike.apache.org: domain of lists@nabble.com designates
 216.139.236.158 as permitted sender)
Message-ID: <17678997.post@talk.nabble.com>
Date: Thu, 5 Jun 2008 13:37:25 -0700 (PDT)
From: sridharmnj <sridharmnj@yahoo.co.in>
To: users@tomcat.apache.org
Subject: Re: Single sign on issue with Tomcat and Apache
In-Reply-To: <48484817.50704@ice-sa.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
References: <17633391.post@talk.nabble.com>
 <3A55348B50FD2A40AAA40ABA16C6B6D60E7CDA88@EXNJMB23.nam.nsroot.net>
 <025501c8c66e$2a6ba8e0$0300000a@animal> <48478F67.4040509@pidster.com>
 <17671253.post@talk.nabble.com> <48480B6D.7050602@ice-sa.com>
 <17674656.post@talk.nabble.com> <48484817.50704@ice-sa.com>


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=
=20
Tomcat also (like it does for aaa and ccc), and serve the static pages=20
from Tomcat, subject to basic authentication on Tomcat.  This way, after=20
the first authentication, no matter where in aaa/bbb/ccc, Tomcat would=20
know and keep the authentication even if you later switch between=20
aaa/bbb/ccc.=20

I am planning to move bbb (Apache static pages) to Tomcat and make it Tomca=
t
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:
>=20
>=20
>=20
> 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=
=20
>> only one Tomcat <Host> section in server.xml
>> Apache virtualhost is there, and tomcat host is <Host name=3D"localhost"=
...
>> - the back-end for the authentication is the same MySql database system,=
=20
>> and the same table.  In one case it is accessed by an Apache module=20
>> (mod_auth_mysql), in the other by some Java module under Tomcat (that's=
=20
>> 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=20
>> 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.
>>
>=20
> As Johnny and I are telling you in different words but with the same=20
> meaning, you are mixing two different kinds of authentication, and=20
> Apache (and the browser) unfortunately never see the authentication that=
=20
> happens with the Tomcat FORM method.  And there is even no way, at the=20
> Tomcat level, to pass this information back to Apache (and neither does=
=20
> it need to be passed back to Apache, it should passed to the browser,=20
> see below).
>=20
> Or, let me put this another way, there is no simple way, using just the=
=20
> standard Apache and Tomcat configuration and standard add-on modules.
>=20
> If your client absolutely wants to keep the FORM authentication for aaa,=
=20
> and still wants to have a single-sign-on between the 3 areas=20
> aaa/ccc/bbb, then the other solution would be to change the=20
> authentication method for bbb and ccc.
>=20
> One general solution, roughly outlined in one of my previous emails : do=
=20
> all the authentication(s) at the Apache level, and pass the Apache=20
> authentication to Tomcat.
> You could do something, at the Apache level, that will authenticate the=
=20
> user always with a form (for aaa/bbb/ccc), and it could even be the same=
=20
> "look" as the login.jsp currently used on Tomcat/aaa.  And it would be=20
> single-sign-on for all aaa/bbb/ccc.
> That would be the "cleanest" solution.
> (Note : the Tomcat applications would still be protected and=20
> authenticated.  They just would no longer handle the login dialog=20
> themselves).
>=20
> Or, another solution : cut out Apache, and use Tomcat also as the HTTP=20
> server for the static pages of bbb.  If what happens on Apache is no=20
> more than serving static html pages for bbb, Tomcat can do that too.=20
> And this way, you could protect bbb by a Tomcat-level Basic=20
> authentication, and it would also fall within your Tomcat single-sign-on.
>=20
> Or, leave Apache in-between, but have it pass all requests for "bbb" to=
=20
> Tomcat also (like it does for aaa and ccc), and serve the static pages=20
> from Tomcat, subject to basic authentication on Tomcat.  This way, after=
=20
> the first authentication, no matter where in aaa/bbb/ccc, Tomcat would=20
> know and keep the authentication even if you later switch between=20
> aaa/bbb/ccc.
>=20
> In Basic authentication, it is the browser basically that decides to=20
> send the "authorization : Basic U3JpZGabkyuUZXN0aW5n " header, in=20
> function of what it knows (that the realm "xxx" requires authorization).=
=20
>   It knows that, because in a previous attempt to access this same=20
> realm, it received a 401 response from the server, telling him=20
> "authorization required for realm "xxx".
> But in your case, when the user accesses "aaa" first, the browser never=
=20
> receives a 401 response, so it never knows that it must send the=20
> "authorization" header, and it never does.
> So when you go from aaa to bbb, it does not send the header either, even=
=20
> if the realm is the same, because it does not know (yet) that an=20
> authorization is required.  The result is that Apache sends back a 401=20
> response then, and the result of that is that the browser pops up the=20
> login dialog (again).
> That's a bit simplified, but it's the essence.
>=20
> On the other hand, Tomcat *never* sends any authentication information=20
> back to Apache.  When you access ccc first, it is Tomcat that sends the=
=20
> 401 response to the browser, and that is how *the browser* then "knows".
> Apache never "knows".
>=20
>=20
> [...]
>=20
>=20
> Andr=C3=A9
>=20
>=20
> ---------------------------------------------------------------------
> To start a new topic, e-mail: users@tomcat.apache.org
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>=20
>=20
>=20

--=20
View this message in context: http://www.nabble.com/Single-sign-on-issue-wi=
th-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: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org