Is your application deployed on multiple data centers to allow high availability of the application and minimize any kind of outage (planned/unplanned) any impact on end users?
Do you think this is enough?
Are the users still complaining of abrupt & forceful session expiry?
Are you struggling to stick the user sessions to a data center (where the user session was initially created)?
The solution is Site Affinity or Session Stickiness or Data Center Affinity.
Let's talk about using a real life scenario.
Bank XYZ has a web application to serve the customers online. For higher availability, the bank decided to host the server having a web application in 2 data centers, say DC1 and DC2, at different physical locations/sites synced with each other so that the servers have the same configuration and at all times.
Since the website domain is served by 2 different data centers, the local DNS server (e.g. F5 GTM) has 2 entries against the domain/hostname of the website. This hostname is mapped to the public IP addresses of the service running on DC1 & DC2.
When the user launches the site, client/browser sends a DNS query to the ISP and ISP (if DNS entry not cached) sends the query to the DNS servers. The DNS service responds with the IP address of any one of the data center. The IP address is then cached by the ISP.
Then a TCP connection is set up between the host and the server. Assuming ISP returns the address of DC1, the request (HTTP) is sent to the server located at Data center DC1. Once the user is logged in, there will be a session id created for the user session (typically JSESSIONID &/or LtpaToken cookie that contains the user session id). This session-id is used to track the user journey & used by the application to authenticate each request.
Please note: The session-id is unique for each client/user session & valid only for the application instance that created the session-id.
Let's see what happens to the cached IP address at the ISP level.
Subsequent requests from the client will then be sent to application instance/service in DC1, till either the TCP connection is valid or the DNS cache with ISP is valid (till TTL/Time To Live).
1. This is true for a client machine that is fixed & connected to the same ISP end point.
2. What if the user is using a mobile device & traveling (say on a train). The ISP end point keeps changing every few seconds & chances are the DNS cache doesn't exist.
In both the above 2 cases - when the client/ISP resends the DNS query to the DNS servers, there is a 50% probability that the response of the query will be IP address of the application instance in DC1 & 50 % chances it would be DC2.
All Good if the response is for DC1. The user can merrily stay logged in & access his/her account without any interference.
If the response is IP address for DC2, BOOOOM.
The user session is not valid for DC2 as the session-id (JSESSIONID) that is passed is not valid for the application instance in DC2. And, the user would be forcefully logged off & will have to re-login.
Imagine the state of the user when accessing his/her bank account while traveling on a train & he/she has to log in every few secs/mins. Sounds Frustrating, isn't it!!
The answer to the above problem is Site Affinity or Data Center Affinity.
OK, let's see what that means.
When a user session is created by the application instance on 1 Data Center (DC1 in case of the above example), all the requests from the client must be sent to that Data Center (DC1). This must happen till the user session exists (user logs out of the application or the session timeout expires).
There can be multiple solutions, a basic solution is to add the Data Center name/identifier to the user session-id & validate the same when the request reaches the application. If the request is not for that Data Center, the application must send that request (without processing it) to the application instance (either the public IP address via the internet or to the private IP address via LAN/WAN/intranet) running on the other Data Center where the user session was created.
Authored By - Raj Gagan Bhatia
TCS Cyber Security Practice