The permanent fix for the configuration level options to accommodate this change will be available in versions 13.0, 12.1, 12.0 and 11.1 and following are the targeted dates.
|ADC Versions||Release Target Dates||Status|
|13.0 52.24||March 24th 2020||Released|
|12.1 55.24||March 6th 2020||Released|
|12.0||March 27th 2020||Pending|
|11.1 64.11||March 25th 2020||Released|
The following are the available workarounds:
Workaround through Chrome
In Chrome 80 there is an option which will allow you to revert to the legacy cookie behavior. This will be available for at least 12 months after the release of Chrome 80 stable.
Refer to SameSite Updates for more information.
Workaround Steps for Case: 1 App cookie
One can configure a response-based rewrite policy to look into “Set-cookie” header in the response sent by the backend server and append the “SameSite” cookie attribute.
Sample rewrite policy looks like:
add rewrite action rewrite_http_header replace_all http.RES.full_Header ""SameSite=None; Secure; path=/"" -search "regex(re!(path=/\; SameSite)|(path=/)!)"add rewrite policy append_samesite_cookie "http.RES.HEADER("Set-Cookie").EXISTS" rewrite_http_header
above rewrite policies needs to be bound application specific virtual server on Citrix ADC.
Workaround Steps for Case: 2 ADC cookie (Persistence Use case)
Currently there are two workarounds to prevent breakage if any (due to the chrome update) to applications with COOKIEINSERT persistence configured on LB vserver.
1. Use response RULE based persistence
If the back end application sends a unique cookie for each of the client session, Citrix ADC can use this unique cookie value as a key and create a RULE based persistence entry storing the back end server information corresponding to the cookie received. When the client request comes back with this Cookie, Citrix ADC will use the cookie value as the key and fetch the corresponding back end server to forward the request, hence maintaining the stickiness as achieved by COOKIEINSERT persistence. This approach works only if the back end server sends a unique Cookie key:value pair for each client in the response.
Below is a sample config where back end server sends cookie with the key as SESSIONID. The SESSIONID in the below config must be replaced with the unique cookie key sent by the back end.
set lb vserver lbvs -persistenceType RULE -rule "HTTP.REQ.COOKIE.VALUE("SESSIONID")" -resRule "HTTP.RES.SET_COOKIE.COOKIE("SESSIONID").VALUE(0)"
Note: The persistence timeout value must be chosen appropriately based on the application requirement.
2. Two Tier topology with a new Citrix ADC front ending the existing Citrix ADCs
Customer can have a two-tier topology with a new Citrix ADC front ending the traffic for the tier-2 Citrix ADC (existing Citrix ADC). The first tier Citrix ADC does response rewrite to include the SameSite attribute for all the cookies received from the tier-2 Citrix ADC.
There are no configuration changes required on the tier-2 Citrix ADC.
Below is a sample configuration on the tier-1 Citrix ADC.
enable feature lb rewriteadd lb vserver tier-1-lb <protocol> <IP> <port>add service tier-2-lb-svc <tier-2-vserver-IP> <tier-2-vserver-protocol> <tier-2-vserver-port>bind lb vserver tier-1-lb tier-2-lb-svcadd rewrite action rewrite_http_header replace_all http.RES.full_Header ""SameSite=None; Secure; path=/"" -search "regex(re!(path=/\; SameSite)|(path=/)!)"add rewrite policy append_samesite_cookie "http.RES.HEADER("Set-Cookie").EXISTS" rewrite_http_headerbind lb vserver tier-1-lb -policyname append_samesite_cookie -priority 10 -type RESPONSE
Note:- This should work even if the back end server does not include any cookie of its own.
We are reviewing on any other ADC use case which may have impact due to the change in default Chrome behavior, Document will be updated with Impact and mitigation steps accordingly.