All work
- Chaining filter does not auto-wire filters in orderJSSH-52Resolved issue: JSSH-52Scott Cantor
- Context initializer fails to honor external property search valuesJSSH-51Resolved issue: JSSH-51Scott Cantor
- Handle ID-less components in SpringServiceableComponentJSSH-48Rod Widdowson
- DataSealer roundtrip encryption fails on Red Hat 9 OpenJDK in FIPS modeJSSH-42Resolved issue: JSSH-42Scott Cantor
- Add a @NonnullBeforeTest annotationJSSH-29Resolved issue: JSSH-29Rod Widdowson
- Update to Apache HttpClient 5.xJSSH-16Resolved issue: JSSH-16Brent Putman
Chaining filter does not auto-wire filters in order
Description
Environment
Activity
Scott CantorJuly 25, 2024 at 5:25 PM
You actually cracked the mystery of why some deployers have been seeing authentication too often, any time an SP used POST the non-SameSite session cookie was dropped.
Holger WurbsJuly 25, 2024 at 5:21 PM
Cool. Thanks again for the insanely fast help on this matter.
Scott CantorJuly 25, 2024 at 5:17 PM
If you want the code we’re going to ship, I branched for 9.1.3, it’s the tip of maint-9.1.
I don’t plan on setting up CI jobs for all of them so there won’t be any formal snapshots in Nexus unless that plan changes.
Holger WurbsJuly 25, 2024 at 5:12 PM
I couldn’t wait to test and compiled just the fix into shib-networking-spring 9.1.2 myself and copied it on our test environment. I can already report it fixes the issue with the cookie issue for both saml2 and oidc.
Scott CantorJuly 25, 2024 at 3:47 PMEdited
Yes, that should be all. There are some other minor issues but nothing that should matter, in your case the issue is the session cookie’s not getting handled, this should fix that at least, plus add any other response headers you cared about.
It will actually be 9.2.0-SNAPSHOT for the moment unless I get time to branch and backport it so a 9.1.3-SNAPSHOT appears. It shouldn’t matter which.
We have the following configuration:
idp.frameoptions = SAMEORIGIN
idp.csp = frame-ancestors 'self'; base-uri 'none';
idp.cookie.sameSite = None
idp.cookie.sameSiteCondition = shibboleth.SameSiteCondition
with a shibboleth.SameSiteCondition bean deciding based on User Agent to disable SameSite for some old browsers. But I can also reproduce the bug setting this to shibboleth.Conditions.TRUE.
Furthermore, we are running a SAML-Proxy configuration which I think might be another why this happens but the bug should also affect other configurations at least for the csp-Part.
I noticed that in some scenarios the __Host-shib_idp_session cookie is set without SameSite=None and it happens when there is no other dialog vm involved (due to the SAML-proxy configuration). We have Consent/Attribute-Release postAuthenticationFlows in place and when that dialog appears, the cookie is set correctly but when consent has already been given before and the dialog is not shown, the cookie is set without SameSite=None.
I tried to pinpoint the problem further with Fiddler and noticed that when the cookie is set at the flow involing the SAML2 Postback template (https://git.shibboleth.net/view/?p=java-opensaml.git;a=blob;f=opensaml-saml-impl/src/main/resources/templates/saml2-post-binding.vm;hb=23ff3b3c6c99f73dfccddf2020f5a1a211f72af8) it is indeed set without SameSite=None despite our configuration. I also noticed that only the Content-Security-Policy containing the script-src-attr unsafe-hashes (if idp.encoders.cspEnabled = true, otherwise none at all) and not the CSP definied in idp.csp is being sent in this step. Without digging deeper in the code, I believe that the filters defined here https://git.shibboleth.net/view/?p=java-identity-provider.git;a=blob;f=idp-conf-impl/src/main/resources/net/shibboleth/idp/conf/filters.xml;hb=b235ec46fa0cab8a957700cf57be700fc0fccd3d are not applied for those flows and hence neither the samesite cookie filter nor the response header filter is working.
I believe this is not intended for both CSP and SameSite but the SameSite issue which causes problems on our side is only happening in proxy-configurations because in other scenarios the session cookie has probably been set before. I also think that SAML2-POST Encoder is not the only one affected. I havent checked SAML2 SimpleSign or OIDC for this matter.