Improving SSO keycloak with kerberos

[tdipisa]

Description

When a user connected to SSO via kerberos uses MapStore, the user is not automatically recognized as authenticated.

The final effect is a continuous refresh of the page.

The problem is caused by a cookie present in the browser. The cookie is most probably KEYCLOAK_ADAPTER_STATE, because the times I replicated this issue, removing this cookie solved the problem, and during the debug session I had,I found it in AdapterTokenStore.class line 122 this.tokenStore.isCached(this) causes in fact the issue. tokenStore.isCached reads that cookie. I was not able to identify the precise condition when this cookie creates the problem yet.

The problem is basically caused by the shared value in RequestContextHolder identified by the key KEYCLOAK_REDIRECT, when the cookie above is present and in a cetain, not well identified, condition.

When the problem happens, this value, KEYCLOAK_REDIRECT, is not set. This causes the doLogin method of KeyCloakLoginService to invoke response.sendRedirect(configuration(provider).getInternalRedirectUri()); instead of challenge.commence(request, response, null); when the browser invokes the login service (automatically via SSO check, or manually clicking on login button, when the cookie above is set).
This causes a rediect to (/mapstore) without doing any authentication. In case of sso active, this creates another redirect by the browser of login entry point, causing the loop we noticed.

graph TD;
    mapstore["/mapstore"];
    keycloak["/keycloak/login"];
    mapstore -- Redirect --> keycloak;
    keycloak -- Redirect --> mapstore;

Loading

During the only backend debug session I was able to do during the issue and inspecting the code, I verified that the KEYCLOAK_REDIRECT variable is set only in the KeyCloakFilter at line 143.

The request of Login is filtered by this filter, the request results to be AUTHENTICATED because of the cookie, at line 131 so the execution does not execute the line 143 causing the issue above.

https://github.com/geosolutions-it/geostore/blob/9bf2c3275165c9b01fa929680a6d9d7c941833da/src/modules/rest/impl/src/main/java/it/geosolutions/geostore/services/rest/security/keycloak/KeyCloakFilter.java#L124-L148

So when the login happens, the value is not set

https://github.com/geosolutions-it/geostore/blob/9bf2c3275165c9b01fa929680a6d9d7c941833da/src/modules/rest/impl/src/main/java/it/geosolutions/geostore/services/rest/security/keycloak/KeyCloakLoginService.java#L78

Locally happens randomly. Probably on the environment where this happens this cookie is already set (e.g. by another application, like GeoServer, on the same domain or somehow MapStore sets it in the way that causes the issue).

The solution is most probably to reply to the login request from the client anyway with the with a login success, instead of a simple redirect, if the keycloak state is correct.

note:

• The browser can not read KEYCLOAK_ADAPTER_STATE because it is http-only

How to replicate

I found out how to replicate the issue at least locally. Here a video:

Basically

• use https://github.com/geosolutions-it/docker-mapstore-integrations (with option "direct")
• run using docker compose up
• (if need, configure proper users in keycloak)
• login from mapstore ( http://localhost:8080/mapstore )
• select keycloak from login form
• login with the user available for keycloak.
• when redirected to mapstore, open the developer tools, in the application tab.
• Select cookies / localhost:8080 from the tree on the left
• rename the cookie KEYCLOAK_ADAPTER_STATE into KEYCLOAK_ADAPTER_STATE2 from the table, by right click / Rename
• Remove all the other cookies (except the one renamed as KEYCLOAK_ADAPTER_STATE2)
• Refresh the page
• Perform again login (you will see an issue header too big, let's ignore it at least for the moment )
• remove all the cookies except KEYCLOAK_ADAPTER_STATE2
• rename KEYCLOAK_ADAPTER_STATE2 into KEYCLOAK_ADAPTER_STATE
• refresh the page

Now you will see the application trying to login in loop. This probably causes a similar issue of the one found on the client environment, where this cookie is created somewhere else. I hope that fixing the issue with this procedure will fix the same problem on kerberos.

Here a video about the procedure to replicate the issue.

ISSUE_REPLICATE.mp4

As you can see at the end of the video. when removing the cookie KEYCLOAK_ADAPTER_STATE, the issue get solved.

As I suggested in a previous comment, the issue is caused by check of session login and the consequent redirect to /mapstore if a valid session is found. This happens also when the cookie is found, even if properly stored/used by current session.
A possible workaround that I'll try is to, in case of login call, call anyway the login workflow.

What kind of improvement you want to add? (check one with "x", remove the others)

• Minor changes to existing features
• Code style update (formatting, local variables)
• Refactoring (no functional changes, no api changes)
• Build related changes
• CI related changes
• Other... Please describe:

Other useful information