earl
|
|
Group: Forum Members
Posts: 7,
Visits: 58
|
Do you have something similar to SameSite Startup Code to fix incompatible browsers for ASP.Net?
|
|
|
ComponentSpace
|
|
ComponentSpace Development
Group: Administrators
Posts: 3.2K,
Visits: 11K
|
+x+x[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.) Please take a look at: https://www.componentspace.com/Forums/10602/SAML-Session-Cookie-When-Is-It-NeededThe 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.
Regards ComponentSpace Development
|
|
|
ComponentSpace
|
|
ComponentSpace Development
Group: Administrators
Posts: 3.2K,
Visits: 11K
|
The HTTP Module includes similar functionality for SAML for ASP.NET library releases prior to v4.0.0. SAML Cookie HTTP ModuleVersion 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.
Regards ComponentSpace Development
|
|
|
lee
|
|
Group: Forum Members
Posts: 3,
Visits: 8
|
+x+x+x[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.) Please take a look at: https://www.componentspace.com/Forums/10602/SAML-Session-Cookie-When-Is-It-NeededThe 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. 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.
|
|
|
ComponentSpace
|
|
ComponentSpace Development
Group: Administrators
Posts: 3.2K,
Visits: 11K
|
+x+x+x+x[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.) Please take a look at: https://www.componentspace.com/Forums/10602/SAML-Session-Cookie-When-Is-It-NeededThe 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. 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. Sounds good.
Regards ComponentSpace Development
|
|
|
Pay
|
|
Group: Forum Members
Posts: 6,
Visits: 48
|
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
Pay
|
|
|
ComponentSpace
|
|
ComponentSpace Development
Group: Administrators
Posts: 3.2K,
Visits: 11K
|
+xHi, 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-NeededIf you've tested with the Chrome updates and everything is working, you should be good.
Regards ComponentSpace Development
|
|
|
alexey.korsakov
|
|
Group: Forum Members
Posts: 5,
Visits: 27
|
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
|
|
|
ComponentSpace
|
|
ComponentSpace Development
Group: Administrators
Posts: 3.2K,
Visits: 11K
|
+xI 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 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-NeededRegarding the testing, be careful of the "Lax + POST" temporary intervention described in: https://www.componentspace.com/Forums/10603/SAML-Cookie-SameSite-Testing-with-ChromeIf you're satisfied after your testing that everything is still working, no changes are required. You won't need to configure the HTTP module.
Regards ComponentSpace Development
|
|
|
ComponentSpace
|
|
ComponentSpace Development
Group: Administrators
Posts: 3.2K,
Visits: 11K
|
+x+xWhat 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 ModuleNote 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> <modules> <add name="SAMLCookieHttpModule" type="ComponentSpace.SAML2.SAMLCookieHttpModule"/> </modules> </system.webServer>
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: 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> <modules> <add name="SAMLCookieHttpModule" type="ComponentSpace.SAML2.SAMLCookieHttpModule"/> </modules> </system.webServer>
Thanks and hope to hear from you soon. Regards MF Lam 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-NeededIf 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.
Regards ComponentSpace Development
|
|
|