ComponentSpace

Forums



SAML Cookie SameSite Mode None


SAML Cookie SameSite Mode None

Author
Message
earl
earl
New Member
New Member (5 reputation)New Member (5 reputation)New Member (5 reputation)New Member (5 reputation)New Member (5 reputation)New Member (5 reputation)New Member (5 reputation)New Member (5 reputation)New Member (5 reputation)

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
ComponentSpace Development
ComponentSpace Development (4.4K reputation)ComponentSpace Development (4.4K reputation)ComponentSpace Development (4.4K reputation)ComponentSpace Development (4.4K reputation)ComponentSpace Development (4.4K reputation)ComponentSpace Development (4.4K reputation)ComponentSpace Development (4.4K reputation)ComponentSpace Development (4.4K reputation)ComponentSpace Development (4.4K reputation)

Group: Administrators
Posts: 3.2K, Visits: 11K
lee - 1/21/2020
[quote]
lee - 1/21/2020
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-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.

Regards
ComponentSpace Development
ComponentSpace
ComponentSpace
ComponentSpace Development
ComponentSpace Development (4.4K reputation)ComponentSpace Development (4.4K reputation)ComponentSpace Development (4.4K reputation)ComponentSpace Development (4.4K reputation)ComponentSpace Development (4.4K reputation)ComponentSpace Development (4.4K reputation)ComponentSpace Development (4.4K reputation)ComponentSpace Development (4.4K reputation)ComponentSpace Development (4.4K reputation)

Group: Administrators
Posts: 3.2K, Visits: 11K
earl - 1/21/2020
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.

Regards
ComponentSpace Development
lee
lee
New Member
New Member (3 reputation)New Member (3 reputation)New Member (3 reputation)New Member (3 reputation)New Member (3 reputation)New Member (3 reputation)New Member (3 reputation)New Member (3 reputation)New Member (3 reputation)

Group: Forum Members
Posts: 3, Visits: 8
ComponentSpace - 1/21/2020
lee - 1/21/2020
[quote]
lee - 1/21/2020
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-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.

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
ComponentSpace Development
ComponentSpace Development (4.4K reputation)ComponentSpace Development (4.4K reputation)ComponentSpace Development (4.4K reputation)ComponentSpace Development (4.4K reputation)ComponentSpace Development (4.4K reputation)ComponentSpace Development (4.4K reputation)ComponentSpace Development (4.4K reputation)ComponentSpace Development (4.4K reputation)ComponentSpace Development (4.4K reputation)

Group: Administrators
Posts: 3.2K, Visits: 11K
lee - 1/22/2020
ComponentSpace - 1/21/2020
lee - 1/21/2020
[quote]
lee - 1/21/2020
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-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.

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
Pay
New Member
New Member (9 reputation)New Member (9 reputation)New Member (9 reputation)New Member (9 reputation)New Member (9 reputation)New Member (9 reputation)New Member (9 reputation)New Member (9 reputation)New Member (9 reputation)

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
ComponentSpace Development
ComponentSpace Development (4.4K reputation)ComponentSpace Development (4.4K reputation)ComponentSpace Development (4.4K reputation)ComponentSpace Development (4.4K reputation)ComponentSpace Development (4.4K reputation)ComponentSpace Development (4.4K reputation)ComponentSpace Development (4.4K reputation)ComponentSpace Development (4.4K reputation)ComponentSpace Development (4.4K reputation)

Group: Administrators
Posts: 3.2K, Visits: 11K
paywan - 1/23/2020
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

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.




Regards
ComponentSpace Development
alexey.korsakov
alexey.korsakov
New Member
New Member (9 reputation)New Member (9 reputation)New Member (9 reputation)New Member (9 reputation)New Member (9 reputation)New Member (9 reputation)New Member (9 reputation)New Member (9 reputation)New Member (9 reputation)

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
ComponentSpace Development
ComponentSpace Development (4.4K reputation)ComponentSpace Development (4.4K reputation)ComponentSpace Development (4.4K reputation)ComponentSpace Development (4.4K reputation)ComponentSpace Development (4.4K reputation)ComponentSpace Development (4.4K reputation)ComponentSpace Development (4.4K reputation)ComponentSpace Development (4.4K reputation)ComponentSpace Development (4.4K reputation)

Group: Administrators
Posts: 3.2K, Visits: 11K
alexey.korsakov - 1/24/2020
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

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.

Regards
ComponentSpace Development
ComponentSpace
ComponentSpace
ComponentSpace Development
ComponentSpace Development (4.4K reputation)ComponentSpace Development (4.4K reputation)ComponentSpace Development (4.4K reputation)ComponentSpace Development (4.4K reputation)ComponentSpace Development (4.4K reputation)ComponentSpace Development (4.4K reputation)ComponentSpace Development (4.4K reputation)ComponentSpace Development (4.4K reputation)ComponentSpace Development (4.4K reputation)

Group: Administrators
Posts: 3.2K, Visits: 11K
mlam - 1/24/2020
ComponentSpace - 1/4/2020
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>
  <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-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.

Regards
ComponentSpace Development
GO


Similar Topics


Execution: 0.000. 2 queries. Compression Enabled.
Login
Existing Account
Email Address:


Password:


Select a Forum....












Forums, Documentation & Knowledge Base - ComponentSpace


Search