ComponentSpace

Forums



SAML Cookie SameSite Mode None


SAML Cookie SameSite Mode None

Author
Message
mov3
mov3
New Member
New Member (15 reputation)New Member (15 reputation)New Member (15 reputation)New Member (15 reputation)New Member (15 reputation)New Member (15 reputation)New Member (15 reputation)New Member (15 reputation)New Member (15 reputation)

Group: Forum Members
Posts: 12, Visits: 60
mov3 - 1/13/2020
mov3 - 1/13/2020
Has anyone been able to get their saml service provider app to fail on google canary with these issues?
We are confused by the post also. We are using .net 4.5.1 framework and your 3.5 version. We have downloaded google canary which is version 81 and turned on the samesite features in flags but are unable to get our saml service provider application to fail with saml sso with your control. We do see the console warnings but contrary to what they say in google canary 81 the SAML_SessionId cookie is still there and we are unable to find a problem thus far.

The code in the SAmlCookieHttpModule.cs states
/// Recent browser versions now default cookies to SameSite=Lax.
  /// To support SAML SSO, the SAML session cookie must be SameSite=None.

What am I missing?

What am I missing of the SAML_SessionId cookie does not exist and yet I get all of the data coming over in my ReceiveSSO like I did before? What's the use of the SAML_SessionId cookie anyways? My service provider app doesn't have the cookie but appears to be working just fine with no changes at all.

I finally found a way to actually turn on the functionality (which does not seem like it will turn on in Chrome 80 or 81) using the steps at https://knowyourtoolset.com/2020/01/testing-for-the-new-samesite-cookie-handling-changes/ with google chrome canary with startup arguments. From my take it looks like Google is threatening to turn this on in 80 but has no plans to actually change the behavior until 81



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
steve.smith - 1/13/2020
Good morning,

Is there some way of checking for sure whether our ComponentSpace SAML based implementation uses cookies? (as I wasn't aware it was).

If I open Chrome, run through a SAML login, and then use the appropriate settings tab to inspect the cookies set for/by our site, I don't see any called "SAML_SessionId".  Does this mean that our implementation is not using cookies, and therefore we're not going to be affected by this change?

I downloaded the current dev preview of Chrome (81.0.4021.2) and also followed the instructions found here - https://www.chromium.org/updates/same-site - to "To test whether your sites may be affected by the SameSite changes", and I can still login to 3rd party sites using SAML SSO.

So I assume in our case, that we don't need to change anything? 

Thanks,

Steve.


The "SAML_SessionId" cookie applies to v3.0.0 or later of the SAML library. In versions 2.5.0 to 2.8.8 of the SAML library the ASP.NET session cookie (eg ASP.NET_SessionId) is used instead.

If you're calling the SAML high-level API (ie the SAMLIdentityProvider and SAMLServiceProvider classes) the applicable cookie should be present and this cookie must have the SameSite=None and Secure attributes.

If instead you're calling the SAML low-level API no cookie is used as SAML session state isn't maintained and consequently the Chrome change has no impact.




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
prgscd01 - 1/13/2020
I want to confirm that no changes should be required for Chrome80.  We are currently using ComponentSpace Version 2.2.0.13.  We are also using the low level api.  This was determined after reviewing the documentation which was sent in this email.  (Please see the highlighted, bolded, underline information below).
I’d also like to understand why no changes are necessary when using an older version of ComponentSpace with the low level api.

FROM YOUR DOCUMENATION
What to do if using SAML Library v2.x....

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 cookieSameSite 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.

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.




That's correct. If using the SAML low-level API, the Chrome changes have no impact. The reason for this is that the SAML low-level API doesn't maintain SAML session state and consequently doesn't use a cookie.

The SAML high-level API was introduced in v2.5.0 of the SAML library. Depending on the version, either a custom SAML_SessionId cookie or the ASP.NET_SessionId cookie is used to maintain SAML session state.

SAML library releases earlier than v2.5.0 support the SAML low-level API only and are not affected by the Chrome changes.

Of course, even if using v2.5.0 or later, if the SAML low-level API is being called instead of the SAML high-level API, no cookie is used and the Crhome changes have no impact.

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
aparcelli - 1/13/2020
I am slightly confused by the post. We are using SAML v 3.x and are on .Net Framework v 4.7.2. I cannot tell if this affects us or not?

Yes it will. I've updated the original post to make this clearer. Regardless of which .NET framework version you target, if you're using the SAML library v3.x the Chrome changes will impact SAML SSO. This assumes you're calling the SAML high-level API (ie the SAMLIdentityProvider and SAMLServiceProvider classes) rather than the less commonly used SAML low-level API.

The SAML library v3.x doesn't include calls into the .NET framework to specify the SameSite mode. The reason for this is that the SAML library supports .NET framework versions earlier than 4.7.2 when the SameSite mode wasn't part of the .NET framework API.

The SAML library v4.0.0 adds this support for setting the SameSite mode.

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
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
<sessionState cookieSameSite="None" />

I already had this line
<httpCookies httpOnlyCookies="true" requireSSL="true"/>

Now I get the error
Parser Error Message: Unrecognized attribute 'cookieSameSite'. Note that attribute names are case-sensitive.
What is wrong?


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 <sessionState> element is in your <system.web> section? If you remove the cookieSameSite="None" do you still get a parser error?

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
mov3 - 1/13/2020
mov3 - 1/13/2020
mov3 - 1/13/2020
Has anyone been able to get their saml service provider app to fail on google canary with these issues?
We are confused by the post also. We are using .net 4.5.1 framework and your 3.5 version. We have downloaded google canary which is version 81 and turned on the samesite features in flags but are unable to get our saml service provider application to fail with saml sso with your control. We do see the console warnings but contrary to what they say in google canary 81 the SAML_SessionId cookie is still there and we are unable to find a problem thus far.

The code in the SAmlCookieHttpModule.cs states
/// Recent browser versions now default cookies to SameSite=Lax.
  /// To support SAML SSO, the SAML session cookie must be SameSite=None.

What am I missing?

What am I missing of the SAML_SessionId cookie does not exist and yet I get all of the data coming over in my ReceiveSSO like I did before? What's the use of the SAML_SessionId cookie anyways? My service provider app doesn't have the cookie but appears to be working just fine with no changes at all.

I finally found a way to actually turn on the functionality (which does not seem like it will turn on in Chrome 80 or 81) using the steps at https://knowyourtoolset.com/2020/01/testing-for-the-new-samesite-cookie-handling-changes/ with google chrome canary with startup arguments. From my take it looks like Google is threatening to turn this on in 80 but has no plans to actually change the behavior until 81



The SAML_SessionId cookie is used in the SAML library v3.0.0 and above to maintain SAML session state. There are some SAML flows where it doesn't matter if SAML state is maintained. For example, IdP-initiated SSO doesn't require SAML state. However, SP-initiated SSO and SLO do. It's safer to set the SameSite=None and Secure cookie attributes for all use cases.

Note that in the SAML library v2.5.0 - v2.8.8 the ASP.NET_SessionId cookie is used instead of a custom SAML_SessionId cookie.

Even if Google don't enable the changes in February they will do at some stage soon so it's better to prepare for them now.

Regards
ComponentSpace Development
steve.smith
steve.smith
New Member
New Member (4 reputation)New Member (4 reputation)New Member (4 reputation)New Member (4 reputation)New Member (4 reputation)New Member (4 reputation)New Member (4 reputation)New Member (4 reputation)New Member (4 reputation)

Group: Forum Members
Posts: 3, Visits: 29
For the kind of scenario where cookies might be used - I assume it would be where the IdP has to push the user past a "local" login page before SAML authentication takes place (and therefore needs somewhere to manage the storage of SAML request data before its ready to be processed)? 

If we're not doing that, then I guess cookies won't be be used?  Also, even if we were - the cookie would still be set providing the page Url domain matches the domain of the Url setting the cookie? (i.e. the login process isn't embedded in an <iframe> or similar)

This change is meant to be about improving security or privacy.  As such. we don't really want to set the SameSite property for the ASP.NET session cookie used by our secure application to "None", as that weakens the security of the cookie? (when compared to the new default of "Lax").  It might help with the SAML login process in certain scenarios, but it reduces the security of the session state for the rest of the application.
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
Those are all fair points. Not all scenarios require SAML session state. For example, IdP-initiated SSO doesn't require any SAML state and therefore the cookie may be lax.

SP-initiated SSO and SLO do require SAML session state and therefore the SameSite mode does come into play.

Of course, the best thing to do is to test that everything works with your particular setup.

Regards
ComponentSpace Development
mov3
mov3
New Member
New Member (15 reputation)New Member (15 reputation)New Member (15 reputation)New Member (15 reputation)New Member (15 reputation)New Member (15 reputation)New Member (15 reputation)New Member (15 reputation)New Member (15 reputation)

Group: Forum Members
Posts: 12, Visits: 60
For asp.net core projects if we update to the latest code and use the high level SSO routines like ReceiveSSO what if Internet Explorer and Safari 12 and lower browsers interact with the site - is your latest asp.net core 4 library released this month conditionally not doing SameSite: None for Internet Explorer and Safari < 13 browsers (ios or mac) since having samesite on those breaks the cookies completely . We don't want to all of a sudden have IE and older than the current Safari browser users not being able to use our service provider application which uses your product for the high level SAML functionality

mov3
mov3
New Member
New Member (15 reputation)New Member (15 reputation)New Member (15 reputation)New Member (15 reputation)New Member (15 reputation)New Member (15 reputation)New Member (15 reputation)New Member (15 reputation)New Member (15 reputation)

Group: Forum Members
Posts: 12, Visits: 60
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/
GO


Similar Topics


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


Password:


Select a Forum....












Forums, Documentation & Knowledge Base - ComponentSpace


Search