Dear All,
Just figured out the answer to my question. Share it with you for others who may have similar "issue" in future.
So, basically the problem was that we use Reverseproxy cluster environment, we set settings on master RP and they replicated over to slave but the order was not the same. Once we connected to slave the cockie settings were wrong once we connected to master cookie settings were good.
These were our settings for tests:
[cookie-attributes]
jtest = SameSite=Strict; Secure; HttpOnly
* = SameSite=none; Secure; HttpOnly
If the line starting with " * " was earlier like other in configuration file RP never check next line because of matching " * " to ALL coockies. Similar liek any Regex search.
Regards,
------------------------------
Janos Laszlo Horvath
------------------------------
Original Message:
Sent: Fri March 08, 2024 12:27 AM
From: Janos Laszlo Horvath
Subject: ISVA support for SameParty cookie attribute
Dear All,
I just don't want to open a new topic for this but I do have question for this.
I would like to set "samesite=strict" for a specific application coockie. I tried this "APPSESSIONID = SameSite=strict; Secure; Httponly" , int this stanza, but the APPSESSIONID is still use"SameSite=none".
I was thought we can set any session coockie "name" , "value" entry there.
What do you think it is possible somehow?
Regards,
------------------------------
Janos Laszlo Horvath
Original Message:
Sent: Thu April 29, 2021 07:26 AM
From: André Leruitte
Subject: ISVA support for SameParty cookie attribute
Thank you very much for your precious reply Jon.
I had trouble finding detailed documentation on the inner workings of SameParty, and the fact that this is not a standard (yet?) explains why.
I was not aware that there were additional .well-known requirements.
So in the end, we juste need SameSite support, which is already taken care of :)
For future readers that could run into the same kind of issue, this is what solved both SameSite and Sameparty issues :
[cookie-attributes]PD-S-SESSION-ID = SameSite=None; SecurePD_STATEFUL* = SameSite=None; SecureJSESSIONID = SameSite=None;Secure
------------------------------
André Leruitte
Original Message:
Sent: Thu April 29, 2021 06:31 AM
From: Jon Harry
Subject: ISVA support for SameParty cookie attribute
André,
Thanks for letting us know that you were able to find a way to get Chrome 90 users working. That's good news.
If you want support for SameParty, please open an RFE so it can be considered ( see https://www.ibm.com/support/pages/node/614221 ).
It's worth noting that (based on my quick read around the subject) simply adding SameParty to cookies does not provide a complete solution. Both the "owning domain" and "member" domains have to host a JSON document at a .well-known URL which defines who they consider part of their domain. Again, this is not a standard yet - just something that Google have added to Chrome (perhaps to test adoption?).
It sounds like the real change in Chrome 90 was the requirement to have SameSite=None in cookies which are set by an iFrame. We have this covered.
Thanks again for raising awareness of this and for your analysis.
Jon.
------------------------------
Jon Harry
Consulting IT Security Specialist
IBM
Original Message:
Sent: Thu April 29, 2021 06:02 AM
From: André Leruitte
Subject: ISVA support for SameParty cookie attribute
Our webbanking application authentication is handled by an external governmental IDP. The integration of their UI is done via an iFrame.
Since v90, the cookie JSESSIONID isn't sent anymore by Chrome on the POST redirects from the IDP to ISAM.
So ISAM SAML process fails as it doesn't know how to identify the request.
Fortunately we were able to work around the issue by adding "SameSite=None" to JSESSIONID cookie. By doing that, the cookie is still sent (as before) in these particular iFrame scenarios.
But I think the solution would be much safer if we were able to simply add "SameParty" to the JSESSIONID cookie, instead of SameSite=None.
I hope next ISVA update will add support for this new cookie attribute.
------------------------------
André Leruitte
Original Message:
Sent: Wed April 28, 2021 08:40 AM
From: Jon Harry
Subject: ISVA support for SameParty cookie attribute
Hi André,
WebSEAL does not provide a capability to add arbitrary attributes to cookies. As you discovered, there is a limited list of attributes that are supported (including SameSite, Secure, HttpOnly etc.).
I would be very interested to understand how Chrome 90 is preventing access to your application. I wouldn't expect the SameParty functionality to cause any change in behaviour unless cookies are being set with this attribute. Can you explain what is failing?
Jon.
------------------------------
Jon Harry
Consulting IT Security Specialist
IBM
Original Message:
Sent: Tue April 27, 2021 11:46 AM
From: André Leruitte
Subject: ISVA support for SameParty cookie attribute
Hi everybody,
Chrome recently introduced in their v90 (being massively rolled out since yesterday) support for a cookie attribute called "SameParty".
How can I configure webseal so that the "SameParty" attribute is added to cookies ?
It seems that the stanza [cookie-attributes] does not accept the "SameParty" attribute, and at the moment we have no workaround for restoring access to clients using Chrome 90 to our most important application.
Thanks for any lead that could help us
------------------------------
André Leruitte
------------------------------