SameSite cookie support and Chrome 80

Follow
    Applies to:
  • SecureAuth Identity Platform
  • Legacy SecureAuth IdP
Deployment model:
  • Hybrid
  • On Premises
  • Update:
    Google issued an update on April 3, 2020 announcing the rollback of SameSite enforcement.  The announcement reads, in part:  "...in light of the extraordinary global circumstances due to COVID-19, we are temporarily rolling back the enforcement of SameSite cookie labeling, starting today. While most of the web ecosystem was prepared for this change, we want to ensure stability for websites providing essential services including banking, online groceries, government services and healthcare that facilitate our daily life during this time. As we roll back enforcement, organizations, users and sites should see no disruption."

    Overview
    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.
    Note: Google has delayed the rollout of the SameSite attribute enforcement in Chrome 80 until Feb. 17.

    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:

    https://web.dev/samesite-cookies-explained/
    https://blog.chromium.org/2019/05/improving-privacy-and-security-on-web.html 

    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 patches
    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.

    To check which version of .NET is currently installed see this article:

    https://support.secureauth.com/hc/en-us/articles/360039397031-How-to-show-which-NET-version-is-installed

    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 if the initial hotfix release (HF200106_004) is used.

    This issue is addressed in the updated version of the hotfix, version HF200106_004_8.

    How do I test:

    Verify the workflow functions as expected (benchmark testing):

    1. The target IdP is unpatched
    2. Using an unaltered browser such as Microsoft Edge or Chrome79, logon to IdP and obtain a SSO token that you would expect to work with the SP you will be testing
    3. Perform a SP-Initiated flow on the application
    4. Expected result: SSO should succeed

    Verify workflow fails as expected (benchmark testing):

    1. The target IdP is unpatched
    2. Use Firefox 72.  Testing this behavior in Firefox is easier than Chrome because Chrome can provide false positives due to a 2 minute grace period provided by Chrome.
    3. In Firefox, in the about:config page change "network.cookie.sameSite.laxByDefault" and "network.cookie.sameSite.noneRequiresSecure" flags to true  by double-clicking those values.
    4. Logon to an unpatched SecureAuth IdP an obtain a SSO token that you would expect to work with the SP you will be testing
    5. Perform a SP-Initiated flow on the application
    6. Expected result: SSO failure

    Verify SecureAuth IdP is setting the SameSite cookie attribute correctly:

    1. Ensure the SecureAuth IdP you are testing against has the required Microsoft and SecureAuth SameSite hotfixes applied
    2. Open an Incognito Browser window in Chrome
    3. Press F12 to open developer tools
    4. Select the “Network” menu item on the top navigation bar
    5. Check the “Preserve log” option on the row below the top navigation bar
    6. Login to your IdP realm, such as a portal realm where you would expect to get a SSO cookie (any interactive login realm will work)
    7. Click on the “Cookies” tab in the main body of the window
    8. In the “Name” column, scroll through the list of elements and look for “Response Cookies” as shown in the example below.  This can typically be found on the SecureAuth.aspx page.
    9. All “Response Cookies” should have the Secure flag checked and the SameSite flag set to “None”, as shown in the example below

    blobid1.png

    Verify IdP and SP SameSite cookies are setting the proper values (Chrome 80 compatible):

    1. Ensure the SecureAuth IdP you are testing against has the required Microsoft and SecureAuth SameSite hotfixes applied
    2. Use Firefox 72.  Testing this behavior in Firefox is easier than Chrome because Chrome can provide false positives due to a 2 minute grace period provided by Chrome.
    3. In Firefox, in the about:config page change "network.cookie.sameSite.laxByDefault" and "network.cookie.sameSite.noneRequiresSecure" flags to true  by double-clicking those values
    4. Logon to a patched SecureAuth IdP and obtain a SSO token that you would expect to work with the SP you will be testing
    5. Perform a SP-Initiated flow on the application
    6. If it fails, then either the IdP or the SP is not setting the SameSite cookie flag as required

    Impacted flows:

    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 consumer

    Notes:

    • iFrame use cases may be impacted if the domains are different between the site hosting the iFrame and the IdP
    • Other flows may be impacted as well.  The above list is a sample of commonly impacted flows, not a comprehensive list.
    • SecureAuth suggests testing all your applications with all browsers your enterprise supports, as well as testing with the Chrome 80 beta
    • If you have failures when testing against Chrome 80 or FireFox when configured to enforce SameSite – 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.

    Other Browsers
    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.

    mceclip1.png

    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.

     

    0 out of 0 found this helpful

    Comments

    0 comments

    Please sign in to leave a comment.