----- Original Message -----
From: "Simon Papillon" <[EMAIL PROTECTED]>
To: <users@tomcat.apache.org>
Sent: Thursday, June 12, 2008 7:11 PM
Subject: jk load balancing based upon ip address rather than session id
Hello,
I'm using jk 1.2.25 with tomcat 5.5.25 and apache 2.0 on one debian
box - 2.4.27-2-386 i686 GNU/Linux
I've set up 3 tomcat instances that receive requests from the jk
load balancer worker
I've implemented in the web application, a simple cross domain single
sign on (SSO) mechanism. This mechanism ties the different session ids
in
any single container together, regardless if they've originated from
different domains, for example:
sub1.mydomain.com
sub2.yourdomain.com
sub3.hisdomain.co.uk
No... thats where you going wrong, SSO means a million different things on
the web, and some systems do mean that, but on tomcat it means SAME domain,
different web apps in same tomcat.
When the domain changes, the browser forget the cookie... thats it.
The way the load balancer works is that is round robins on the domain... and
it maps on context not domain.
ie if you call Domain1/Webapp1
Then it will round robin Domain1/Webapp1 (machine1) Domain1/Webapp1
(machine2) Domain1/Webapp1 (machine3)
And its the same for other domains.... ie it round robins between the
virtual hosts you have set.
If you set STICKY SESSIONS... it still round robins... UNLESS the servlet
sets a cookie.
As soon as a session comes into play, the client (on that domain) continues
to hit the same machine... thus that machine remembers the client state.
TC's security uses "full domain temp cookies"... and the problem is that the
security comes before everything else, its no intercept-able.
ie that security will prompt before anything else gets at it... or you can
get at it.
If users never cross a domain... ie a nurse.hospital.com is always in her
domain.... the load balancing will work and so will TC's SSO, if they move
between webapps, in that domain.
But as soon as nurse.hospital.com links to doctor.hospital.com.... the
browser will not send the cookie and TC will challenge the browser.
And then it will round robin in that domain... unless a cookie is set....
then it sticks.
The way some of these other SSO (cross domain systems work)... is they set
partial domains... ie .HOSPITAL.COM (with a dot in front)
Then that cookie returns across all those domains.... and they put a
JSPECIAL_SESSION_ID in that.
Simple... except that you will not get past TC's default security to be able
to check it.... thus the cross domain security systems effectively rebuild
all the security.
If TC allowed... or a class could be overriden to set a partial cookie....
it would be cross domain SSO... I'm not sure it can be done easily.
And the problem is that if you mess with valves... the custom code may not
work in later TC's
There are systems out there that do it... but I forget the products... it
does mean not using TC's default security.
So... If the doctor want to check out the nurse... he has to log on... ;)
An interesting thought... if Apache could map...
All_Staff.hospital.com/doctor/webapp/ - could be remapped to -
doctor.hospital.com/webapp/
All_Staff.hospital.com/nurse/webapp/ - could be remapped to -
nurse.hospital.com/webapp/
I wonder if browser and virtual hosting would be happy... ha ha
Of course if nurse was a the end of your domain... all your problems
(crossing domains) would go away.
Nice brain bender... ;)
Note that TC actually does it right, because there are all sorts of security
considerations when cookies start going cross domain.
The other problem is that dotSubDomains... dont work on localhost, so the TC
guys probably dont do it because they want to stay sane.
Good luck... the problem is only thereif you cross domains... otherwise it
works I think.
--- Anything said above could be in error ---
---------------------------------------------------------------------------
HARBOR : http://www.kewlstuff.co.za/index.htm
The most powerful application server on earth.
The only real POJO Application Server.
See it in Action : http://www.kewlstuff.co.za/cd_tut_swf/whatisejb1.htm
---------------------------------------------------------------------------
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
