PersistentIPCheck vs TransientIPCheck - What is the difference?

[Kevin Buckley]

We have been using TransientIPCheck for 10+ years. It causes havoc for off-campus users who may be using an AT&T Hotspot, or various networks beyond our control that use NAT with a pool of IP Addresses. Because they are outside our control we can't use the Proxy whitelisting feature.

 

I see there is another features called PersistentIPCheck. What is the difference between the two ACO settings?

[Legacy User]

TransientIPCheck is applied when SMSESSION is Transient in nature (OOB Default).

 

If we set PersistantCookies=YES in ACO, then SMSESSION becomes PERSISTANT in nature. Now PERSISTANTIPCHECK comes into play.

 

 

Thus by default in your scenario TransientIPCheck is applicable. So WebAgent tries to match IP in SMSESSION with Client IP accessing. If we need to use TransientIPCheck then front end load balancers needs to pass through the ClientIP. We could use CustomIPHeader in ACO to read the correct value which the front end is setting.

 

https://docops.ca.com/ca-single-sign-on/12-52-sp1/en/configuring/web-agent-configuration/web-application-protection/default-http-headers-used-by-the-product#DefaultHTTPHeadersUsedbytheProduct-HeaderVariablesandEnd-UserIPAddressValidation

[Kevin Buckley]

I don't completely understand - Does that mean you use TransientIPCheck when you use transient cookies and PersistenIPCheck when you use persistent cookies?

[Legacy User]

Correct. TransientIPCheck when you use transient cookies and PersistenIPCheck when you use persistent cookies

[kuyle01]

Not sure how deep you want to look - but the following provides a fairly good description

Verify IP Addresses - CA Single Sign-On - 12.52 SP1 - CA Technologies Documentation 

 

I also find this to be a handy URL : re ACO Parameters
List of Agent Configuration Parameters - CA Single Sign-On - 12.52 SP1 - CA Technologies Documentation 

[Legacy User]

https://docops.ca.com/ca-single-sign-on/12-52-sp1/en/configuring/web-agent-configuration/web-application-protection/default-http-headers-used-by-the-product#DefaultHTTPHeadersUsedbytheProduct-ConfigureIPAddressValidation

 

Refer to this doc note. This should help.

 

I often find that after a point if the request is being routed through too many proxies / firewall, it is simply best to turn off IPChecks. Because even with the ACO parameters for IP Validation behind proxies / firewall, it becomes difficult to manage the definitions. We could also selectively disable IPChecks on selective WebAgents using LocalConfig. We could also route external traffic to a different set of WebServer/WebAgent which has IPCheck disabled, but we could still maintain security through external means (e.g. NetScalers handling Internet Traffic) Hope this helps!

[Kevin Buckley]

Is it safe to turn off IPChecks? Even if just for internal traffic?

[Legacy User]

I have seen Customers even in Internal environment who are unable to turn on IPCheck because of the underlying network topology is so diverse & dynamic, that recording OR passing the actual clientIP is a challenge.

 

That being said we could supplement with other Security mechanism. It really depends on what security usecase we are trying to resolve and is IPCheck the only way to mitigate it.

[Kevin Buckley]

Our security use case is to avoid session stealing. We use transient cookies and are looking into Session Assurance, but it doesn't seem to be a production ready product.

[Ujwol]

Hi Kevin,

 

Just wondering , what feature do you see lacking in the current version of Session Assurance to be production ready for your use case ?

 

Just to let you know it's currently being used by various large enterprises in their production environment.

 

Regards,

Ujwol

[Legacy User]

Transient IP Check is not a full proof approach in itself, in addition to the cookie being hijacked, IP Addresses could also be spoofed. It good to have something than nothing, that is the extent of Transient IP Check in a nutshell layman term. But security has evolved and so has the Session Assurance feature. Not sure which version of CA SSO you are on, but the Session Assurance feature on (new design) R12.6 / R12.7 is a lightweight and a better performant solution than the one in R12.52. Enhanced SA provides a much higher level of security than just a mere IP Check and is deemed more better fit / fuller solution to Session Hijacking.

 

https://docops.ca.com/ca-single-sign-on/12-7/en/configuring/policy-server-configuration/enhanced-session-assurance-with-… 

Configure Enhanced Session Assurance with DeviceDNA™ - CA Single Sign-On - 12.7 - CA Technologies Documentation 

 

Tech Tip : CA Single Sign-On :: Policy Server:How to Configure Enhanced Session Assurance 

Tech Tip : CA Single Sign-On :: CA Access Gateway::Introduction to the Redesigned Enhanced Session Assurance (12.6/12.7) 

 

Again as I mentioned, it is really dependant on how deep we need to dive to secure resource and how other supporting components (e.g. Networks, Proxies, LB's) align. From what I understand from the very first conversation, TransientIPCheck is working for all Intranet based access. The challenge is when the same URL is accessed from the Internet TransientIPCheck creates a havoc, because now the Client IP is masked by the intermediate components.

 

Like I mentioned here are the options

1. We could look at Enhanced Session Assurance. This should cater to both Internet and Intranet. But necessitates having CA AG (with Session Assurance) running in parallel to the WebAgent. 
2. Segregate Internet and Intranet Traffic. Internet Traffic goes to a Web Front end which does not do IP Check. All Intranet Traffic is routed to a Web Front end which enforces IP Check. In doing so, we retain the IP Check currently being done on Intranet and at the sametime cater to Internet Traffic as well. The Internet Traffic would be additionally secured using VPNs OR NetScalars OR Junipers, so relaxing the rules on the Internet facing Web Front end, should be mitigated.
3. Configure CustomIPHeader in WebAgent ACO. Configure proxies / firewall / LBs to pass through the ClientIP in a header. Default HTTP Headers Used by the Product - CA Single Sign-On - 12.52 SP1 - CA Technologies Documentation