I'm looking to better understand what exactly need to be changed in SiteMinder and agents to support Chrome 80.  We do use your cookie providers and my understanding is this flow will break.  We are not using SiteMinder at this time for Federations flows.

Can you provide me a link that has a concise summary of what is impacted?  I did see a video on your cookie provider flows.  It mentions an attribute named getcpcookie=yes.  Is this the new change? 

We have a mix of web agents so I assume we'd need to find the corresponding agent and upgrade them?

Testing

For testing simulating Chrome 80, I've been using:

    chrome://flags/

and enabling samesite by default cookies.   Is this sufficient?

Google Chrome 80 will introduce by DEFAULT in a portion of the Browsers shipped the 'SameSite' functionality which governs when the Browser may present a cookie for a Domain when the request is a "Cross-Site" (Domain) request based on a 'samesite' flag being present in the cookie or not, and it's value if present. The Browser will NOT present the cookie on a Cross-Site (Domain) POST request if the flag is absent, or it's value is set to either "STRICT" or "LAX".

Release : 12.52 - R12.8.0.3

Component : SITEMINDER -Web Agents which generate or update cookies (Web Agent, Access Gateway (SPS), Agent for SharePoint, Web Agent Option Pack, WSS).  

Broadcom SiteMinder Engineering has released a solution for the various R12.52 SP1 CR-05 thru CR-10 Web Agents which generate or update cookies (Web Agent, Secure Proxy Server, Agent for SharePoint, Web Agent Option Pack, WSS). ", and also the R12.6 SP2, 12.7 SP2, R12.8.0.1, R12.8.0.2, and R12.8.0.3 Access Gateway versions. This solution is to allow Chrome 80 Browsers with the 'SameSite' feature enabled to experience the same Single Sign-On (SSO) experience they have come to expect.

NOTE: For versions prior to R12.52 SP1 CR-09, please check with Support on availability.
 

Please refer to the following Chromium.org links for information on the ‘SameSite’ feature;

https://www.chromium.org/updates/same-site

https://www.chromium.org/administrators/policy-list-3/cookie-legacy-samesite-policies


Please refer to the following Communities Post which explains this Broadcom solution for the Google Chrome 80 'SameSite' behavior;

https://community.broadcom.com/enterprisesoftware/communities/community-home/digestviewer/viewthread?MessageKey=2b29c302-4e89-431b-aaf1-de90c616fca5&CommunityKey=f9d65308-ca9b-48b7-915c-7e9cb8fc3295&tab=digestviewer#bm2b29c302-4e89-431b-aaf1-de90c616fca5


Following is a "Q&A" I put together to address a bunch of the common 'SameSite' questions. Please review this info, and let me know if you have any further questions.
 
Common 'Chrome 80 SameSite' Q&A's 

1.) Why is Chrome 80 'SameSite' an issue for Web Sites?

The Chrome 80 SameSite issue only affects the Agents which generate or update cookies (Web Agent, Access Gateway (SPS), ASA, Agent for SharePoint, Web Agent Option Pack, WSS). 

The Chrome 80 'SameSite' functionality dictates if and when the Chrome 80 Browser with the 'SameSite' feature enabled will or will not present a Cookie for a "Cross-Site" (Domain) request to a Web Server, and ultimately the SiteMinder Web Agent(s) for processing.

The current SiteMinder Web Agents do not set the 'SameSite' flag when generating their Cookies. The Chrome 80 Browsers with the 'SameSite' feature enabled will consider these cookies as if the flag was set to a value of "LAX". This means that any "Cross-Site" (Domain) POST request would NOT include the cookie for the receiving Domain, the Chrome 80 Browser will not present the cookie. This new behavior will cause issues when accessing SiteMinder protected sites.

If a User logs into Domain ".abc.com" and gets an SMSESSION cookie in ".abc.com", then move to a resource on ".xyz.com", and then on the page at ".xyz.com" clicks a link that POST's to a resource in ".abc.com", the Chrome 80 Browser will NOT present the SMSESSION cookie that it has for ".abc.com" in this "Cross-Site" (Domain) POST request, and the User will be re-challenged for Credentials.

The Google Chrome 80 Browsers will be released with the ‘SameSite’ feature enabled by default, and these Browsers will not present a cookie on a “Cross-Site” (Domain) POST request to a Web Server or Application Server.

2.) What use Cases would be affected?

SiteMinder Affected Use Cases when Chrome 80 is released:
When a user’s browser interacts with these SiteMinder components, under specific use cases, their interactions may fail.

- SiteMinder Agents when they are functioning in a cross-domain Cookie Provider capacity.
- SiteMinder Web Agent Option Pack (WAOP) or Access Gateway when supporting SAML or WS-Federation
- SiteMinder Access Gateway when supporting OIDC for Single Page Apps
- SiteMinder Application Server Agents when interacting with the browser in a cross-domain capacity
- SiteMinder SharePoint when interacting with the browser in a cross-domain capacity

See the use case details and some example videos on the Broadcom techdocs location (requires login):

https://techdocs.broadcom.com/us/product-content/status/announcement-documents/2019/details-of-siteminder-use-cases-impacted-by-google-chrome-80s-new-default-behavior.html


3.) What components and versions do I need for this solution?

For each of the above SiteMinder Agents that are involved with "Cross-Site" (Domain) requests which require cookies to be presented, you will want to apply this solution to provide the Chrome 80 Browsers with the same SSO experience they have come to expect.

For each of the components listed in #2 above, patches to address the Chrome 'SameSite' feature are being made available on the most recent Cumulative releases of each of the Agents. If your Agents are not currently at the latest version and Cumulative Releases where the 'SameSite' solution is available; then you will need to upgrade your Agents to the latest R12.52 SP1 CR-10 release, and then apply the patch on top of this version to obtain the solution at this time. If you are unable to upgrade to the R12.52 SP1 CR-10 release, please consult Support.

For the SiteMinder Access Gateway, the patches will be available on top of the R12.6 SP2, R12.7 SP2 versions, and will be made available for the R12.8.0.1, R12.8.0.2, and R12.8.0.3 versions. 

The Chrome 80 issue has no impact on the Policy Server other than requiring two new ACO parameters to be added to implement the new functionality; GetCPCookie and SameSite.
 
4.) Are the patches out yet?

Yes, the patches have been released and are available on the Support Portal and the Cumulative Release Index.

Following is the link to the "CA Single Sign-On (formerly CA SiteMinder) Hotfix/Cumulative Release Index" where you can locate ALL SiteMinder Cumulative Releases;

https://techdocs.broadcom.com/us/product-content/recommended-reading/technical-document-index/ca-single-sign-on-hotfix-cumulative-release-index.html?r=2&r=1&r=1&r=1



The Product Documentation released with this 'SameSite' solution explains the solution and provides instructions on how to install and configure your environment.

Please upgrade any affected component to the appropriate version so that it can accept the Solution provided, and then download and apply the solution.

5.) How can I test the ‘SameSite’ functionality before Chrome 80 is released?

Per the Chromium site, you can configure this feature on the last two previous versions of Chrome with the following steps;

“Go to chrome://flags and enable #same-site-by-default-cookies and #cookies-without-same-site-must-be-secure. Restart the browser for the changes to take effect. Test your sites, with a focus on anything involving federated login flows, multiple domains, or cross-site embedded content.”

Per the following Chromium Site, the "2 Minutes" Grace Period for the 'SameSite' behavior can be changed to "10 seconds" to help speed up testing;

Clearing up some misconceptions and providing additional information about "Lax + POST" (which is mentioned briefly on the chromestatus.com page):

• "Lax + POST" does not result in the legacy behavior (i.e. the old behavior before the SameSite changes).
• “Lax + POST” is an intervention for Lax-by-default cookies (cookies that don’t specify a `SameSite` attribute) which allows these cookies to be sent on top-level cross-site POST requests if they are at most 2 minutes old. “Normal” Lax cookies are not sent on cross-site POST requests (or any other cross-site requests with a non-idempotent HTTP method such as PUT). This intervention was put in place to mitigate breakage to some POST-based login flows.
• If “Lax + POST” is affecting the cookies you are testing (i.e. if your cookie would have been excluded if not for the "+ POST" behavior due to its age), you will see a message in the DevTools console about the 2 minute threshold. This can be useful for debugging.
• For integration testing (if your cookie needs to be sent on cross-site POST requests), we recommend test cases with cookie age both below and above the threshold. For this, there is a command-line flag --enable-features=ShortLaxAllowUnsafeThreshold, which will lower the 2 minute threshold to 10 seconds, so that your test doesn’t have to wait for 2 whole minutes. This flag is available in Chrome 79.0.3945.16 and newer. (Note that if you are also using other --enable-features flags such as --enable-features=SameSiteByDefaultCookies,CookiesWithoutSameSiteMustBeSecure, you must append the feature name to the comma-separated list rather than use multiple --enable-features flags.)
• Note that the 2-minute window for "Lax+POST" is a temporary intervention and will be removed at some point in the future (some time after the Stable launch of Chrome 80), at which point cookies involved in these flows will require `SameSite=None` and `Secure` even if under 2 minutes old.