0

I am currently trying to use testing Pac4j (v4.5.7) along with Payara 5 (Java 8) and Keycloak 16.1.1 after a previous attempt to use the OIDC Connect client available with Payara API.

I simply tried to use a single pac4j client, the OIDC connect.

Unfortunately I obtained a similar error to my previous attempt with Payara OIDC APIs, so I am starting thinking there is something that changed overtime because I think I am not the only user of these technologies...

After the login process the session is available on keycloak, but after the OIDC callback is invokated I receive this error:

org.pac4j.core.exception.TechnicalException: State cannot be determined

Using the OIDC connect Client include in Payara I obtained a similar error:

Expected state not found

This is how the callback url appears:

http://192.168.1.11:8080/svc/login/oidc_callback?client_name=KeycloakOidcClient&state=ee6cb6f634&session_state=3b74a47d-da7a-451c-8c5e-9ae857b37017&code=6202b059-1b62-44c6-ab38-9b63d13ed0b9.3b74a47d-da7a-451c-8c5e-9ae857b37017.4f4dd20b-fd60-4228-b5d2-e6287ce200f4

I initially thought the SameSite cookie settings was a possible issue but I noted that this version of Keycloak is already using "none" as value.

My keycloak runs on HTTPS while Payara is in test running on HTTP.

These are my pac4j libs:

pac4j core 4.5.7
pac4j oidc 4.5.7
jee-pac4j 5.0.0

Is there any issue that prevent the use of the pac4j v.4 with todays browsers ? I would need to stay with Java 8... that's why I am locked on these versions...

I would expect to have a valid session available on the request.

Thank you in advance for any suggestion,

Best Roberto

Roberto Cisternino
  • 1
  • 1

1 Answers1

0

The state is generated before the redirection to Keycloak and saved into the web session. After the login process, the returned state is compared to the one retrieved from the web session.

So you must have a problem with your web session: a new one is created or something like this. Track your JSESSIONID cookie to see if its value changes before and after logging in at Keycloak?

In the old v4 of pac4j, the Same-state policy was not handled so this is also a lead for your problem.

jleleu
  • 2,309
  • 1
  • 13
  • 9
  • So the pac5j v4 which in turn means Java 8 cannot be used with Keycloak todays due to the shift in the same site policy handling on browsers... ouch! – Roberto Cisternino May 22 '23 at 14:16
  • We don't know yet. First, you must investigate to find the issue and then we try to find a fix. – jleleu May 23 '23 at 05:31
  • It looks this problem occurs when there is an additional JSESSIONID. This happens with our website as we have a static app (always on) and a service app that could be offline for maintenance. The 1st app is in the root context while the service app is in a specific context. After login the user has collected two JSESSIONID as per the above explnation and Payara OIDC APIs as well as Pac4j are not able to select the correct session id. In theory the last JSESSIONID should be the correct one, but browsers probably are not ensuring the right order of these info so it would end to be tricky. – Roberto Cisternino May 25 '23 at 11:25
  • Why is there an additional JSESSIONID? Is the original JSESSIONID not posted back by Keycloak? I remember known issues with Keycloak and cookies management because of the hardcoded: `Referrer-Policy: no-referrer policy` header. – jleleu May 26 '23 at 05:28
  • The additional JSESSIONID exists when a website has the static part completely separated from the dynamic part.. two different web app. The OIDC client needs to update the right session ofter Keycloak authentication has been completed. – Roberto Cisternino Aug 25 '23 at 08:12
  • Can it be a problem related to the path of the two JSESSIONID cookies? – jleleu Aug 25 '23 at 15:26