The ASP.NET_SessionId cookie looks fine. It has the Secure and SameSite=None attributes.
Is there another cookie in the list (wasn’t sure if all the cookies were on display) without SameSite explicitly set?
[quote]
Just to confirm, this is the ASP.NET_SessionId cookie?
Could you include the full set-cookie header?
Could you include the full set-cookie header?
Set-Cookie: user_activity=1579155584; domain=intraminglesite.com; path=/; secure
Thanks[/quote]
The default cookie name for the ASP.NET session is "ASP.NET_SessionId". Please check for a Set-Cookie header for this cookie.
[/quote]
Set-Cookie: ASP.NET_SessionId=6c06d7d7-6aea-4ed6-a68d-3f63e43f7f4f12; path=/; secure; HttpOnly
Set-Cookie: AWSELB=DD83512F1E37455783B3049A0BB616A7DC489B769BCA2BD75E555F2352F9C26D00C4E0010F7AE9AD1547A9F20ABD0C5AF30D9B0F2A3A8A4A747666C73E8FE3EE508F06F265;PATH=/
THanks,
THanks,
It doesn't appear the HTTP module is being invoked.
Please enable SAML trace and send the generated log file as an email attachment to support@componentspace.com mentioning the issue with the cookie.
https://www.componentspace.com/Forums/17/Enabing-SAML-Trace
The log will indicate whether the HTTP module has been initialized and invoked.
[/quote]
I have sent the log from the trace via private message. Please check. Thank you..
Please send the log as an email attachment to support@componentspace.com including any background information.
Hi,
I would just like to get confirmation regarding the behavior I observed:
.Net target framework: 4.7.2
.Net framework installed: 4.8
SAML DLL version: 4.0.0.0
The above combination only works if I add below settings in Web.config:
<sessionStatecookieSameSite=“None” />
<httpCookiesrequireSSL=“true”/>
Otherwise, ASP.NET_SessionId cookie will have “SameSite=Lax”.
Can you please confirm that the above Web.config changes are really required? I am a bit confused with the below highighted statement whether that is already part of SAML library implementation:
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.
[quote][/quote]
Hi,
I would just like to get confirmation regarding the behavior I observed:
.Net target framework: 4.7.2
.Net framework installed: 4.8
SAML DLL version: 4.0.0.0
The above combination only works if I add below settings in Web.config:
Otherwise, ASP.NET_SessionId cookie will have "SameSite=Lax".
Can you please confirm that the above Web.config changes are really required? I am a bit confused with the below highighted statement whether that is already part of SAML library implementation:
I would just like to get confirmation regarding the behavior I observed:
.Net target framework: 4.7.2
.Net framework installed: 4.8
SAML DLL version: 4.0.0.0
The above combination only works if I add below settings in Web.config:
Otherwise, ASP.NET_SessionId cookie will have "SameSite=Lax".
Can you please confirm that the above Web.config changes are really required? I am a bit confused with the below highighted statement whether that is already part of SAML library implementation:
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.
Versions 3.0.0 and later use a custom cookie named SAMLSession_Id. Versions 2.5.0 to v2.8.8 use the ASP.NET_SessionId cookie instead.
If you're using v4.0.0, nothing else is required. The SAMLSession_Id cookie will have the SameSite=None and Secure attributes set automatically. The web.config settings are to set these attributes on the ASP.NET_SessionId cookie when using v2.5.0 to 2.8.8 and don't apply for any versions from 3.0.0 and later.
[quote][/quote]
Hi,
I would just like to get confirmation regarding the behavior I observed:
.Net target framework: 4.7.2
.Net framework installed: 4.8
SAML DLL version: 4.0.0.0
The above combination only works if I add below settings in Web.config:
Otherwise, ASP.NET_SessionId cookie will have "SameSite=Lax".
Can you please confirm that the above Web.config changes are really required? I am a bit confused with the below highighted statement whether that is already part of SAML library implementation:
I would just like to get confirmation regarding the behavior I observed:
.Net target framework: 4.7.2
.Net framework installed: 4.8
SAML DLL version: 4.0.0.0
The above combination only works if I add below settings in Web.config:
Otherwise, ASP.NET_SessionId cookie will have "SameSite=Lax".
Can you please confirm that the above Web.config changes are really required? I am a bit confused with the below highighted statement whether that is already part of SAML library implementation:
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.
Versions 3.0.0 and later use a custom cookie named SAMLSession_Id. Versions 2.5.0 to v2.8.8 use the ASP.NET_SessionId cookie instead.
If you're using v4.0.0, nothing else is required. The SAMLSession_Id cookie will have the SameSite=None and Secure attributes set automatically. The web.config settings are to set these attributes on the ASP.NET_SessionId cookie when using v2.5.0 to 2.8.8 and don't apply for any versions from 3.0.0 and later.[/quote]
I confirmed that the SAMLSession_Id was being passed from IDP to SP. However, I realized that it was the ASP.Net session ID that is missing and we needed to retain the same session after the authentication. In this case, we needed the Web.config settings to achieve this. Is my understanding correct?
That’s correct. If you need to retain the ASP.NET session you need to update the web.config as described.
Hi.
Using ComponentSpace.SAML2.dll v2.6.0.16 (SAML v2.0 for .NET4) for SP-initiated SSO using the high-level SAMLServiceProvider.InitiateSSO(). What information is actually stored in the ASP.NET session in this scenario, and how important is it?
I ask, because I can’t break SSO. i.e. I browse to the SP site. I use Chrome’s dev tools to verify that the SP site is setting an ASP.NET_SessionId cookie in the response headers. In the browser, I get automatically bounced to the IdP, which prompts me to sign in. Before doing so, I open up a second tab, browse to a SP page that doesn’t require signing in, and use Chrome’s dev tools to delete all cookies in the SP’s domain, including the ASP.NET_SessionId. Back in my first tab, I sign in, and I get bounced back to the SP site, and everything works as expected. This is despite the fact that I can see that the POST to the ACS URL did not have the ASP.NET_SessionId cookie in the request headers (or any cookies). (In fact, ASP.NET sent a fresh ASP.NET_SessionId cookie with a new ID in the response to the ACS POST, confirm that the old session was not accessible.)
So despite the fact that ASP.NET_SessionId cookie is being deleted between the first SAMLServiceProvider.InitiateSSO() call made when initiating SSO and the second SAMLServiceProvider.InitiateSSO() call made when verifying the SAML response, everything worked, and the user was logged in. I’m assuming that this means it will continue to work when Chrome fails to send the ASP.NET_SessionId cookie in the future.
So whatever information is being stored in session state by ComponentSpace.SAML2.dll v2.6.0.16 seems to be irrelevant to a SP-initiated flow completing successfully.
Giving this testing, do you think I’m good to support future releases of Chrome despite not having SameSite=None on the ASP.NET_SessionId cookie, or have I misunderstood something?
Thanks.
[quote]
So despite the fact that ASP.NET_SessionId cookie is being deleted between the first SAMLServiceProvider.InitiateSSO() call made when initiating SSO and the second SAMLServiceProvider.InitiateSSO() call made when verifying the SAML response, everything worked, and the user was logged in. I'm assuming that this means it will continue to work when Chrome fails to send the ASP.NET_SessionId cookie in the future.
I meant to write "between the SAMLServiceProvider.InitiateSSO() call made when initiating SSO and the SAMLServiceProvider.ReceiveSSO() call". (The "Update Post" button doesn't seem to work for me.)
[quote]
So despite the fact that ASP.NET_SessionId cookie is being deleted between the first SAMLServiceProvider.InitiateSSO() call made when initiating SSO and the second SAMLServiceProvider.InitiateSSO() call made when verifying the SAML response, everything worked, and the user was logged in. I'm assuming that this means it will continue to work when Chrome fails to send the ASP.NET_SessionId cookie in the future.
I meant to write "between the SAMLServiceProvider.InitiateSSO() call made when initiating SSO and the SAMLServiceProvider.ReceiveSSO() call". (The "Update Post" button doesn't seem to work for me.)
[/quote]
Hey Lee,
Check my post. Not sure if it will help.
I couldn't break mine either. Also from reading, I'm not 100% that the change will happen in Chrome 80 or 81.
In short, I followed a link from another user to get a "warning" in chrome console. Note, this never broke my SSO.
But following the steps did prevent the warning, so I just did it as proactive.
Here's the steps I used to get the warning:
https://knowyourtoolset.com/2020/01/testing-for-the-new-samesite-cookie-handling-changes/
Do you have something similar to SameSite Startup Code to fix incompatible browsers for ASP.Net?
[quote]
So despite the fact that ASP.NET_SessionId cookie is being deleted between the first SAMLServiceProvider.InitiateSSO() call made when initiating SSO and the second SAMLServiceProvider.InitiateSSO() call made when verifying the SAML response, everything worked, and the user was logged in. I'm assuming that this means it will continue to work when Chrome fails to send the ASP.NET_SessionId cookie in the future.
I meant to write "between the SAMLServiceProvider.InitiateSSO() call made when initiating SSO and the SAMLServiceProvider.ReceiveSSO() call". (The "Update Post" button doesn't seem to work for me.)
[/quote]
Please take a look at:
https://www.componentspace.com/Forums/10602/SAML-Session-Cookie-When-Is-It-Needed
The SAML session state and associated cookie is used in support of the SAML protocol. For some flows, no SAML session state is required. For others, SAML session state is desirable but not mandatory. And for some, SAML session state is mandatory.
When acting as the SP in SP-initiated SSO, SAML session state is desirable but not mandatory. It means that we cannot perform a minor security check of the InResponseTo field but SAML SSO will otherwise work. It's effectively the same as if it were IdP-initiated SSO.
Therefore, in your scenario everything will continue to work after the Chrome update.
However, just be aware that if in future you wished to support SAML logout, for example, this may not work without taking the steps described in this forum post.
[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]
So despite the fact that ASP.NET_SessionId cookie is being deleted between the first SAMLServiceProvider.InitiateSSO() call made when initiating SSO and the second SAMLServiceProvider.InitiateSSO() call made when verifying the SAML response, everything worked, and the user was logged in. I'm assuming that this means it will continue to work when Chrome fails to send the ASP.NET_SessionId cookie in the future.
I meant to write "between the SAMLServiceProvider.InitiateSSO() call made when initiating SSO and the SAMLServiceProvider.ReceiveSSO() call". (The "Update Post" button doesn't seem to work for me.)
[/quote]
Please take a look at:
https://www.componentspace.com/Forums/10602/SAML-Session-Cookie-When-Is-It-Needed
The SAML session state and associated cookie is used in support of the SAML protocol. For some flows, no SAML session state is required. For others, SAML session state is desirable but not mandatory. And for some, SAML session state is mandatory.
When acting as the SP in SP-initiated SSO, SAML session state is desirable but not mandatory. It means that we cannot perform a minor security check of the InResponseTo field but SAML SSO will otherwise work. It's effectively the same as if it were IdP-initiated SSO.
Therefore, in your scenario everything will continue to work after the Chrome update.
However, just be aware that if in future you wished to support SAML logout, for example, this may not work without taking the steps described in this forum post.[/quote]
Thanks for the explanation of when state is required. Continuing to work without a minor security check in our SP-initiated flow as a SP is good enough, and we don't care about ASP.NET session state ourselves until after the user has logged in, so it looks like I'm all good.
[quote]
So despite the fact that ASP.NET_SessionId cookie is being deleted between the first SAMLServiceProvider.InitiateSSO() call made when initiating SSO and the second SAMLServiceProvider.InitiateSSO() call made when verifying the SAML response, everything worked, and the user was logged in. I'm assuming that this means it will continue to work when Chrome fails to send the ASP.NET_SessionId cookie in the future.
I meant to write "between the SAMLServiceProvider.InitiateSSO() call made when initiating SSO and the SAMLServiceProvider.ReceiveSSO() call". (The "Update Post" button doesn't seem to work for me.)
[/quote]
Please take a look at:
https://www.componentspace.com/Forums/10602/SAML-Session-Cookie-When-Is-It-Needed
The SAML session state and associated cookie is used in support of the SAML protocol. For some flows, no SAML session state is required. For others, SAML session state is desirable but not mandatory. And for some, SAML session state is mandatory.
When acting as the SP in SP-initiated SSO, SAML session state is desirable but not mandatory. It means that we cannot perform a minor security check of the InResponseTo field but SAML SSO will otherwise work. It's effectively the same as if it were IdP-initiated SSO.
Therefore, in your scenario everything will continue to work after the Chrome update.
However, just be aware that if in future you wished to support SAML logout, for example, this may not work without taking the steps described in this forum post.[/quote]
Thanks for the explanation of when state is required. Continuing to work without a minor security check in our SP-initiated flow as a SP is good enough, and we don't care about ASP.NET session state ourselves until after the user has logged in, so it looks like I'm all good.[/quote]
Sounds good.
Hi,
Sorry, need a little confirmation and help here. If i have both SP and Idp setup using component space, do i need SameSite setup on both SP and Idp? I can see Idp have SameSite value on it but SP only have HTTPOnly and Secure flag turned on (I had to remove from SP after adding samesite value, the site became incredible slow). I still can login and logout with other SP without any issues.
Thanks.
Pay
[quote][/quote]
Hi,
Sorry, need a little confirmation and help here. If i have both SP and Idp setup using component space, do i need SameSite setup on both SP and Idp? I can see Idp have SameSite value on it but SP only have HTTPOnly and Secure flag turned on (I had to remove from SP after adding samesite value, the site became incredible slow). I still can login and logout with other SP without any issues.
Thanks.
Pay
Sorry, need a little confirmation and help here. If i have both SP and Idp setup using component space, do i need SameSite setup on both SP and Idp? I can see Idp have SameSite value on it but SP only have HTTPOnly and Secure flag turned on (I had to remove from SP after adding samesite value, the site became incredible slow). I still can login and logout with other SP without any issues.
Thanks.
Pay
I'm not sure why the SameSite attribute would affect the speed. The only impact is whether or not the browser returns the cookie.
If your SP is supporting SSO only and not SLO (SAML logout), you shouldn't have any issues with the Chrome update and no changes would be required in your SP. For more details, please refer to:
https://www.componentspace.com/Forums/10602/SAML-Session-Cookie-When-Is-It-Needed
If you've tested with the Chrome updates and everything is working, you should be good.
I have read the post carefully, but still it is not clear for me, should I take any actions.
I cannot reproduce any problems with Chrome Canary (enabling the feature , etc). So I will not be able to prove that I did everything correctly.
Our web app authenticates with IdP using componentspace library. No logout.
We are using v3.1.0 and the framework is 4.6.2, but I have found only one cookie which looks like discribed and its name is “ASP.NET_SesionId”, not “SAML_SessionId”
Should I anyway add and enable http module?
I could check the cookie value (if it changes when update), but name still confuses me
[quote][/quote]
I have read the post carefully, but still it is not clear for me, should I take any actions.
I cannot reproduce any problems with Chrome Canary (enabling the feature , etc). So I will not be able to prove that I did everything correctly.
Our web app authenticates with IdP using componentspace library. No logout.
We are using v3.1.0 and the framework is 4.6.2, but I have found only one cookie which looks like discribed and its name is "ASP.NET_SesionId", not "SAML_SessionId"
Should I anyway add and enable http module?
I could check the cookie value (if it changes when update), but name still confuses me
I cannot reproduce any problems with Chrome Canary (enabling the feature , etc). So I will not be able to prove that I did everything correctly.
Our web app authenticates with IdP using componentspace library. No logout.
We are using v3.1.0 and the framework is 4.6.2, but I have found only one cookie which looks like discribed and its name is "ASP.NET_SesionId", not "SAML_SessionId"
Should I anyway add and enable http module?
I could check the cookie value (if it changes when update), but name still confuses me
In version 3.0.0 and above of the SAML library, we use a custom SAML_SessionId cookie by default. Prior to this, we used the ASP.NET session cookie (default name of ASP.NET_SessionId).
Not all SAML SSO flows require SAML session state and the corresponding cookie. Please take a look at the following for more information:
https://www.componentspace.com/Forums/10602/SAML-Session-Cookie-When-Is-It-Needed
Regarding the testing, be careful of the "Lax + POST" temporary intervention described in:
https://www.componentspace.com/Forums/10603/SAML-Cookie-SameSite-Testing-with-Chrome
If you're satisfied after your testing that everything is still working, no changes are required. You won't need to configure the HTTP module.
[quote][/quote]
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.
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.
Hi
I found my SAML dlls is 3.1.0.0 for .NET 4.6.2 and my .NET target is 4.7.2 does the following step still work for me to avoid the Chrome 80's issue?
The following steps should be taken:Thanks and hope to hear from you soon.
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.
Regards
MF Lam
[/quote]
Yes, that's correct. Adding the HTTP module will set the SameSite=None attribute on the SAML_SessionId cookie.
Depending on what SAML flows you support, this may not be necessary. However, the safest option is to make the change anyway.
You'll find more information about when the SAML cookie is needed and therefore potentially affected by the Chrome update at:
https://www.componentspace.com/Forums/10602/SAML-Session-Cookie-When-Is-It-Needed
If you believe you're not affected and you've confirmed this by testing with the Chrome update, no changes are required.
Otherwise, we recommend adding the HTTP module.