Chrome SameSite Cookie Change
Chrome version 80, which is scheduled for release in February 2020, includes a change that may impact SAML SSO.
In most versions of the SAML library, a cookie is used to maintain SAML session state in support of the SAML protocol. This cookie must have a SameSite mode of None.
In earlier releases of Chrome, the SameSite mode defaulted to None. The update defaults the SameSite mode to Lax.
Furthermore, if a SameSite mode of None is specified, Chrome requires the Secure attribute to be specified for the cookie.
For more details, please refer to the Background and ASP.NET Support sections below.
Determining the SAML Library Version
The NuGet package manager identifies the product version being used. Alternatively, refer to Determining the Product Version.
What to do if using SAML Library v4.x
No changes are required as SAML library v4.0.0 and above includes inbuilt support for SameSite=None.
If the application targets .NET framework v4.8 or later, the SAML library makes use of the .NET framework’s support for SameSite. Otherwise, for earlier releases of the .NET framework, a workaround is employed to add SameSite support.
What to do if using SAML Library v3.x
Prior to v4.7.2, the .NET framework didn’t support setting the SameSite mode.
However, SAML library v3.x supports .NET framework versions prior to v4.7.2 and consequently this .NET framework update isn’t available.
To avoid the additional disruption of requiring an update to SAML for ASP.NET, a special HTTP module is available that adds the missing SameSite=None.
For example, the HTTP Module updates:
set-cookie: SAML_SessionId=59c203d2-8c64-4ac4-b664-6fb8a7320434; path=/; secure; httponly
To:
set-cookie: SAML_SessionId=59c203d2-8c64-4ac4-b664-6fb8a7320434; path=/; SameSite=None; secure; httponly
The HTTP module does this using a workaround as SameSite isn’t supported by the earlier .NET framework API.
The HTTP module, including full source code, is available for download at:
SAML Cookie HTTP Module
Note that the HTTP module is required even if your application targets .NET framework v4.7.2 or later as the SameSite support isn’t included in the SAML library v3.x.
The following steps should be taken:
1. Copy the HTTP Module DLL to the application’s bin folder.
2. To enable the HTTP module, update the application’s web.config as follows.
<system.webServer>
</system.webServer>
3. Confirm that SameSite is working as described in the section below.
What to do if using SAML Library releases from v2.5.0 but earlier than v3.0.0
SAML library v2.5.0 introduced the SAML high-level API which uses a cookie to maintain SAML session state.
The ASP.NET session cookie, rather than a separate SAML session cookie, is used to maintain SAML session state.
The ASP.NET session cookie must include a SameSite value of None and should be marked as secure.
To achieve this:
1. Update the web server to the latest ASP.NET release (ie ASP.NET v4.8 or later) to pick up the runtime support for SameSite.
Note that the application may continue to target an earlier version of the .NET framework. For example, your application’s project may continue to target .NET framework v4.0 but you need to update the web server to ASP.NET v4.8.
2. Ensure the web server is up to date and the KB article 4531182 and KB article 4524421 updates have been applied. This is also available through KB article 4535104.
Without the updates, the None value does not emit the SameSite cookie header.
For more information, refer to:
https://docs.microsoft.com/en-us/dotnet/api/system.web.configuration.sessionstatesection?view=netframework-4.8
https://docs.microsoft.com/en-us/dotnet/api/system.web.samesitemode?view=netframework-4.8
3. Update the application’s web.config to specify the following.
4. Confirm that SameSite is working as described in the section below.
Without these changes, the SameSite parameter is missing or set to either Lax or Strict.
set-cookie: ASP.NET_SessionId=dwhtw4ajbxblp5pw5arwf0ww; path=/; HttpOnly
After these changes, the SameSite parameter is included.
set-cookie: ASP.NET_SessionId=2s2wesefh0cohv0ugctun4hl; path=/; secure; HttpOnly; SameSite=None
Note though that if the ASP.NET update hasn’t been installed on the web server, the unrecognized cookie SameSite attribute will result in an “Unrecognized attribute” configuration error at runtime.
These changes are not required if calling the SAML low-level API rather than the more commonly used SAML high-level API.
What to do if using SAML Library releases earlier than v2.5.0
SAML library releases prior to v2.5.0 support the SAML low-level API only. The SAML high-level API was introduced in v2.5.0. The SAML low-level API doesn’t maintain SAML session state and therefore doesn’t use a cookie.
Therefore, no changes are required to use the SAML library releases prior to v2.5.0.
Confirming Correct SameSite Support
It’s highly recommended that after making the required changes, the SameSite support is confirmed.
For example, use the Browser developer tools to capture the network traffic.
At the beginning of the SSO flow, there will be a Set-Cookie response header similar to the following.
set-cookie: SAML_SessionId=925a928f-1b6e-469a-9593-3a61d8b0b84d; path=/; SameSite=None; secure; HttpOnly
Ensure the SameSite=None and Secure attributes are present.
Older Browser Support
Some older browsers are incompatible with the SameSite mode of None.
In particular, older releases of Safari, prior to OSX Catalina or iOS 13, will fail if presented with a SameSite mode of None.
It’s recommended that users upgrade to the latest OSX or iOS release.
Of course, this may not be possible and the SAML for ASP.NET 4.0.0 and SAML Cookie HTTP Module both include code to detect these older browsers and not include the SameSite mode in the cookie.
There are no known compatibility issues with recent versions of Chrome, Firefox or Edge.
https://www.chromium.org/updates/same-site/incompatible-clients
Background
A SAML session cookie is used to maintain SAML session state and support the SAML protocol.
A set-cookie header may include an optional SameSite attribute whose purpose is to help protect against cross-site request forgery attacks (CSRF).
SAML protocol exchanges are, in most use cases, cross-site. The identity provider (IdP) and service provider (SP) are different sites. Furthermore, these flows do not involve users clicking navigation links from one site to the other. For example, when an IdP sends an SP a SAML response, it returns a 200 HTTP response to the browser containing an HTML form and some JavaScript to automatically submit the form to the SP via an HTTP Post. From the browser’s perspective, the current site is the IdP and destination site for the HTTP Post is the SP.
If the SAML session cookie is marked as SameSite=Strict, the browser won’t include it with the SAML response as the sites are different. If the SAML session cookie is marked as SameSite=Lax, the browser still won’t include it as this isn’t considered a top-level navigation action. Specifically, the SameSite specification doesn’t consider Post to be a safe HTTP method.
Consequently, the SAML session cookie must be created with a SameSite value of None.
These considerations aren’t specific to SAML SSO or ASP.NET. Other external authentication protocols and other platforms potentially have the same issues.
Until recently, Chrome treated a missing SameSite parameter the same as if None had been specified. In other words, None was the default SameSite mode at the browser. Starting with Chrome version 80, SameSite will default to Lax and if a SameSite mode of None is specified, the Secure attribute must be specified for the cookie.
ASP.NET Support
Prior to v4.7.2, the .NET framework didn’t support setting the SameSite mode.
For example:
set-cookie: SAML_SessionId=59c203d2-8c64-4ac4-b664-6fb8a7320434; path=/; secure; httponly
Microsoft identified this as an issue, given the impending change in browser support.
https://github.com/aspnet/AspNetCore/issues/12125
Updates to the .NET framework are available that ensure a SameSite mode of None is included in the set-cookie header.
https://docs.microsoft.com/en-us/dotnet/api/system.web.httpcookie.samesite?view=netframework-4.8
For example:
set-cookie: SAML_SessionId=4987e404-617c-450c-8515-35d0b0a8f80c; path=/; secure; samesite=none; httponly
References
https://tools.ietf.org/html/draft-ietf-httpbis-cookie-same-site-00
https://tools.ietf.org/html/draft-west-cookie-incrementalism-00
https://blog.chromium.org/2019/10/developers-get-ready-for-new.html
https://www.chromestatus.com/feature/5088147346030592
https://www.chromium.org/updates/same-site/incompatible-clients
https://github.com/aspnet/AspNetCore/issues/8212
https://github.com/aspnet/AspNetCore/issues/12125
https://github.com/dotnet/core/blob/master/release-notes/2.2/2.2.8/2.2.8.md
https://docs.microsoft.com/en-us/aspnet/samesite/system-web-samesite
https://devblogs.microsoft.com/aspnet/upcoming-samesite-cookie-changes-in-asp-net-and-asp-net-core/
[quote][/quote]
Chrome SameSite Cookie Change
Chrome version 80, which is scheduled for release in February 2020, includes a change that may impact SAML SSO.
SAML for ASP.NET uses a cookie to maintain SAML session state in support of the SAML protocol. This cookie must have a SameSite mode of None.
In earlier releases of Chrome, the SameSite mode defaulted to None. The update defaults the SameSite mode to Lax.
Furthermore, if a SameSite mode of None is specified, Chrome requires the Secure attribute to be specified for the cookie.
For more details, please refer to the Background and ASP.NET Support sections below.
Determining the SAML for ASP.NET Version
The NuGet package manager identifies the product version being used. Alternatively, refer to Determining the Product Version.
What to do if using SAML for ASP.NET v4.x
No changes are required as SAML for ASP.NET v4.0.0 and above includes inbuilt support for SameSite=None.
If targeting .NET framework v4.8 or later, the .NET framework's support for SameSite is used.
If targeting earlier versions of the .NET framework, a workaround is employed as SameSite isn't supported by the earlier .NET framework API.
What to do if using SAML for ASP.NET v3.x
Prior to v4.7.2, the .NET framework didn't support setting the SameSite mode.
However, SAML for ASP.NET v3.x supports .NET framework versions prior to v4.7.2 and consequently this .NET framework update isn't available.
To avoid the additional disruption of requiring an update to SAML for ASP.NET, a special HTTP module is available that adds the missing SameSite=None.
For example, the HTTP Module updates:
set-cookie: SAML_SessionId=59c203d2-8c64-4ac4-b664-6fb8a7320434; path=/; secure; httponly
To:
set-cookie: SAML_SessionId=59c203d2-8c64-4ac4-b664-6fb8a7320434; path=/; SameSite=None; secure; httponly
The HTTP module does this using a workaround as SameSite isn't supported by the earlier .NET framework API.
The HTTP module, including full source code, is available for download at:
SAML Cookie HTTP Module
1. Copy the HTTP Module DLL to the application's bin folder.
2. To enable the HTTP module, update the application's web.config as follows.
3. Confirm that SameSite is working as described in the section below.
What to do if using SAML for ASP.NET v2.x
SAML for ASP.NET v2.x makes use of the ASP.NET session cookie rather than a separate SAML session cookie to maintain SAML session state.
The ASP.NET session cookie must include a SameSite value of None and should be marked as secure.
To achieve this:
1. Update the web server to the latest ASP.NET release (ie ASP.NET v4.8 or later) to pick up the runtime support for SameSite. The application may continue to target an earlier version of the .NET framework.
2. Update the application's web.config to specify the following.
3. Confirm that SameSite is working as described in the section below.
Without these changes, the SameSite parameter is missing.
set-cookie: ASP.NET_SessionId=dwhtw4ajbxblp5pw5arwf0ww; path=/; HttpOnly
After these changes, the SameSite parameter is included.
set-cookie: ASP.NET_SessionId=2s2wesefh0cohv0ugctun4hl; path=/; secure; HttpOnly; SameSite=None
Note though that if the ASP.NET update hasn’t been installed on the web server, the unrecognized cookieSameSite attribute will result in an “Unrecognized attribute” configuration error at runtime.
These changes are not required if calling the SAML low-level API rather than the more commonly used SAML high-level API.
Confirming Correct SameSite Support
It's highly recommended that after making the required changes, the SameSite support is confirmed.
For example, use the Browser developer tools to capture the network traffic.
At the beginning of the SSO flow, there will be a Set-Cookie response header similar to the following.
set-cookie: SAML_SessionId=925a928f-1b6e-469a-9593-3a61d8b0b84d; path=/; SameSite=None; secure; HttpOnly
Ensure the SameSite=None and Secure attributes are present.
Older Browser Support
Some older browsers are incompatible with the SameSite mode of None.
In particular, older releases of Safari, prior to OSX Catalina or iOS 13, will fail if presented with a SameSite mode of None.
It's recommended that users upgrade to the latest OSX or iOS release.
Of course, this may not be possible and the SAML for ASP.NET 4.0.0 and SAML Cookie HTTP Module both include code to detect these older browsers and not include the SameSite mode in the cookie.
There are no known compatibility issues with recent versions of Chrome, Firefox or Edge.
https://www.chromium.org/updates/same-site/incompatible-clients
Background
A SAML session cookie is used to maintain SAML session state and support the SAML protocol.
A set-cookie header may include an optional SameSite attribute whose purpose is to help protect against cross-site request forgery attacks (CSRF).
SAML protocol exchanges are, in most use cases, cross-site. The identity provider (IdP) and service provider (SP) are different sites. Furthermore, these flows do not involve users clicking navigation links from one site to the other. For example, when an IdP sends an SP a SAML response, it returns a 200 HTTP response to the browser containing an HTML form and some JavaScript to automatically submit the form to the SP via an HTTP Post. From the browser's perspective, the current site is the IdP and destination site for the HTTP Post is the SP.
If the SAML session cookie is marked as SameSite=Strict, the browser won't include it with the SAML response as the sites are different. If the SAML session cookie is marked as SameSite=Lax, the browser still won't include it as this isn't considered a top-level navigation action. Specifically, the SameSite specification doesn't consider Post to be a safe HTTP method.
Consequently, the SAML session cookie must be created with a SameSite value of None.
These considerations aren't specific to SAML SSO or ASP.NET. Other external authentication protocols and other platforms potentially have the same issues.
Until recently, Chrome treated a missing SameSite parameter the same as if None had been specified. In other words, None was the default SameSite mode at the browser. Starting with Chrome version 80, SameSite will default to Lax and if a SameSite mode of None is specified, the Secure attribute must be specified for the cookie.
ASP.NET Support
Prior to v4.7.2, the .NET framework didn't support setting the SameSite mode.
For example:
set-cookie: SAML_SessionId=59c203d2-8c64-4ac4-b664-6fb8a7320434; path=/; secure; httponly
Microsoft identified this as an issue, given the impending change in browser support.
https://github.com/aspnet/AspNetCore/issues/12125
Updates to the .NET framework are available that ensure a SameSite mode of None is included in the set-cookie header.
https://docs.microsoft.com/en-us/dotnet/api/system.web.httpcookie.samesite?view=netframework-4.8
For example:
set-cookie: SAML_SessionId=4987e404-617c-450c-8515-35d0b0a8f80c; path=/; secure; samesite=none; httponly
References
https://tools.ietf.org/html/draft-ietf-httpbis-cookie-same-site-00
https://tools.ietf.org/html/draft-west-cookie-incrementalism-00
https://blog.chromium.org/2019/10/developers-get-ready-for-new.html
https://www.chromestatus.com/feature/5088147346030592
https://github.com/aspnet/AspNetCore/issues/8212
https://github.com/aspnet/AspNetCore/issues/12125
https://github.com/dotnet/core/blob/master/release-notes/2.2/2.2.8/2.2.8.md
https://docs.microsoft.com/en-us/aspnet/samesite/system-web-samesite
https://devblogs.microsoft.com/aspnet/upcoming-samesite-cookie-changes-in-asp-net-and-asp-net-core/
Chrome version 80, which is scheduled for release in February 2020, includes a change that may impact SAML SSO.
SAML for ASP.NET uses a cookie to maintain SAML session state in support of the SAML protocol. This cookie must have a SameSite mode of None.
In earlier releases of Chrome, the SameSite mode defaulted to None. The update defaults the SameSite mode to Lax.
Furthermore, if a SameSite mode of None is specified, Chrome requires the Secure attribute to be specified for the cookie.
For more details, please refer to the Background and ASP.NET Support sections below.
Determining the SAML for ASP.NET Version
The NuGet package manager identifies the product version being used. Alternatively, refer to Determining the Product Version.
What to do if using SAML for ASP.NET v4.x
No changes are required as SAML for ASP.NET v4.0.0 and above includes inbuilt support for SameSite=None.
If targeting .NET framework v4.8 or later, the .NET framework's support for SameSite is used.
If targeting earlier versions of the .NET framework, a workaround is employed as SameSite isn't supported by the earlier .NET framework API.
What to do if using SAML for ASP.NET v3.x
Prior to v4.7.2, the .NET framework didn't support setting the SameSite mode.
However, SAML for ASP.NET v3.x supports .NET framework versions prior to v4.7.2 and consequently this .NET framework update isn't available.
To avoid the additional disruption of requiring an update to SAML for ASP.NET, a special HTTP module is available that adds the missing SameSite=None.
For example, the HTTP Module updates:
set-cookie: SAML_SessionId=59c203d2-8c64-4ac4-b664-6fb8a7320434; path=/; secure; httponly
To:
set-cookie: SAML_SessionId=59c203d2-8c64-4ac4-b664-6fb8a7320434; path=/; SameSite=None; secure; httponly
The HTTP module does this using a workaround as SameSite isn't supported by the earlier .NET framework API.
The HTTP module, including full source code, is available for download at:
SAML Cookie HTTP Module
1. Copy the HTTP Module DLL to the application's bin folder.
2. To enable the HTTP module, update the application's web.config as follows.
3. Confirm that SameSite is working as described in the section below.
What to do if using SAML for ASP.NET v2.x
SAML for ASP.NET v2.x makes use of the ASP.NET session cookie rather than a separate SAML session cookie to maintain SAML session state.
The ASP.NET session cookie must include a SameSite value of None and should be marked as secure.
To achieve this:
1. Update the web server to the latest ASP.NET release (ie ASP.NET v4.8 or later) to pick up the runtime support for SameSite. The application may continue to target an earlier version of the .NET framework.
2. Update the application's web.config to specify the following.
3. Confirm that SameSite is working as described in the section below.
Without these changes, the SameSite parameter is missing.
set-cookie: ASP.NET_SessionId=dwhtw4ajbxblp5pw5arwf0ww; path=/; HttpOnly
After these changes, the SameSite parameter is included.
set-cookie: ASP.NET_SessionId=2s2wesefh0cohv0ugctun4hl; path=/; secure; HttpOnly; SameSite=None
Note though that if the ASP.NET update hasn’t been installed on the web server, the unrecognized cookieSameSite attribute will result in an “Unrecognized attribute” configuration error at runtime.
These changes are not required if calling the SAML low-level API rather than the more commonly used SAML high-level API.
Confirming Correct SameSite Support
It's highly recommended that after making the required changes, the SameSite support is confirmed.
For example, use the Browser developer tools to capture the network traffic.
At the beginning of the SSO flow, there will be a Set-Cookie response header similar to the following.
set-cookie: SAML_SessionId=925a928f-1b6e-469a-9593-3a61d8b0b84d; path=/; SameSite=None; secure; HttpOnly
Ensure the SameSite=None and Secure attributes are present.
Older Browser Support
Some older browsers are incompatible with the SameSite mode of None.
In particular, older releases of Safari, prior to OSX Catalina or iOS 13, will fail if presented with a SameSite mode of None.
It's recommended that users upgrade to the latest OSX or iOS release.
Of course, this may not be possible and the SAML for ASP.NET 4.0.0 and SAML Cookie HTTP Module both include code to detect these older browsers and not include the SameSite mode in the cookie.
There are no known compatibility issues with recent versions of Chrome, Firefox or Edge.
https://www.chromium.org/updates/same-site/incompatible-clients
Background
A SAML session cookie is used to maintain SAML session state and support the SAML protocol.
A set-cookie header may include an optional SameSite attribute whose purpose is to help protect against cross-site request forgery attacks (CSRF).
SAML protocol exchanges are, in most use cases, cross-site. The identity provider (IdP) and service provider (SP) are different sites. Furthermore, these flows do not involve users clicking navigation links from one site to the other. For example, when an IdP sends an SP a SAML response, it returns a 200 HTTP response to the browser containing an HTML form and some JavaScript to automatically submit the form to the SP via an HTTP Post. From the browser's perspective, the current site is the IdP and destination site for the HTTP Post is the SP.
If the SAML session cookie is marked as SameSite=Strict, the browser won't include it with the SAML response as the sites are different. If the SAML session cookie is marked as SameSite=Lax, the browser still won't include it as this isn't considered a top-level navigation action. Specifically, the SameSite specification doesn't consider Post to be a safe HTTP method.
Consequently, the SAML session cookie must be created with a SameSite value of None.
These considerations aren't specific to SAML SSO or ASP.NET. Other external authentication protocols and other platforms potentially have the same issues.
Until recently, Chrome treated a missing SameSite parameter the same as if None had been specified. In other words, None was the default SameSite mode at the browser. Starting with Chrome version 80, SameSite will default to Lax and if a SameSite mode of None is specified, the Secure attribute must be specified for the cookie.
ASP.NET Support
Prior to v4.7.2, the .NET framework didn't support setting the SameSite mode.
For example:
set-cookie: SAML_SessionId=59c203d2-8c64-4ac4-b664-6fb8a7320434; path=/; secure; httponly
Microsoft identified this as an issue, given the impending change in browser support.
https://github.com/aspnet/AspNetCore/issues/12125
Updates to the .NET framework are available that ensure a SameSite mode of None is included in the set-cookie header.
https://docs.microsoft.com/en-us/dotnet/api/system.web.httpcookie.samesite?view=netframework-4.8
For example:
set-cookie: SAML_SessionId=4987e404-617c-450c-8515-35d0b0a8f80c; path=/; secure; samesite=none; httponly
References
https://tools.ietf.org/html/draft-ietf-httpbis-cookie-same-site-00
https://tools.ietf.org/html/draft-west-cookie-incrementalism-00
https://blog.chromium.org/2019/10/developers-get-ready-for-new.html
https://www.chromestatus.com/feature/5088147346030592
https://github.com/aspnet/AspNetCore/issues/8212
https://github.com/aspnet/AspNetCore/issues/12125
https://github.com/dotnet/core/blob/master/release-notes/2.2/2.2.8/2.2.8.md
https://docs.microsoft.com/en-us/aspnet/samesite/system-web-samesite
https://devblogs.microsoft.com/aspnet/upcoming-samesite-cookie-changes-in-asp-net-and-asp-net-core/
Thanks for providing this information. I'm a bit confused, however. We are currently using SAML v2.0 for .NET4 and we are targeting ASP.NET 4.7.2 in our assemblies. As such, the post says that "No changes are required as SAML for ASP.NET v4.0.0 and above includes inbuilt support for SameSite=None." So, at first it seems that there's nothing to do and everything is already taken care of. I then looked at the "Confirming Correct SameSite Support" section and pulled a network trace of the SAML flow and am not seeing a cookie with the "SameSite=None" attribute (or the secure one for that matter).
Could you please clarify steps to take here for my use case of: SAML v2.0 for .NET4 within a project targeting 4.7.2? Also, should I expect to see "SAML_SessionId" as a specific cookie, or is the name of this cookie customized within the implementation?
We appreciate your feeback.
My apologies for the confusion. SAML for ASP.NET v4.x refers to v4.x of the SAML for ASP.NET product rather than ASP.NET v4.x. I’ve updated the topic to make this clearer by referring to SAML library v4.x etc. Please determine which version of the SAML library you’re using. If, for example, it’s v3.x then follow the instructions for this version.
For versions from 3.0.0 onward, you should see a cookie named SAML_SessionId. The only exception is if you’re calling the SAML low-level API rather than the SAML high-level API.
Let me know if you have any other questions.
Good morning,
Is there some way of checking for sure whether our ComponentSpace SAML based implementation uses cookies? (as I wasn’t aware it was).
If I open Chrome, run through a SAML login, and then use the appropriate settings tab to inspect the cookies set for/by our site, I don’t see any called “SAML_SessionId”. Does this mean that our implementation is not using cookies, and therefore we’re not going to be affected by this change?
I downloaded the current dev preview of Chrome (81.0.4021.2) and also followed the instructions found here - https://www.chromium.org/updates/same-site - to “To test whether your sites may be affected by the SameSite changes”, and I can still login to 3rd party sites using SAML SSO.
So I assume in our case, that we don’t need to change anything?
Thanks,
Steve.
I want to confirm that no changes should be required for Chrome80. We are currently using ComponentSpace Version 2.2.0.13. We are also using the low level api. This was determined after reviewing the documentation which was sent in this email. (Please see the highlighted, bolded, underline information below).
I’d also like to understand why no changes are necessary when using an older version of ComponentSpace with the low level api.
FROM YOUR DOCUMENATION
What to do if using SAML Library v2.x…
After these changes, the SameSite parameter is included.
set-cookie: ASP.NET_SessionId=2s2wesefh0cohv0ugctun4hl; path=/; secure; HttpOnly; SameSite=None
Note though that if the ASP.NET update hasn’t been installed on the web server, the unrecognized cookieSameSite attribute will result in an “Unrecognized attribute” configuration error at runtime.
These changes are not required if calling the SAML low-level API rather than the more commonly used SAML high-level API.
Confirming Correct SameSite Support
It’s highly recommended that after making the required changes, the SameSite support is confirmed.
For example, use the Browser developer tools to capture the network traffic.
I am slightly confused by the post. We are using SAML v 3.x and are on .Net Framework v 4.7.2. I cannot tell if this affects us or not?
Has anyone been able to get their saml service provider app to fail on google canary with these issues?
We are confused by the post also. We are using .net 4.5.1 framework and your 3.5 version. We have downloaded google canary which is version 81 and turned on the samesite features in flags but are unable to get our saml service provider application to fail with saml sso with your control. We do see the console warnings but contrary to what they say in google canary 81 the SAML_SessionId cookie is still there and we are unable to find a problem thus far.
[quote][/quote]
Has anyone been able to get their saml service provider app to fail on google canary with these issues?
We are confused by the post also. We are using .net 4.5.1 framework and your 3.5 version. We have downloaded google canary which is version 81 and turned on the samesite features in flags but are unable to get our saml service provider application to fail with saml sso with your control. We do see the console warnings but contrary to what they say in google canary 81 the SAML_SessionId cookie is still there and we are unable to find a problem thus far.
We are confused by the post also. We are using .net 4.5.1 framework and your 3.5 version. We have downloaded google canary which is version 81 and turned on the samesite features in flags but are unable to get our saml service provider application to fail with saml sso with your control. We do see the console warnings but contrary to what they say in google canary 81 the SAML_SessionId cookie is still there and we are unable to find a problem thus far.
No - I have tested too, and haven't been able to get a login process to fail.
I read again, and it seems that the version of the component we're using (2.x) uses the ASP.NET session cookie, and not a custom SAML cookie.
So far as I can see from research - the changes Google have made only affect cookies that are set via a third party. e.g. in the scenario that my web page loads some images or videos from a different domain. The browser will no longer allow cookies to be set for the different domain when a resource has been loaded via (for example) an
What I can't see is how this affects - in most cases - the SAML login process? But I could be missing something :)
[quote][/quote]
Has anyone been able to get their saml service provider app to fail on google canary with these issues?
We are confused by the post also. We are using .net 4.5.1 framework and your 3.5 version. We have downloaded google canary which is version 81 and turned on the samesite features in flags but are unable to get our saml service provider application to fail with saml sso with your control. We do see the console warnings but contrary to what they say in google canary 81 the SAML_SessionId cookie is still there and we are unable to find a problem thus far.
We are confused by the post also. We are using .net 4.5.1 framework and your 3.5 version. We have downloaded google canary which is version 81 and turned on the samesite features in flags but are unable to get our saml service provider application to fail with saml sso with your control. We do see the console warnings but contrary to what they say in google canary 81 the SAML_SessionId cookie is still there and we are unable to find a problem thus far.
The code in the SAmlCookieHttpModule.cs states
/// Recent browser versions now default cookies to SameSite=Lax.
/// To support SAML SSO, the SAML session cookie must be SameSite=None.
What am I missing?
My test server is Windows Server 2008 R2. It has the latest .Net Framework installed (4.8). We are using ComponentSpace 2.8.50. I added this line to web.config
I already had this line
Now I get the error
Parser Error Message: Unrecognized attribute ‘cookieSameSite’. Note that attribute names are case-sensitive.
What is wrong?
[quote][/quote]
Has anyone been able to get their saml service provider app to fail on google canary with these issues?
We are confused by the post also. We are using .net 4.5.1 framework and your 3.5 version. We have downloaded google canary which is version 81 and turned on the samesite features in flags but are unable to get our saml service provider application to fail with saml sso with your control. We do see the console warnings but contrary to what they say in google canary 81 the SAML_SessionId cookie is still there and we are unable to find a problem thus far.
We are confused by the post also. We are using .net 4.5.1 framework and your 3.5 version. We have downloaded google canary which is version 81 and turned on the samesite features in flags but are unable to get our saml service provider application to fail with saml sso with your control. We do see the console warnings but contrary to what they say in google canary 81 the SAML_SessionId cookie is still there and we are unable to find a problem thus far.
The code in the SAmlCookieHttpModule.cs states
/// Recent browser versions now default cookies to SameSite=Lax.
/// To support SAML SSO, the SAML session cookie must be SameSite=None.
What am I missing?[/quote]
What am I missing of the SAML_SessionId cookie does not exist and yet I get all of the data coming over in my ReceiveSSO like I did before? What's the use of the SAML_SessionId cookie anyways? My service provider app doesn't have the cookie but appears to be working just fine with no changes at all.
I finally found a way to actually turn on the functionality (which does not seem like it will turn on in Chrome 80 or 81) using the steps at https://knowyourtoolset.com/2020/01/testing-for-the-new-samesite-cookie-handling-changes/ with google chrome canary with startup arguments. From my take it looks like Google is threatening to turn this on in 80 but has no plans to actually change the behavior until 81
[quote][/quote]
Good morning,
Is there some way of checking for sure whether our ComponentSpace SAML based implementation uses cookies? (as I wasn't aware it was).
If I open Chrome, run through a SAML login, and then use the appropriate settings tab to inspect the cookies set for/by our site, I don't see any called "SAML_SessionId". Does this mean that our implementation is not using cookies, and therefore we're not going to be affected by this change?
I downloaded the current dev preview of Chrome (81.0.4021.2) and also followed the instructions found here - https://www.chromium.org/updates/same-site - to "To test whether your sites may be affected by the SameSite changes", and I can still login to 3rd party sites using SAML SSO.
So I assume in our case, that we don't need to change anything?
Thanks,
Steve.
Is there some way of checking for sure whether our ComponentSpace SAML based implementation uses cookies? (as I wasn't aware it was).
If I open Chrome, run through a SAML login, and then use the appropriate settings tab to inspect the cookies set for/by our site, I don't see any called "SAML_SessionId". Does this mean that our implementation is not using cookies, and therefore we're not going to be affected by this change?
I downloaded the current dev preview of Chrome (81.0.4021.2) and also followed the instructions found here - https://www.chromium.org/updates/same-site - to "To test whether your sites may be affected by the SameSite changes", and I can still login to 3rd party sites using SAML SSO.
So I assume in our case, that we don't need to change anything?
Thanks,
Steve.
The "SAML_SessionId" cookie applies to v3.0.0 or later of the SAML library. In versions 2.5.0 to 2.8.8 of the SAML library the ASP.NET session cookie (eg ASP.NET_SessionId) is used instead.
If you're calling the SAML high-level API (ie the SAMLIdentityProvider and SAMLServiceProvider classes) the applicable cookie should be present and this cookie must have the SameSite=None and Secure attributes.
If instead you're calling the SAML low-level API no cookie is used as SAML session state isn't maintained and consequently the Chrome change has no impact.
[quote][/quote]
I want to confirm that no changes should be required for Chrome80. We are currently using ComponentSpace Version 2.2.0.13. We are also using the low level api. This was determined after reviewing the documentation which was sent in this email. (Please see the highlighted, bolded, underline information below).
I’d also like to understand why no changes are necessary when using an older version of ComponentSpace with the low level api.
FROM YOUR DOCUMENATION
What to do if using SAML Library v2.x....
After these changes, the SameSite parameter is included.
set-cookie: ASP.NET_SessionId=2s2wesefh0cohv0ugctun4hl; path=/; secure; HttpOnly; SameSite=None
Note though that if the ASP.NET update hasn’t been installed on the web server, the unrecognized cookieSameSite attribute will result in an “Unrecognized attribute” configuration error at runtime.
These changes are not required if calling the SAML low-level API rather than the more commonly used SAML high-level API.
Confirming Correct SameSite Support
It's highly recommended that after making the required changes, the SameSite support is confirmed.
For example, use the Browser developer tools to capture the network traffic.
I’d also like to understand why no changes are necessary when using an older version of ComponentSpace with the low level api.
FROM YOUR DOCUMENATION
What to do if using SAML Library v2.x....
After these changes, the SameSite parameter is included.
set-cookie: ASP.NET_SessionId=2s2wesefh0cohv0ugctun4hl; path=/; secure; HttpOnly; SameSite=None
Note though that if the ASP.NET update hasn’t been installed on the web server, the unrecognized cookieSameSite attribute will result in an “Unrecognized attribute” configuration error at runtime.
These changes are not required if calling the SAML low-level API rather than the more commonly used SAML high-level API.
Confirming Correct SameSite Support
It's highly recommended that after making the required changes, the SameSite support is confirmed.
For example, use the Browser developer tools to capture the network traffic.
That's correct. If using the SAML low-level API, the Chrome changes have no impact. The reason for this is that the SAML low-level API doesn't maintain SAML session state and consequently doesn't use a cookie.
The SAML high-level API was introduced in v2.5.0 of the SAML library. Depending on the version, either a custom SAML_SessionId cookie or the ASP.NET_SessionId cookie is used to maintain SAML session state.
SAML library releases earlier than v2.5.0 support the SAML low-level API only and are not affected by the Chrome changes.
Of course, even if using v2.5.0 or later, if the SAML low-level API is being called instead of the SAML high-level API, no cookie is used and the Crhome changes have no impact.
[quote]
[/quote]
Yes it will. I've updated the original post to make this clearer. Regardless of which .NET framework version you target, if you're using the SAML library v3.x the Chrome changes will impact SAML SSO. This assumes you're calling the SAML high-level API (ie the SAMLIdentityProvider and SAMLServiceProvider classes) rather than the less commonly used SAML low-level API.
The SAML library v3.x doesn't include calls into the .NET framework to specify the SameSite mode. The reason for this is that the SAML library supports .NET framework versions earlier than 4.7.2 when the SameSite mode wasn't part of the .NET framework API.
The SAML library v4.0.0 adds this support for setting the SameSite mode.
[quote][/quote]
My test server is Windows Server 2008 R2. It has the latest .Net Framework installed (4.8). We are using ComponentSpace 2.8.50. I added this line to web.config
I already had this line
Now I get the error
Parser Error Message: Unrecognized attribute 'cookieSameSite'. Note that attribute names are case-sensitive.
What is wrong?
I already had this line
Now I get the error
Parser Error Message: Unrecognized attribute 'cookieSameSite'. Note that attribute names are case-sensitive.
What is wrong?
Our testing was on Windows Server 2012. We haven't tested on 2008 but as far as I can tell as long as you have .NET framework v4.8 installed on the web server it should work.
Just to confirm, the element is in your section? If you remove the cookieSameSite="None" do you still get a parser error?
[quote][/quote]
Has anyone been able to get their saml service provider app to fail on google canary with these issues?
We are confused by the post also. We are using .net 4.5.1 framework and your 3.5 version. We have downloaded google canary which is version 81 and turned on the samesite features in flags but are unable to get our saml service provider application to fail with saml sso with your control. We do see the console warnings but contrary to what they say in google canary 81 the SAML_SessionId cookie is still there and we are unable to find a problem thus far.
We are confused by the post also. We are using .net 4.5.1 framework and your 3.5 version. We have downloaded google canary which is version 81 and turned on the samesite features in flags but are unable to get our saml service provider application to fail with saml sso with your control. We do see the console warnings but contrary to what they say in google canary 81 the SAML_SessionId cookie is still there and we are unable to find a problem thus far.
The code in the SAmlCookieHttpModule.cs states
/// Recent browser versions now default cookies to SameSite=Lax.
/// To support SAML SSO, the SAML session cookie must be SameSite=None.
What am I missing?[/quote]
What am I missing of the SAML_SessionId cookie does not exist and yet I get all of the data coming over in my ReceiveSSO like I did before? What's the use of the SAML_SessionId cookie anyways? My service provider app doesn't have the cookie but appears to be working just fine with no changes at all.
I finally found a way to actually turn on the functionality (which does not seem like it will turn on in Chrome 80 or 81) using the steps at https://knowyourtoolset.com/2020/01/testing-for-the-new-samesite-cookie-handling-changes/ with google chrome canary with startup arguments. From my take it looks like Google is threatening to turn this on in 80 but has no plans to actually change the behavior until 81
[/quote]
The SAML_SessionId cookie is used in the SAML library v3.0.0 and above to maintain SAML session state. There are some SAML flows where it doesn't matter if SAML state is maintained. For example, IdP-initiated SSO doesn't require SAML state. However, SP-initiated SSO and SLO do. It's safer to set the SameSite=None and Secure cookie attributes for all use cases.
Note that in the SAML library v2.5.0 - v2.8.8 the ASP.NET_SessionId cookie is used instead of a custom SAML_SessionId cookie.
Even if Google don't enable the changes in February they will do at some stage soon so it's better to prepare for them now.
For the kind of scenario where cookies might be used - I assume it would be where the IdP has to push the user past a “local” login page before SAML authentication takes place (and therefore needs somewhere to manage the storage of SAML request data before its ready to be processed)?
If we’re not doing that, then I guess cookies won’t be be used? Also, even if we were - the cookie would still be set providing the page Url domain matches the domain of the Url setting the cookie? (i.e. the login process isn’t embedded in an
Those are all fair points. Not all scenarios require SAML session state. For example, IdP-initiated SSO doesn’t require any SAML state and therefore the cookie may be lax.
SP-initiated SSO and SLO do require SAML session state and therefore the SameSite mode does come into play.
Of course, the best thing to do is to test that everything works with your particular setup.
For asp.net core projects if we update to the latest code and use the high level SSO routines like ReceiveSSO what if Internet Explorer and Safari 12 and lower browsers interact with the site - is your latest asp.net core 4 library released this month conditionally not doing SameSite: None for Internet Explorer and Safari < 13 browsers (ios or mac) since having samesite on those breaks the cookies completely . We don’t want to all of a sudden have IE and older than the current Safari browser users not being able to use our service provider application which uses your product for the high level SAML functionality
https://bugs.webkit.org/show_bug.cgi?id=198181
https://caniuse.com/#search=samesite
I only see code for safari not internet explorer in https://www.componentspace.com/Forums/10491/SAML-Cookie-SameSite-Mode-None - why is no old Chrome version or IE useragent sniffing code in there? https://www.chromium.org/updates/same-site/incompatible-clients
https://caniuse.com/#search=samesite
I only see code for safari not internet explorer in https://www.componentspace.com/Forums/10491/SAML-Cookie-SameSite-Mode-None - why is no old Chrome version or IE useragent sniffing code in there? https://www.chromium.org/updates/same-site/incompatible-clients
Seems like instead of all of the browser sniffing Auth0 is just having two cookies - one without any samesite attributes on the cookie and one with SamlSite: None; Secure - why isn’t componentspace doing this with their implementation to avoid all of the browser sniffing that is otherwise required? https://auth0.com/blog/browser-behavior-changes-what-developers-need-to-know/