Cluster and authentication

Monday 25 February 2008 2:42:53 am

As long as all frontal servers are connected to the same backend database, and you are nout using https, session affinity is not needed.

Typical scenario:
+ user goes to site, hits server A
+ server A sets cookie to user, creates a row in the session table in the db
+ user goes to page 1, hists server B - he sends the session cookie (since all frontals are hidden by the load balancer, the server names is still the same for the end user)
+ server B receives session ID, looks it up in the DB, and finds session in there
+ all is fine ;)

Principal Consultant International Business
Member of the Community Project Board

Monday 25 February 2008 7:45:51 am

Gaetano-

I'm curious what the effect is if the server does use https. Is it only an issue if the session goes from http to https? Would there still be a problem if the entire session used https?

I am relatively new to ezPublish. I have not been able to track down much information about session management and user authentication. Can you point me the way to some documentation on the subject?

Thanks!

Tuesday 26 February 2008 1:40:02 am

<i>I'm curious what the effect is if the server does use https. Is it only an issue if the session goes from http to https? Would there still be a problem if the entire session used https?</i>

The main problem with https is where does the encrypted session end.

If the load balancer terminates the https session, forwarding http to the webserver pool then you have some nifty advantages:
- you install the ssl certs on the lb only
- the webservers are relieved of the ssl ciperhing load (lb will do it in hw if you buy add on cards so it is much more efficient)
- since the lb can look at the decrypted request, it can apply session affinity/stickiness if he wants to

If the load balancer does not terminate the https, I am not 100% sure, but what should happen is that either
a) once the ssl session is initiated, it will stick to the same real webserver, since ssl operates at a level just below tcp/http headers. So it should work, but you will not be spreading the load across your server pool. Also, in case that particular webserver goes down, the client will have to hit "refresh" to initiate a new ssl session to a different one
or
b) the different https requests of a user session end up on different web real servers. Every time a new SSL handshake takes place, since the SSL sesssion ID from server A will not be good for server B etc, and your webservers are under very high load (and pages seen by end user slower)

In any case you should definitely set keepalives on for https

Principal Consultant International Business
Member of the Community Project Board