Google has been working with the Internet community to help strengthen the security of cookies. Draft RFC 6265bis-03 defines new settings for the SameSite cookie flag to allow for compatibility with several federated flows including SAML, WS-Fed and OAuth. Google is targeting the release of Chrome 80 on February 4, 2020 and will start enforcing the SameSite setting, even if not specified by the web server dropping the cookie, including the SP/RP or IdP.
The changes Chrome is making are substantial and could impact your enterprise or customers. In order to accommodate this change, SecureAuth is providing a hotfix which set the SameSite flag to a value appropriate for federated workflows.
SecureAuth strongly recommends implementing this hotfix to avoid service interruption if you are using SAML, WS-Fed, OIDC/OAuth, or Forms Post.
What are SameSite cookies?
Here are a couple articles that do a great job of explaining the SameSite cookie change and how it works:
Is the IdP the only side that needs to support SameSite?
Aside from SecureAuth having to update our software to ensure compatibility with this change, SAML/WS-Fed SP’s and OIDC/OAuth Clients (Relying Parties) may need to update their code to be compatible as well.
For example, in a SP-Initiated SAML workflow, if the SP does not set the SameSite flag to None,Secure, then this will break the SAML flow. The solution to this type of issue is to ensure the SP has updated their code to include the SameSite flag.
Note that SecureAuth cannot mitigate problems with Service Providers or OIDC/OAuth RPs that do not set “their” cookie SameSite flag to None,Secure, as the behavior is enforced by the Chrome 80 browser, not SecureAuth.
Microsoft has released hotfixes for all the supported server operating systems (https://docs.microsoft.com/en-us/aspnet/samesite/kbs-samesite). This hotfix will set the SameSite value to “Lax” by default. For most use cases, SecureAuth will change the SameSite value to None,Secure to ensure compatibility with federated workflows. This hotfix is required for the SecureAuth SameSite hotfix. Note that in some iFrame use cases, applying the Microsoft hotfixes before the SecureAuth hotfix may result in failed SSO.
From time to time Microsoft may replace existing hotfixes with newer versions. The SecureAuth hotfix checks for the Microsoft December 2019 and January 2020 hotfixes before installation.
Are you impacted?
Most SAML, WS-Fed and some OIDC/OAuth workflows are impacted, as well as IdP consuming SAML and Forms Auth post-auth use cases – in cross site POST requests. Because of the variety of ways in which applications can be integrated, and some may or may not be on the same root domain, it is not possible to provide a definitive set of use cases that will be impacted. SecureAuth strongly recommends implementing this hotfix to avoid service interruption if you are using SAML, WS-Fed, OIDC/OAuth, or Forms Post. If not applied, for example, federated login request may fail, loop or just prompt the user for credentials. In addition, logout functions may not work properly.
The SecureAuth Identity Platform/IdP hotfix was designed to ensure the least amount of disruption for our customers. The hotfix can be installed by your IT staff, and specifically designed to avoid conflicts or incompatibilities with customizations. In the rare event a customization may be impacted, the hotfix installer will detect this condition and abort the installation warning of a possible conflict. If this is encountered, please contact SecureAuth support.
No SecureAuth Endpoint products (Passcode, Authenticate, Login for Windows/Mac, RADIUS server) are impacted at this time.
What does the hotfix do?
This hotfix adds the SameSite flag to most cookies dropped by IdP or Identity Platform products:
- Appends all cookies with the SameSite=None,Secure flags except for those browsers that do not supported as noted below
What do you need to do?
Detailed instructions and a link to download the hotfix and can be found here: https://docs.secureauth.com/x/HwKcAw
- Apply the hotfix to your dev/UAT environments for testing
- Apply the hotfix to your prod environments
- Ensure your partners (Service Providers or other federated integration partners) support the SameSite flag
Note that a system reboot is not required. The patch takes effect immediately upon being implemented.
Known Issues with hotifx:
If the UserAgent=NULL, the login will fail. This issue is being addressed in an updated version of the hotfix
How do I test:
Before applying the hotfix:
- SecureAuth suggests testing all your applications with the Chrome 80 beta browser.
- Expected results: Any application impacted by the SameSite cookie setting will fail to work properly with Chrome 80, as noted above (various failure conditions).
- Note that if you have a failure, it could be due to the SP/RP, not the fact that the SecureAuth appliance is not patch yet.
- Most commonly it is a IdP-side issue for:
- SP-initiated requests while using SecurePortal
- SP-initiated requests while using Transparent SSO
- Most commonly it is a SP/RP-side issue for:
- SP-initiated requests
- Authorization Code, Implicit, and Hybrid flows using response_mode=form_post
- POST to the authorization_endpoint
- POST to the end_session_endpoint
- IdP initiated request to SecureAuth SAML consume
After applying the hotfix:
- SecureAuth suggests testing all your applications with all browsers your enterprise supports, as well as testing with the Chrome 80 beta.
- Note that if you have failures when testing against Chrome 80 – but not other browsers, you need to ensure the SP/RP servers are setting their cookie’s SameSite flag to None,Secure. SecureAuth cannot mitigate problems with Service Providers or OIDC/OAuth RPs that do not set “their” cookie SameSite flag to None,Secure, as the behavior is enforced by the Chrome 80 browser, not SecureAuth.
What about incompatible SPs/RPs?
As noted above, it is inevitable that some SPs/RPs will not properly set their cookie SameSite flag. SecureAuth will be tracking reported SPs/RPs that are not properly supporting the SameSite flag and will update this post to a link to that document when available.
In time, Microsoft Edge and FireFox will start enforcing defaults for SameSite, but as of this writing, Firefox has not released a target release and Microsoft is targeting Edge 80 (both can be manually enabled on current releases). IE does support the previous draft of RFC respecting Lax and Strict, but “by default” supports None by ignoring the flag.
Safari, iOS, MacOS and some older Chrome versions have a bit more of a complicated story. Safari and embedded browsers on MacOS 10.14 and all browsers on iOS 12, and Chrome 51-66 have defects where they do not handle SameSite=None properly. Apple has chosen to only fix this defect on their most current OS versions. The SecureAuth SameSite hotfix handles these well documented exceptions for MacOS, iOS and specific Chrome versions by not sending the SameSite attribute to those browsers.
What if I’m unable to install the SecureAuth hotfix, or am on an unsupported IdP version?
If you are unable to install the SecureAuth SameSite hotfix, or on an unsupported version of SecureAuth IdP, the SameSite enforcement by Chrome80 can be disabled manually on the user’s browser.
- Browse to: chrome://flags/#same-site-by-default-cookies
- Change the “SameSite by default cookies” = Disabled
- Restart the browser
If the computers running the Chrome browser are managed, the setting can be changed via a policy change. This article https://cloud.google.com/docs/chrome-enterprise/policies/?policy=LegacySameSiteCookieBehaviorEnabled provides instructions on how to change this behavior via policy change.