http - https - load balancer - web Server - app Server

I have some doubt about http https , webserver, load balancer etc . I have found different informations from different source ( net, book etc) but still cannot get a complete idea.

Everywhere I have found the following 2 items about http and https. (1) http is stateless, connection less ( http 1.1 keep-alive but still connectionless - as client/server can drop the connection anytime) (2) https stateful, connection based.

Questions: ========== (1) Now say I am using http. I have a web-request coming and I have stored some state info ( say username) in HTTPSession. Now when the call returns then I assume the http connection is gone as it is stateless and connection less. But when I fire a second request from the same session of the browser it gets the stateinfo I have stored in earlier request from httpsession. In Cade's book I have found that some info is sent with each request( cookie/URL rewriting) for the same session. Now if user disables the cookie in browser how webserver will behave? Will it automatically use url rewriting ( by tracking that user has disabled cookie) or it should be preconfigured in WebServer (which technique should be used) ? Or I am messing up something here?

Now a basic question related to this.. If WebServer uses URL rewriting then I should see it in the browser URL...isn't it?

(2) In https ( when using from browser) the external behavior is also same as I have seen. Is it saving cookie/url rewriting? So, if I disable cookie then also https will behave properly and no url rewriting will be needed as the connection is maintained in Client ? [Say the WebServer to AppServer communication is http ( not https ) ]

(3) Say I have a WebServer (IPlanet/ Sun One/IBM HTTP Server etc) deployed in one m/c ( serving as a proxy) and in 2 other machine I have 4 application Servers running ( 2 on each machine) [ diagonal cloning ] . I have fed the plugin ( which contains the info for all the 4 instances of App Server ) to the WebServer. Now when the http request comes to WebServer it chooses a App Server instance and redirects it to that. Now the subsequent http request should also be forwarded to that Server for Server affinity ( Because I have put some data in HTTPSession and I need to access it or I am using a StatefulSession Bean. Who is exactly doing this ? WebServer or WebServer plugin?

(4) In the scenario described above if the protocol is https is there any difference? Will it be automatically be directed to the proper app Server ( because it is stateful so it knows where to go) or the plugin will play the same role here? My doubt is - will https keep the information of the appserver also in Client or the appserver instance name is maintained in WebServer and a linking information is maintained in the Client ?

(5) Say if I have 2 proxy webServers and a hardware load balancer in front of it....and my first request has gone this path...(http request)[say I have used a statefulsession bean ]

Browser --> hardware loadbalancer --> WebServer 2 --> AppServer 4

I believe if I do not store any static content in WebServer and it is only used for proxy and using http (not https) then WebServers are not needed at all. Is my understanding correct?

But say now I have some static content in WebServer also, so I have WebServers in place. How my second request will reach AppServer 4. Who is responsible to store session information? Will all the consequtive request will go to same WebServer 2 ? Or it may go to WebServer 1 ? But the final destination should be AppServer 4. Here I am totally confused about the server affinity.

(6) If the above scenario is for https then I believe I will definitely need a proxy webServer (If not then SSL accelerator is needed in front of hardware loadbalancer...keep that issue aside).

So, the second request can also traverse the following path. Browser --> hardware loadbalancer --> WebServer 1 --> AppServer 4

(Because if SSL acclerator is not there then hardware loadbalancer will not be able to read the header information of the SSL request and it can forward the request to any of the WebServer proxy...then webserver plugin should decode the https request and forward the request to AppServer 4.)

2) I don't think https makes cookies and URL rewriting unnecessary. Your webapp still needs one of it to manage its session.

3) I think it must be the plug in. Because it only knows the other machines and their connection. But this is an implementation detail of the webserver -> appserver combination. I'm not really sure.

4) I'm not really sure here either. But I guess it's also the plug in. Because the client can't know that there are other servers behind. The fact that there are more than one appservers is hidden to the client (it's transparent).

5) What exactly do you mean by webserver here? A simple webserver for static content or the webcontainer of an appserver? The connection to your statefull session bean is your remote object reference. You have to keep this remote object reference in your http session to associate it with your client requests. So if you answer your question about the affinity of the http session then the affinity to your SSB is solved.

6) See answer 2). I don't think https session management is different to http. You still need a cookie or URL rewriting. The fact that https is statefull doesn't change the implementation of the session management in your webcontainer.

I hope I could help you with my answers. I'm not quite sure with all of it but it's my best guess.

roy siju

Greenhorn

Posts: 19

posted 12 years ago

Hi Peter,

I have some doubt about point 2 and point 6. In Cade's book it is written ...In Protocols chapter... Cookie and URL rewriting both can compromise security in case of http.

From Cade's Guide: ----------------- "SSL connection also provides a maintenance of state between one request and the next. Using the state in the SSL connection at application level avoids the security problems associated with cookies or URL rewriting"

Regarding point 5 ... In my project we have 1 web server ( SunOne WebServer ) where we have kept the static contents ( like html, javascripts, images , css etc) and the dynamic request gets forwarded to Application Server ( WAS 4.0 Which has both WebContainer and EJB container..So, Servlet , JSP, EJBs are all in AppServer ). Here I was thinking that if we would have 2 SunOne WebServer and a hardware load balancer in front of it...what will happen?

Thanks Roy

Peter Storch

Ranch Hand

Posts: 74

posted 12 years ago

Originally posted by roy siju: From Cade's Guide: ----------------- "SSL connection also provides a maintenance of state between one request and the next. Using the state in the SSL connection at application level avoids the security problems associated with cookies or URL rewriting"

Yes, HTTPS (SSL) avoids the security problems, because with http the cookies and URLs are submitted in plain text over the network. But this doesn't affect the session handling of the web container.

Originally posted by roy siju:

Regarding point 5 ... In my project we have 1 web server ( SunOne WebServer ) where we have kept the static contents ( like html, javascripts, images , css etc) and the dynamic request gets forwarded to Application Server ( WAS 4.0 Which has both WebContainer and EJB container..So, Servlet , JSP, EJBs are all in AppServer ). Here I was thinking that if we would have 2 SunOne WebServer and a hardware load balancer in front of it...what will happen?

So the SunOne WebServers have the WAS Plugins installed, but there is a load balancer (extra machine) in front of it? Ok, then the Load balancer has to handle the session affinity otherwise the AppServers have to share their session information (synchronizing, uh oh complex topic).

Does every WebServer (PlugIn) also know every AppServer? That would make it even more complex. Then you have a two stage load balancing here? I give up.

roy siju

Greenhorn

Posts: 19

posted 12 years ago

Hi Peter,

Thanks for your reply.

But I am still not clear about one point.

Bothering you guys too much...sorry...but I really want to make my concepts clear.

Say https is using url rewriting to handle the session.The URL will be shown as usual isn't it?

Now if from the same browser If I jump to another URL will it be able to read the my https url(referring url) and can break into the server "some.server.domain" . This problem is there with http ( Again mentioning Cade's book..protocol --> http--> url rewriting). So the security gets compromised... What benifit I am getting out of https to become a stateful protocol.

Thanks Roy

Peter Storch

Ranch Hand

Posts: 74

posted 12 years ago

Hi Roy,

Originally posted by roy siju: Now if from the same browser If I jump to another URL will it be able to read the my https url(referring url) and can break into the server "some.server.domain".

No, this is kind of browser policy. They never send a https URL as refferrer to another webserver. If they do, it's a security bug.

roy siju

Greenhorn

Posts: 19

posted 12 years ago

Hi Peter,

Thanks for the clarification....

Just a thought...

In the SSL handshake mechanism the following is one step:

================================================== "The client sends the ClientKeyExchange message. This is random key material, and it is encrypted with the server�s public key. This material is used to create the symmetric key to be used for this session, and the fact that it is encrypted with the server�s public key is to allow a secure transmission across the network. The server must verify that the same key is not already in use with any other client. If this is the case, the server asks the client for another random key." - Java 2 Network Security...

So, this key is residing both in Server and Client side and this is unique for all sessions. SSL mechanism can use this key to track the user session .....But may be some security violation will occur ...don't know!!!

Thanks Roy for this information. This feature must be supported by the webcontainer. As one stated in the other thread is that not all webcontainer have this feature. And cookies and URL rewriting works always regardless of http/https.