/Copyright (c) 2016 Interaktiva rum Sverige (Interactive rooms Sweden)Website: http://www.interaktivarum.se/enPermission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the “Software”), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.THE SOFTWARE IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.//* The color filters are defined in external SVG file rgblind.svg, located in same folder as this CSS file. Use this CSS file when injecting both the CSS style rules and the SVG filters into the HTML document.*/.protanopia{ filter: url(‘#protanopia’); -webkit-filter: url(‘#protanopia’); color-interpolation-filters:sRGB; }.deuteranopia{ filter: url(‘#deuteranopia’); -webkit-filter: url(‘#deuteranopia’); color-interpolation-filters:sRGB; }Hi,
I’m running 2.8.8 in an MVC project targeting dotNet framework 4.5.2. I’ve added the lines for and in the web.config in the root of the project and upgraded the server with dotNet Framework 4.8 on Windows Server 2012 R2.
I can now see the ASP.NET_SessionId cookie is returning secure=true but I still see SameSite=Unset. Are there any other steps that can be taken to figure out why SameSite isn’t being set to none?
[quote][/quote]
/*Copyright (c) 2016 Interaktiva rum Sverige (Interactive rooms Sweden)Website: http://www.interaktivarum.se/enPermission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.*//* The color filters are defined in external SVG file rgblind.svg, located in same folder as this CSS file. Use this CSS file when injecting both the CSS style rules and the SVG filters into the HTML document.*/.protanopia{ filter: url('#protanopia'); -webkit-filter: url('#protanopia'); color-interpolation-filters:sRGB; }.deuteranopia{ filter: url('#deuteranopia'); -webkit-filter: url('#deuteranopia'); color-interpolation-filters:sRGB; }Hi,
I'm running 2.8.8 in an MVC project targeting dotNet framework 4.5.2. I've added the lines for and in the web.config in the root of the project and upgraded the server with dotNet Framework 4.8 on Windows Server 2012 R2.
I can now see the ASP.NET_SessionId cookie is returning secure=true but I still see SameSite=Unset. Are there any other steps that can be taken to figure out why SameSite isn't being set to none?
I'm running 2.8.8 in an MVC project targeting dotNet framework 4.5.2. I've added the lines for and in the web.config in the root of the project and upgraded the server with dotNet Framework 4.8 on Windows Server 2012 R2.
I can now see the ASP.NET_SessionId cookie is returning secure=true but I still see SameSite=Unset. Are there any other steps that can be taken to figure out why SameSite isn't being set to none?
Those should be the only steps required.
Which browser are you using? For Firefox, make sure to switch to the Header view and to view the raw headers.
[quote][/quote]
Do you have something similar to SameSite Startup Code to fix incompatible browsers for ASP.Net?
The HTTP Module includes similar functionality for SAML for ASP.NET library releases prior to v4.0.0.
SAML Cookie HTTP Module
Version 4.0.0 of SAML for ASP.NET has equivalent functionality inbuilt.
The ASP.NET Core code we supply has similar functionality but the packaging is different.[/quote]
Hi,
I'm using SAML 2.5.2 and .Net 4.8 and I tried using SAMLCookieHttpModule by changing Saml session id to ASP.NET_SessionId, but SameSite attribute is not getting added in ASP.NetSessionId cookie... On debugging, I found that httpContext.Response.Cookies.Count is always 0. Do you see any specific reason for that?
Thanks,
Vandana
Hi Vandana,
For SAML library v2.x we recommend modifying the Microsoft configuration in web.config rather than using the HTTP module.
It’s possible you may not be impacted by the Chrome update and therefore won’t need to make any changes.
Are you calling the SAML high-level API or SAML low-level API?
The SAML high-level API includes the SAMLIdentityProvider and SAMLServiceProvider classes.
Do you have a SAML configuration (eg saml.config file)?
A SAML configuration only applies if using the SAML high-level API.
Is your site acting as the identity provider or service provider?
Are you supporting IdP-initiated SSO or SP-initiated SSO?
Are you supporting SLO (ie SAML logout)?
If you’re calling the SAML low-level API only you wont be affected by the Chrome update as this API doesn’t use cookies.
If you’re calling the SAML high-level API, you’re acting as the SP and you’re not supporting SLO, you shouldn’t be affected by the Chrome update.
For an explanation as to why, please refer to:
https://componentspace.com/Forums/10602/SAML-Session-Cookie-When-Is-It-Needed
Regardless, you should test your SAML flows to confirm everything works with the Chrome update as described in the “Configuring Chrome” section of the following post:
https://componentspace.com/Forums/10603/SAML-Cookie-SameSite-Testing-with-Chrome
[quote][/quote]
Thanks for the quick reply. We are supporting IDP Initiated SSO. We don't support SAML logout. Hi Vandana,
For SAML library v2.x we recommend modifying the Microsoft configuration in web.config rather than using the HTTP module.
It's possible you may not be impacted by the Chrome update and therefore won't need to make any changes.
Are you calling the SAML high-level API or SAML low-level API?
The SAML high-level API includes the SAMLIdentityProvider and SAMLServiceProvider classes.
Do you have a SAML configuration (eg saml.config file)?
A SAML configuration only applies if using the SAML high-level API.
Is your site acting as the identity provider or service provider?
Are you supporting IdP-initiated SSO or SP-initiated SSO?
Are you supporting SLO (ie SAML logout)?
If you're calling the SAML low-level API only you wont be affected by the Chrome update as this API doesn't use cookies.
If you're calling the SAML high-level API, you're acting as the SP and you're not supporting SLO, you shouldn't be affected by the Chrome update.
For an explanation as to why, please refer to:
https://componentspace.com/Forums/10602/SAML-Session-Cookie-When-Is-It-Needed
Regardless, you should test your SAML flows to confirm everything works with the Chrome update as described in the "Configuring Chrome" section of the following post:
https://componentspace.com/Forums/10603/SAML-Cookie-SameSite-Testing-with-Chrome
For SAML library v2.x we recommend modifying the Microsoft configuration in web.config rather than using the HTTP module.
It's possible you may not be impacted by the Chrome update and therefore won't need to make any changes.
Are you calling the SAML high-level API or SAML low-level API?
The SAML high-level API includes the SAMLIdentityProvider and SAMLServiceProvider classes.
Do you have a SAML configuration (eg saml.config file)?
A SAML configuration only applies if using the SAML high-level API.
Is your site acting as the identity provider or service provider?
Are you supporting IdP-initiated SSO or SP-initiated SSO?
Are you supporting SLO (ie SAML logout)?
If you're calling the SAML low-level API only you wont be affected by the Chrome update as this API doesn't use cookies.
If you're calling the SAML high-level API, you're acting as the SP and you're not supporting SLO, you shouldn't be affected by the Chrome update.
For an explanation as to why, please refer to:
https://componentspace.com/Forums/10602/SAML-Session-Cookie-When-Is-It-Needed
Regardless, you should test your SAML flows to confirm everything works with the Chrome update as described in the "Configuring Chrome" section of the following post:
https://componentspace.com/Forums/10603/SAML-Cookie-SameSite-Testing-with-Chrome
I enabled the samesite flags on Chrom 76 and it didn't affect our flows. So does that mean we won't be affected by this?
Also, does it mean we don't need to set our ASP.Net Sesssion Id cookies with samesite=none attribute?
I had an issue where I couldn’t get samesite to set using the suggested solution for > 2.5 but < 3.0. I ended up creating a rewrite rule for it. Here’s what I did in case anyone finds it useful.
[quote][/quote]
Thanks for the quick reply. We are supporting IDP Initiated SSO. We don't support SAML logout. Hi Vandana,
For SAML library v2.x we recommend modifying the Microsoft configuration in web.config rather than using the HTTP module.
It's possible you may not be impacted by the Chrome update and therefore won't need to make any changes.
Are you calling the SAML high-level API or SAML low-level API?
The SAML high-level API includes the SAMLIdentityProvider and SAMLServiceProvider classes.
Do you have a SAML configuration (eg saml.config file)?
A SAML configuration only applies if using the SAML high-level API.
Is your site acting as the identity provider or service provider?
Are you supporting IdP-initiated SSO or SP-initiated SSO?
Are you supporting SLO (ie SAML logout)?
If you're calling the SAML low-level API only you wont be affected by the Chrome update as this API doesn't use cookies.
If you're calling the SAML high-level API, you're acting as the SP and you're not supporting SLO, you shouldn't be affected by the Chrome update.
For an explanation as to why, please refer to:
https://componentspace.com/Forums/10602/SAML-Session-Cookie-When-Is-It-Needed
Regardless, you should test your SAML flows to confirm everything works with the Chrome update as described in the "Configuring Chrome" section of the following post:
https://componentspace.com/Forums/10603/SAML-Cookie-SameSite-Testing-with-Chrome
For SAML library v2.x we recommend modifying the Microsoft configuration in web.config rather than using the HTTP module.
It's possible you may not be impacted by the Chrome update and therefore won't need to make any changes.
Are you calling the SAML high-level API or SAML low-level API?
The SAML high-level API includes the SAMLIdentityProvider and SAMLServiceProvider classes.
Do you have a SAML configuration (eg saml.config file)?
A SAML configuration only applies if using the SAML high-level API.
Is your site acting as the identity provider or service provider?
Are you supporting IdP-initiated SSO or SP-initiated SSO?
Are you supporting SLO (ie SAML logout)?
If you're calling the SAML low-level API only you wont be affected by the Chrome update as this API doesn't use cookies.
If you're calling the SAML high-level API, you're acting as the SP and you're not supporting SLO, you shouldn't be affected by the Chrome update.
For an explanation as to why, please refer to:
https://componentspace.com/Forums/10602/SAML-Session-Cookie-When-Is-It-Needed
Regardless, you should test your SAML flows to confirm everything works with the Chrome update as described in the "Configuring Chrome" section of the following post:
https://componentspace.com/Forums/10603/SAML-Cookie-SameSite-Testing-with-Chrome
I enabled the samesite flags on Chrom 76 and it didn't affect our flows. So does that mean we won't be affected by this?
Also, does it mean we don't need to set our ASP.Net Sesssion Id cookies with samesite=none attribute?
[/quote]
Yes, the Chrome updates shouldn't affect you.
I suggest letting the ASP.NET_SessionId cookie default to SameSite=Lax by removing the configuration and retesting with the Chrome updates to confirm everything is still working.
[quote]
[/quote]
Thanks for sharing.
I've updated the post with some additional information regarding Microsoft KB article 4531182 and KB article 4524421. Without the updates, the None value does not emit the SameSite cookie header. Our test servers were up to date and we didn't have to explicitly install these KB updates but this is possibly what the issue is with your setup.
[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.
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.
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/
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.
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/
I would not like to require SSL for development purposes in SSO scenarios. However, the Secure attribute for the saml-session cookie makes me use it. Is it possible to use http connection instead of https?
SAML Library: v4.2.0
Target framework .Net 6.0
Default response cookies: Set-Cookie: saml-session=96368e8c-8679-4170-99a6-addef791a027; path=/; secure; samesite=none; httponly
Thanks.
I’m afraid this isn’t possible. The cross-site flows of SAML SSO mean we must specify SameSite=None and this then requires the Secure cookie property.