SAML Cookie SameSite Mode None

SAML for ASP.NET
21
[quote]
CBRon - 1/13/2020
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]

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]
Yes, the element is present. And I do not get the parser error if I remove the cookieSameSite="None" attribute. One other potential issue - this is a legacy app that is using the .Net framework 2.0 (actually 3.5). Could that be an issue? I also had another idea. What if I add the SameSite attribute to the Response cookie using an URL Rewrite outbound rule? Would that work?
22

I have an ASP.NET application targeting 4.5 using the SAML library v2.x so I followed the process of installing v4.8 Framework and changing the web.config, but so far I’m not seeing SameSite=none in the set cookie:

aspxauth=… path=/; HttpOnly

Is there any trick to upgrading the ASP.NET app pool? From what I’m reading it should take the updated framework. I even verified the registry to make sure the correct .Net framework version is installed.

23
[quote]
mov3 - 1/14/2020
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/
[/quote]

We could do this with the custom SAML session cookie but I don't think this is possible with the ASP.NET session cookie.

The browser sniffing is an interim solution that hopefully won't be needed in the near future.

There is the option to customize the implementation of the cookie setting in the latest product releases if you would prefer the approach you suggested.
24
[quote]
CBRon - 1/13/2020
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]

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]
Yes, the element is present. And I do not get the parser error if I remove the cookieSameSite="None" attribute. One other potential issue - this is a legacy app that is using the .Net framework 2.0 (actually 3.5). Could that be an issue? I also had another idea. What if I add the SameSite attribute to the Response cookie using an URL Rewrite outbound rule? Would that work?
[/quote]
I haven't tried it but it's worth taking a look if you like. As long as you see the Secure and SameSite=None in the set-cookie header, that's all that's required.

Just to confirm, you have .NET framework v4.8 installed on the web server?
25
[quote]
csnyder - 1/14/2020
I have an ASP.NET application targeting 4.5 using the SAML library v2.x so I followed the process of installing v4.8 Framework and changing the web.config, but so far I'm not seeing SameSite=none in the set cookie:

aspxauth=... path=/; HttpOnly

Is there any trick to upgrading the ASP.NET app pool? From what I'm reading it should take the updated framework. I even verified the registry to make sure the correct .Net framework version is installed.
[/quote]

The aspxauth cookie is the authorization cookie rather than the session cookie.

You should be looking for a cookie whose name is ASP.NET_SessionId, unless you've changed the default name for this cookie.

The following post shows where I changed the cookie name to My.ASP.NET_SessionId just to make this clearer. However, using the default name of ASP.NET_SessionId is perfectly fine.

https://www.componentspace.com/Forums/10552/Chrome-SameSite-Cookie-Change


26
[quote]
csnyder - 1/14/2020
I have an ASP.NET application targeting 4.5 using the SAML library v2.x so I followed the process of installing v4.8 Framework and changing the web.config, but so far I'm not seeing SameSite=none in the set cookie:

aspxauth=... path=/; HttpOnly

Is there any trick to upgrading the ASP.NET app pool? From what I'm reading it should take the updated framework. I even verified the registry to make sure the correct .Net framework version is installed.
[/quote]

We also encountering this issue. Our web project is 4.5.1 and were using SAMLv 2.6. We updated the web.config and installed .NET Framework 4.8 runtime in the web server.

Were getting this result:

refCode=0; path=/; secure; HttpOnly

Cheers,
27

Just to confirm, this is the ASP.NET_SessionId cookie?

Could you include the full set-cookie header?

28
[quote]
CBRon - 1/13/2020
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]

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]
Yes, the element is present. And I do not get the parser error if I remove the cookieSameSite="None" attribute. One other potential issue - this is a legacy app that is using the .Net framework 2.0 (actually 3.5). Could that be an issue? I also had another idea. What if I add the SameSite attribute to the Response cookie using an URL Rewrite outbound rule? Would that work?
[/quote]
I haven't tried it but it's worth taking a look if you like. As long as you see the Secure and SameSite=None in the set-cookie header, that's all that's required.

Just to confirm, you have .NET framework v4.8 installed on the web server?[/quote]
Yes, I have .NET Framework 4.8 installed on the server.
29
[quote]
ComponentSpace - 1/14/2020
Just to confirm, this is the ASP.NET_SessionId cookie?

Could you include the full set-cookie header?
[/quote]

The set cookie header on our server is returning:
Server: Microsoft-IIS/8.5
Set-Cookie: .ASPXAUTH=130960F2BE1F38E1E090B5E8BBC91A7EA504A591A8386023108C02D7D51508376319FB993A3C0B4F9495E75E2A7BDE312747813D5519E3BA71D6677751E6A015692442F5DC7EA22513556232EB4F380FA9C3F6036E6B3A36F64DF7D9C325E99D20ADC37630E284A68840F4ED6774; path=/; HttpOnly
  1. X-AspNet-Version: 4.0.30319
  2. X-AspNetMvc-Version: 5.2
  3. X-Powered-By: ASP.NET


30
[quote]
CBRon - 1/13/2020
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]

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]
Yes, the element is present. And I do not get the parser error if I remove the cookieSameSite="None" attribute. One other potential issue - this is a legacy app that is using the .Net framework 2.0 (actually 3.5). Could that be an issue? I also had another idea. What if I add the SameSite attribute to the Response cookie using an URL Rewrite outbound rule? Would that work?
[/quote]
I haven't tried it but it's worth taking a look if you like. As long as you see the Secure and SameSite=None in the set-cookie header, that's all that's required.

Just to confirm, you have .NET framework v4.8 installed on the web server?[/quote]
Yes, I have .NET Framework 4.8 installed on the server.
[/quote]
It might be related to the .NET framework v2.0. Our testing has been on the .NET framework v4.0 and above. You might have to contact Microsoft support for confirmation.

The other consideration is that not all SAML flows require the use of SAML state to work.

For example, if you're the SP and supporting IdP-initiated SSO flow, no SAML state is required. Therefore no changes would be required to support the Chrome updates.

Are you acting as the SP or IdP and are you supporting IdP-initiated or SP-initiated SSO? Are you supporting SAML logout?
31
[quote]
ComponentSpace - 1/14/2020
Just to confirm, this is the ASP.NET_SessionId cookie?

Could you include the full set-cookie header?
[/quote]

The set cookie header on our server is returning:
Server: Microsoft-IIS/8.5
Set-Cookie: .ASPXAUTH=130960F2BE1F38E1E090B5E8BBC91A7EA504A591A8386023108C02D7D51508376319FB993A3C0B4F9495E75E2A7BDE312747813D5519E3BA71D6677751E6A015692442F5DC7EA22513556232EB4F380FA9C3F6036E6B3A36F64DF7D9C325E99D20ADC37630E284A68840F4ED6774; path=/; HttpOnly
  1. X-AspNet-Version: 4.0.30319
  2. X-AspNetMvc-Version: 5.2
  3. X-Powered-By: ASP.NET


[/quote]
.ASPXAUTH is the authorization cookie rather than the session cookie. The default name of the ASP.NET session cookie is ASP.NET_SessionId.
32
[quote]
CBRon - 1/13/2020
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]

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]
Yes, the element is present. And I do not get the parser error if I remove the cookieSameSite="None" attribute. One other potential issue - this is a legacy app that is using the .Net framework 2.0 (actually 3.5). Could that be an issue? I also had another idea. What if I add the SameSite attribute to the Response cookie using an URL Rewrite outbound rule? Would that work?
[/quote]
I haven't tried it but it's worth taking a look if you like. As long as you see the Secure and SameSite=None in the set-cookie header, that's all that's required.

Just to confirm, you have .NET framework v4.8 installed on the web server?[/quote]
Yes, I have .NET Framework 4.8 installed on the server.
[/quote]
It might be related to the .NET framework v2.0. Our testing has been on the .NET framework v4.0 and above. You might have to contact Microsoft support for confirmation.

The other consideration is that not all SAML flows require the use of SAML state to work.

For example, if you're the SP and supporting IdP-initiated SSO flow, no SAML state is required. Therefore no changes would be required to support the Chrome updates.

Are you acting as the SP or IdP and are you supporting IdP-initiated or SP-initiated SSO? Are you supporting SAML logout?[/quote]
We are the SP, and we are supporting SP-initiated SSO. We do not support SAML logout.
I am currently experimenting with the URL rewrite outbound rule. If I am successful, I will post the method I used here in case someone else has an environment similar to mine.
33
[quote]
CBRon - 1/13/2020
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]

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]
Yes, the element is present. And I do not get the parser error if I remove the cookieSameSite="None" attribute. One other potential issue - this is a legacy app that is using the .Net framework 2.0 (actually 3.5). Could that be an issue? I also had another idea. What if I add the SameSite attribute to the Response cookie using an URL Rewrite outbound rule? Would that work?
[/quote]
I haven't tried it but it's worth taking a look if you like. As long as you see the Secure and SameSite=None in the set-cookie header, that's all that's required.

Just to confirm, you have .NET framework v4.8 installed on the web server?[/quote]
Yes, I have .NET Framework 4.8 installed on the server.
[/quote]
It might be related to the .NET framework v2.0. Our testing has been on the .NET framework v4.0 and above. You might have to contact Microsoft support for confirmation.

The other consideration is that not all SAML flows require the use of SAML state to work.

For example, if you're the SP and supporting IdP-initiated SSO flow, no SAML state is required. Therefore no changes would be required to support the Chrome updates.

Are you acting as the SP or IdP and are you supporting IdP-initiated or SP-initiated SSO? Are you supporting SAML logout?[/quote]
We are the SP, and we are supporting SP-initiated SSO. We do not support SAML logout.
I am currently experimenting with the URL rewrite outbound rule. If I am successful, I will post the method I used here in case someone else has an environment similar to mine.
[/quote]
You probably can get away without the changes. It will mean one of the minor security checks won't be made. Specifically, we can't check the InResponseTo field of the SAML response without the saved SAML state. However, this isn't a major issue.

Thanks for volunteering to post the rewrite rule. That's very much appreciated.
34
[quote]
ComponentSpace - 1/15/2020

.ASPXAUTH is the authorization cookie rather than the session cookie. The default name of the ASP.NET session cookie is ASP.NET_SessionId.
[/quote]

I haven't been able to find a Response header where the ASP.NET__SessionId is set, however I do see the cookie is in each Request header and the SameSite flag is empty. We do not have a valid SSL cert in the development server, so I was unable to require secure. Will that nullify the sameSite=none setting?

This is what I currently have in the Web.config:


35

There definitely should be a response header with a set-cookie of the ASP.NET_SessionId cookie.

Please try this in browser incognito mode.

You should still see SameSite=None even if the Secure flag isn’t set.

In production, you will want Secure set as well as this is a requirement of Chrome 80 (ie if setting SameSite=None then Secure must be set as well).

36
[quote]
ComponentSpace - 1/14/2020
Just to confirm, this is the ASP.NET_SessionId cookie?

Could you include the full set-cookie header?
  • Set-Cookie: user_activity=1579155584; domain=intraminglesite.com; path=/; secure

    • Our web project target framework is 4.5.1 and were using SAMLv 2.6. SameSite=none is still missing

    Thanks
    37
    [quote]
    ComponentSpace - 1/14/2020
    Just to confirm, this is the ASP.NET_SessionId cookie?

    Could you include the full set-cookie header?
  • Set-Cookie: user_activity=1579155584; domain=intraminglesite.com; path=/; secure

    • Our web project target framework is 4.5.1 and were using SAMLv 2.6. SameSite=none is still missing

    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.
    38
    [quote]
    ComponentSpace - 1/14/2020
    Just to confirm, this is the ASP.NET_SessionId cookie?

    Could you include the full set-cookie header?
  • Set-Cookie: user_activity=1579155584; domain=intraminglesite.com; path=/; secure

    • Our web project target framework is 4.5.1 and were using SAMLv 2.6. SameSite=none is still missing

    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,

    39
    [quote]
    ComponentSpace - 1/14/2020
    Just to confirm, this is the ASP.NET_SessionId cookie?

    Could you include the full set-cookie header?
  • Set-Cookie: user_activity=1579155584; domain=intraminglesite.com; path=/; secure

    • Our web project target framework is 4.5.1 and were using SAMLv 2.6. SameSite=none is still missing

    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,

    [/quote]
    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.


    40

    2012 R2
    IIS 8.5
    Application is .Net 4.5.2
    ComponentSpace dll - 2.8.8.0
    WebServer Installed .Net 4.8 patch
    SP Initiated SSO

    So I followed what I thought where the steps.
    With Chrome 80 Beta and the following link provided by @Mov3

    https://knowyourtoolset.com/2020/01/testing-for-the-new-samesite-cookie-handling-changes/

    I tested my application SSO which works regardless, but I’m trying to close the loop here and be proactive.

    I still see the following. But you can see my cookie is Secure and SameSite=None

    What else might I be missing, where there any post patch 4.8 update steps I needed to follow?


    EDIT Disregard, I forgot to clear my cookies before the last test. It now appears the warning message is gone.
    Leaving post in case it helps anyone.

    Thanks