SameSite cookies

About Samesite cookies

First of all, you can learn about SameSite cookies at https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies and at https://web.dev/samesite-cookies-explained/.

The .NET team had a blog post to explain why recent changes in the specification can cause problems:

TL;DR

Before Chrome 80 is released (and other browsers before they turn the new SameSite behavior on):

  • If your servers haven't installed the latest SameSite updates for .NET, you are good.
  • If your servers have installed the latest SameSite updates for .NET:
    • If you don't need to support old browsers, you can use the approach in the "Workaround" section below.
    • If you need to support old browsers, you can either check out the "Workaround - not support old browsers" section or the "Final solution" section.

After Chrome 80 is released (and other browsers when they turn the new SameSite behavior on):

  • You need to install the latest SameSite updates for .NET.
  • If you don't need to support old browsers, you can use the approach in the "Workaround" section below.
  • If you need to support old browsers, please check out the "Final solution" section.

Problems that the new SameSite specification will cause to Safewhere's products

First of all, please note that the upcoming problems will only happen when at least one of the following happens:

  • You install a latest Net patch.
  • Or you are using a Chrome build/configuration that enables the new SameSite behaviors.

SAML 2.0/WSFed/OAuth/OIDC logins work as follows:

  • An SP sends a request to Safewhere Identify. Identify, as an Asp.Net application, creates a new session and writes the session id to a cookie named identify_sessionid.
  • The user selects an upstream IdP to use. It may be a SAML 2.0, WSFed, or OAuth/OIDC provider. Identify will send an authentication request to the IdP. If an OAuth/OIDC IdP is used, Identify will also create a correlation cookie.
  • The user finishes logging in on the IdP side and the IdP returns a response to Identify by using a mechanism called "POST-based-redirect" which triggers SameSite protection.

The same problem can happen when a Service Provider or Identity Provider does POST based redirects to Identify for AuthnRequest or LogoutRequest/LogoutResponse. Besides, your own Service Provider may have the same issue.

All cookies that are affected by the SameSite changes are:

  • identify_sessionid
  • identify_auth
  • correlation
  • AuthenticationConnectionId
  • participants cookies

Changes that are/were happening

Google Chrome

Chrome is making a number of changes. The most important timestamp is that from Chrome 80 stable, which will be released by February 4, 2020:

This means that by the time Chrome 80 is released, the new default behavior may cause big problems to many web applications.

More details from the Chromium team: https://blog.chromium.org/2019/10/developers-get-ready-for-new.html

.NET framework

The .NET team released a bunch of updates to support the new specification:

What is the immediate problem

The update from Microsoft is supposed to be optional. The ideal scenario is:

  • We install the update on dev machines.
  • We implement necessary code and test to make sure the new SameSite spec is supported by our products on all browsers. In addition, we will document workaround, if there is, for those who can't update yet.
  • We roll out updates for our products to you to test it together with the new .NET update on your servers before Chrome 80 is released.

However, we got reported that some of our customers' servers have got that optional update installed. The consequence is that SAML 2.0 logins and OpenId Connection logins might stop working.

Workaround

This workaround applies if you want to support old browsers that implemented SameSite wrong. Please note that this workaround can apply to the Identify version 5.1.1++ but it will stop working on Chrome 80 as well as on future releases of other browsers. You will need to install our software updates before that timeline or check the next workaround.

If you have installed the latest .NET patch on your server, you can opt-out of the new behavior as follows:

  1. Use the following command to decrypt the web.config file of your Identify instance:

  2. Add the sameSite attribute to the system.web/httpCookies section. The httpOnlyCookies attribute is optional but we recommend that you set it to true to prevent JavaScript code from accessing your cookies.

  3. Add the cookieSameSite attribute to the sessionState section:

    For example:

  4. Add the cookieSameSite attribute to the authentication/forms section:

  5. Add the key below to the -appSettings section:

  6. Save the web.config file.

  7. Encrypt your web.config:

Workaround - not support old browsers

You won't need to update your Safewhere Identify deployment if you don't need to support users who are using the following browser clients: https://www.chromium.org/updates/same-site/incompatible-clients

  1. Use the following command to decrypt the web.config file of your Identify instance:

  2. Add the sameSite attribute to the system.web/httpCookies section. The httpOnlyCookies attribute is optional but we recommend that you set it to true to prevent JavaScript code from accessing your cookies.

  3. Add the cookieSameSite attribute to the sessionState section:

  4. Add the cookieSameSite attribute to the authentication/forms section:

  5. Save the web.config file.

  6. Encrypt your web.config:

Final solution


NOTE

Unlike the workarounds above which either doesn't support old browsers or will stop working when Chrome 80 is released. This solution can virtually work in all situations.


Because Safewhere Identify needs to use its cookies in the POST-based-redirect manner, those cookies must use SameSite=None. The problem now is to deal with old browsers that don't support the None option.

According to guidances from Microsoft and Google:

the two common solutions are:

  • Use browser agent sniffing.
  • Use double cookies.

Although both solutions have pros and cons, we opted for the browser agent sniffing one because the double cookies approach will double cookie's size which may end up with the exceeding cookie size limit problem.

Safewhere Identify version 5.6 will ship with support for the new SameSite behavior as well as support for old browsers by default. If you are using a previous version and want to support old browsers, you will need to deploy the patch, which is a dll named Safewhere.Extensions.SameSite, into the Runtime\Bin folder of your Identify instance.

The Safewhere.Extensions.SameSite dll has an Asp.Net MVC's global filter that uses browser agent sniffing technique to detect and set the SameSite flag to empty if the browser doesn't support the None option. Implementing the path in a separate dll also means that we can release bug fixes or improvements for it easily.

How to apply the patch

From Identify version 5.1.1.4514 to latest version 5.5

First of all, you need to install .NET 4.7.2 or 4.8 on your server as well as all the latest patches.

  1. Download the latest extension.

  2. Deploy the dll to C:\Program Files\Safewhere\Identify\Tenants\#yourTenantT1\bin

  3. Use the following command to decrypt the web.config file of your Identify instance:

  4. Open to edit the web.config file

  5. Update the AppStartup setting under the -appSettings section as follows:

    To

  6. Add the sameSite attribute to the system.web/httpCookies section. The httpOnlyCookies attribute is optional but we recommend that you set it to true to prevent JavaScript code from accessing your cookies.

  7. Add the cookieSameSite attribute to the sessionState section:

  8. Add the cookieSameSite attribute to the authentication/forms section:

  9. Save your web.config file.

  10. Encrypt your web.config:

For Identify 5.6 and later

The patch is shipped with Identify 5.6 out of the box. You won't need to make any manual change to your Identify instances.

Service Providers

Saml 2.0 for WIF component


Note: SAML 2.0 for WIF is a component and each application that uses it is different. The workarounds that we are proposing here are technical tips. They are not universal solutions that you should use as-is without proper consideration.

If you don't need to support old browsers and assuming that your application is using all the standard Asp.Net and WIF's cookies, you can follow the next steps to enable SameSite support:

  1. Install .NET 4.7.2 or 4.8 on your server as well as all the latest patches.

  2. Add the sameSite attribute to the system.web/httpCookies section (and add the section to your web.config if it isn't there. If the section doesn't exist in your web.config, it will mean that you are using its default settings). The httpOnlyCookies attribute is optional but we recommend that you set it to true to prevent JavaScript code from accessing your cookies.

    Please note that using sameSite="None" here will turn all cookies of your application to None which can be a security risk. The reason that you need to set this one is to let the FedAuth cookies set to sameSite="None". An alternative is to make a custom Cookie Handler.

  3. Add the cookieSameSite attribute to the sessionState section:

  4. Add the cookieSameSite attribute to the authentication/forms section:

If you want to support old browsers, you will need to do browser sniffing. You can find sample code for doing that at https://github.com/Safewhere/Safewhere-Identify-samples/tree/master/SameSite-Cookies.

Q&A