tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Johnny Kewl" <>
Subject Re: jk load balancing based upon ip address rather than session id
Date Fri, 13 Jun 2008 15:40:22 GMT

----- Original Message ----- 
From: "Simon Papillon" <>
To: <>
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:

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 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 links to 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 
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... - could be remapped to - - could be remapped to -

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 ---

The most powerful application server on earth.
The only real POJO Application Server.
See it in Action :

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

View raw message