Issue with missing session when redirected back to application

[thomaskaviani-vvvl]

We have a Java EE web-application that used the dssp-client (version 1.7.0).
With the recent updates of the Chromium-driver (used by Microsoft Edge and Chrome) we ran into the following issue:

• when signing a document on the e-contract page, on the redirect we had a "missing session" exception.

In the dssp documentation we saw that in the most recent version of the dssp-client (1.8.0) we had to add a filter to our web.xml.

We still run on Wildfly 11 servers, and your team was friendly enough to make a patch (1.8.1) to get the new version of the dssp-client working on those servers. But after some testing, the "missing session" issue still persists. We tought the cause could be in the configuration of our application or our servers. So we took the dssp-example from github, downloaded a clean Wildfly 11 and Wildfly 18 server and did the same tests on those, and this is the exception we encountered every time:

java.lang.IllegalArgumentException: missing session at deployment.dssp-example-1.0.0-SNAPSHOT.war//be.e_contract.dssp.client.SignResponseVerifier.checkSignResponse(SignResponseVerifier.java:117) at deployment.dssp-example-1.0.0-SNAPSHOT.war//be.e_contract.dssp.example.LandingServlet.doPost(LandingServlet.java:46) at [email protected]//javax.servlet.http.HttpServlet.service(HttpServlet.java:523) at [email protected]//javax.servlet.http.HttpServlet.service(HttpServlet.java:590) at [email protected]//io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:74)

How to reproduce the exception:

1. Startup the server and deploy the dssp-example
2. Open Microsoft Edge or Chrome and go to: http://localhost:8080/dssp-example/
3. Click the "Sign example PDF", perform the sign with a valid EID-card, you get redirect to the dssp-example application
4. You return succesfully on the application and the data from the EID-card is shown (so far so good)
5. Stay in the same tab in the browser and surf to 'http://localhost:8080/dssp-example/' again, perform the process again
6. Repeating this process will eventually result in the exception stated above

We noticed that for Wildfly 11 we could succesfully sign 3 times, the fourth time would result in the exception.
We noticed that for Wildfly 18 we could succesfully sign 4 times, the fifth time would result in the exception.

For Wildfly 11 we used a War that was build with the wss4j21 profile
For Wildfly 18 we used a War that was build with the wss4j2 profile

We used the latest 1.8.1 version of dssp.
The servers we used were downloaded from https://www.wildfly.org/downloads/. Nothing in the server was changed to test this
Nothing in the dssp-example was changed to test this. It was cloned directly from the Github repository

[fcorneli]

As Undertow is more strict on cookie manipulations, you need to set SameSite=None on the JSESSIONID cookie in another way.
See:
https://undertow.io/undertow-docs/undertow-docs-2.1.0/index.html#samesite-cookie-handler

[fcorneli]

Updated the example for WildFly:
e-Contract/dssp-example@3eb144a

[thomaskaviani-vvvl]

Important to know that the example provided is only available for Wildfly 19 and later versions. We'll look for a way to get the samesite cookie working on wildfly 11 and 18

[thomaskaviani-vvvl]

We tested the dssp-example on a wildfly 21 with the samesite filter in the web.xml AND tested it with adding the cookie in another way (using the undertow-handler.conf) file. The problem still persists and can be reproduced with the steps stated above.

[fcorneli]

For the SameSite=None session cookie attribute to get correctly picked up by the Chrome web browser, you need to run your web application over SSL. Updated the example to also demonstrate an SSL setup for WildFly:
e-Contract/dssp-example@7f3b64a

[thomaskaviani-vvvl]

We tried to run the example over SSL (just like the application we are implementing it in) and still face the same issue. Are you able to reproduce the exception?

[fcorneli]

When running the dssp-example with the SSL changes, I can no longer trigger the exception over here.
Try to inspect the dssp-example Set-Cookie HTTP header requests within the Chrome web browser.
Do you clearly see the ; SameSite=None; Secure attributes being set on the JSESSIONID cookie?

[loictielen-vvvl]

Hello, I'm Loïc, a colleague from Thomas. At the end of last year he was assigned to some other urgent projects.

We have gotten the example working on WF19+. There are however still issues for WF18 and lower since the undertow sameSiteCookieHandler is only available from WF19 onwards. Unfortunately we are not allowed to migrate to WF19+, so we are still looking for a solution for WF18 and lower. Can you please look into it?

[loictielen-vvvl]

It seems that in the response the "Set-Cookie" header is never present

[loictielen-vvvl]

It seems I have found a solution. First of all, I would like to note that the class WSSecurityWSS4J21 that is part of your package: be.e_contract.dssp.client.wss4j21 contains references to classes that are internal. To make them accessible I've had to add:

<jboss-deployment-structure> <deployment> <dependencies> <module name="org.apache.ws.security" export="true"/> <module name="org.joda.time" export="true"/> <module name="org.apache.santuario.xmlsec" export="true"/> </dependencies> </deployment> </jboss-deployment-structure>

While it is present in the example you have written, it is not clear from the wiki: https://www.e-contract.be/sites/dssp/dssp-client/

Anyway, as I mentioned, the Set-Cookie header is never present in any of the calls, as such one can only assume the cookie is not added with the wrapper in the SameSiteNoneFilter. The solution is then to adjust the cookie once the session is already touched.
I followed and slightly adjusted the code proposed in this topic on stackoverflow: https://stackoverflow.com/a/52823011/12775089

now everything seems to work (Still testing in different environments)