OpenAM Session Stickiness Concept - Part II

If you follow my previous blog on OpenAM Session Stickiness Concept, when will the MQ Cluster get into the picture?

The following is what I have lifted from OpenAM documentation. That explains all.

OpenAM gets balanced through load-balancer, where OpenAM generates a specific load balancer cookie that they can use to implement sticky balancing. If a user gets balanced to a different instance, OpenAM will first use cross-talk to that original OpenAM instance to see if the latest session information is available. If that instance doesn’t reply (because it may be down) than the OpenAM instance will fall back to its session store and see if the session information got replicated. If the information is still not there, then OpenAM will simply consider this a new request and initiate an authentication step. 

The following illustrates the flow:

(1) : User tries to access OpenAM. The load-balancer redirects him to OpenAM 1.
(2) : User will be prompted to authenticate. OpenAM 1 creates a session and stores it in CTS
(3) : The same session is persisted into the MQ Cluster via the AM Session Failover (AMSFO) component. MQ Cluster consists of a pair of Java Message Queue servers. OpenAM will only write to Java Message Queue 1 since it is configured as the Primary node.
(4) : Upon receiving the session information, Java Message Queue 1 will broadcast to Java Message Queue 2 since it is configured as the Secondary node. This ensures the same session information can be retrieved by any OpenAM instance if Java Message Queue 1 suddenly goes down.


The above architecture ensures the high-availability of user sessions in OpenAM SSO infrastructure. Nice isn't it?

.