Has anyone deployed Session Assurance in a large enterprise environment?
How is performance?How did you handle load balancing? With Sticky Sessions?
How easy is it to remove on SA server from rotation for maintenance? Does that cause user interruptions?
What did you use as an accurate Health Check?
I will let others to answer their experience.
But just to be clear, can you confirm your Policy server and CA Access Gateway version.
There were significant changes pertaining to session assurance functionality in 12.6.
I have briefed about this here : Tech Tip : CA Single Sign-On :: CA Access Gateway::Introduction to the Redesigned Enhanced Session Assurance (12.6/12.7)
I would strongly recommend going for the 12.6 or higher version of session assurance.
Our test environment is on 12.7 for both and prod is currently running 12.6 for both.
For Access Gateway generally if you have a load balancer out the front it is advisable to use sticky sessions, since the Ag does maintain an in memory session lookup,although this is more of a cached value. The Ag will work without sticky sessions but you do end up with taking more memory, since you have the SMSESSION and Az cache values in whatever Ag servers you visited, so Ag is more efficient with sticky session load balancer out the front than without.
However, usually the sticky session is more important with the backend servers that Ag passes the request onto, often if itis JBOSS or IIS or other, they have their own in-memory session (keyed by JSESSIONID, ASPSESSIONID etc) and if you visit a new backend server (which may happen if you go via a new Ag server), then you can find yourself in terminated session.
The same would also apply to a backend AA, if you have two Ag servers and they each talk to a different backend AA server, then any AA server session information will not be shared. Again I believe (but will defer to Ujwol
who is the AA SME) that AA may also be configured so that it will cope with multiple backends, since the information is stored in the policy store session store, but probably would be less efficient.
So net result is sticky session load balancer in front of SPS would generally be advisable.
For health check for SPS, it is best to have a URL that goes through to the backend, so that you are sure the whole pathway is working.
Cheers - Mark
----Mark O'DonohueSnr Principal Support Engineer - Global Customer Success
There is no external Advanced Authentication server integration involved here.
It is the simplified version of the Risk Authentication inbuilt within the Access Gateway.
Hi Ujwol, thanks for the clarification, with your background in AA, and experience with the redesigned session assurance, your probably best placed to give them some advice on any limitations with load balancer, and a benign URL to test that it is working. So, I will leave this question to you.
Tech Tip : CA Single Sign-On :: CA Access Gateway::Introduction to the Redesigned Enhanced Session Assurance (12.6/12.7)
Cheers - Mark
My personal thoughts.....
How is performance?
Between Session Assurance in R12.52 and R12.6 / R12.7; the performance in the feature itself is improved quite drastically. The reason is the light weight solution minus the Risk Manager is no longer running alongside the Policy Server. Also good improvements in CA Directory as a Session Store functional logic.
Between a none Session Assurance setup and enabling Session Assurance, there will be some added latencies. This is mainly due to the fact we are introducing an additional 302 redirect to the Session Assurance App on CA Access Gateway and also addition of Session Store. However this is not a valid performance comparison use case i.e. comparing non SA setup performance and SA setup performance.
How did you handle load balancing? With Sticky Sessions?
Mark has explained this beautifully in the blog reply and I do agree with the thoughts. However I do carry a certain level of caution if we do go down the route of sticky session it needs to tested appropriately. The name sticky is because it really sticks, therefore we shouldn't be in a scenario wherein one CA Access Gateway is getting blasted away by all User request because of stickiness. What cautions me is CA Access Gateway not only serves the Session Assurance content but also a variety of other functions (WAOP / AuthAz WebServices / Proxy functions). If the same CA Access Gateway is being used for all these functions, then I'll be concerned on enabling Sticky Sessions unless we could segregate sticky based on VH / functions.
Alternatively, I would probably categorize clusters of CA Access Gateway based on Job functions. E.g. I'd keep a cluster primarily for Session Assurance, AuthAz WebServices, WAOP (In a way this is similar to the concept of Centralized Authentication Server which does purely the login / Auth) and I'd keep another cluster for Proxy functions. Though this is primary categorization, I'd also make sure if & when needed, I can added capacity by routing traffic across cluster for temporary surges. To be able to do this, even though there is categorization, we need to ensure we build all CA Access Gateways across the cluster at the same configuration level.
If we have a load balancer in front of a pool of CA Access Gateway server, taking a single CA Access Gateway outside the Load Balancer pool for maintenance should have no impact. The load balancer has to be smart to re-route the traffic to the active CA Access Gateway servers. This is same rule for anything that is served off the CA Access Gateway (e.g. WAOP). What we define in the Session Assurance end point configuration on the Policy Server is a end point URL. The Web Server name can also be the Load Balancer VIP FQDN.
You can use keep alives. There are various tech-notes on how to deploy pages on CA Access Gateway.