[FIXES #2971] MapStore - SSO keycloak kerberos

[afabiani]

ref.: https://github.com/geosolutions-it/support/issues/2971

[offtherailz]

From my testing I have this error.

Here is what I did.

• Compiled this geostore branch with mvn -B clean install -Pextjs,postgres
• Compiled mapstore master with npm fe:build (once only) then mvn clean install
• Installed mapstore.war in keycloak setup for docker.

mvn version:

mvn --version
Apache Maven 3.6.3 (cecedd343002696d0abb50b32b541b8a6ba2883f)
Maven home: /usr/local/maven
Java version: 11.0.23, vendor: Ubuntu, runtime: /usr/lib/jvm/java-11-openjdk-amd64
Default locale: it_IT, platform encoding: UTF-8
OS name: "linux", version: "6.5.0-35-generic", arch: "amd64", family: "unix"

When I try to login I have this issue.

screencast-localhost_8080-2024.06.19-10_44_22.webm

with docker compose log -f I have this log:

mapstore     | --------------------------------------
mapstore     | 18-Jun-2024 13:10:58.743 INFO [http-nio-8080-exec-2] org.apache.cxf.interceptor.LoggingOutInterceptor.null Outbound Message
mapstore     | ---------------------------
mapstore     | ID: 52
mapstore     | Response-Code: 302
mapstore     | Content-Type: text/html
mapstore     | Headers: {Location=[http://localhost:8080/mapstore/], Set-Cookie=[tokens_key=f3534cb7-7ae2-473d-b445-e8557515859e;Version=1;Comment=;Path=/;Max-Age=120;Expires=Tue, 18-Jun-2024 13:12:58 GMT;SameSite=lax, authProvider=keycloak;Version=1;Comment=;Path=/;Max-Age=120;Expires=Tue, 18-Jun-2024 13:12:58 GMT;SameSite=lax], Cache-Control=[no-cache], Expires=[-1], Date=[Tue, 18 Jun 2024 13:10:58 GMT], Content-Length=[0]}
mapstore     | --------------------------------------
mapstore     | 18-Jun-2024 13:10:58.744 SEVERE [http-nio-8080-exec-2] org.apache.coyote.http11.Http11Processor.service Error processing request
mapstore     |  org.apache.coyote.http11.HeadersTooLargeException: An attempt was made to write more data to the response headers than there was room available in the buffer. Increase maxHttpHeaderSize on the connector or write less data into the response headers.
mapstore     |          at org.apache.coyote.http11.Http11OutputBuffer.checkLengthBeforeWrite(Http11OutputBuffer.java:473)
mapstore     |          at org.apache.coyote.http11.Http11OutputBuffer.write(Http11OutputBuffer.java:426)
mapstore     |          at org.apache.coyote.http11.Http11OutputBuffer.write(Http11OutputBuffer.java:412)
mapstore     |          at org.apache.coyote.http11.Http11OutputBuffer.sendHeader(Http11OutputBuffer.java:370)
mapstore     |          at org.apache.coyote.http11.Http11Processor.prepareResponse(Http11Processor.java:1065)
mapstore     |          at org.apache.coyote.AbstractProcessor.action(AbstractProcessor.java:379)
mapstore     |          at org.apache.coyote.Response.action(Response.java:211)
mapstore     |          at org.apache.coyote.Response.sendHeaders(Response.java:440)
mapstore     |          at org.apache.catalina.connector.OutputBuffer.doFlush(OutputBuffer.java:292)
mapstore     |          at org.apache.catalina.connector.OutputBuffer.close(OutputBuffer.java:252)
mapstore     |          at org.apache.catalina.connector.Response.finishResponse(Response.java:443)
mapstore     |          at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:391)
mapstore     |          at org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:399)
mapstore     |          at org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:65)
mapstore     |          at org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:890)
mapstore     |          at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1789)
mapstore     |          at org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)
mapstore     |          at org.apache.tomcat.util.threads.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1191)
mapstore     |          at org.apache.tomcat.util.threads.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:659)
mapstore     |          at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
mapstore     |          at java.base/java.lang.Thread.run(Thread.java:829)

I don't know why you don't have this error in this case.

Anyway, because the issue involves only the login endpoint, I'd suggest to try another solution:

Here the doLogin in openid version:

https://github.com/geosolutions-it/geostore/blob/master/src/modules/rest/impl/src/main/java/it/geosolutions/geostore/services/rest/security/oauth2/Oauth2LoginService.java#L25

Here the doLogin in keycloak:

geostore/src/modules/rest/impl/src/main/java/it/geosolutions/geostore/services/rest/security/keycloak/KeyCloakLoginService.java

Line 61 in 16bbce6

public void doLogin(HttpServletRequest request, HttpServletResponse response, String provider) {

As you can see the keycloak version has a flag, KEYCLOAK_REDIRECT.

it is used only in that place:

https://github.com/search?q=repo%3Ageosolutions-it%2Fgeostore%20KEYCLOAK_REDIRECT&type=code

and set only here:

geostore/src/modules/rest/impl/src/main/java/it/geosolutions/geostore/services/rest/security/keycloak/KeyCloakFilter.java

Line 148 in 16bbce6

.setAttribute(KEYCLOAK_REDIRECT, entryPoint, 0);

if result.equals(AuthOutcome.AUTHENTICATED) the KEYCLOAK_REDIRECT is not set, and so the login switch to a normal internal redirect.

This looks to me the key point of the problem. I think the problem behind is that kerberos uses the same cookie of the internal library causing the problem. In the filter the user results authenticated, but in fact it is not, because the client is not aware of the cookie (that is done by callback + token endpoints calls, see this chart)

So we have anyway to complete the login workflow.
I'd suggest to try the following approches:

1. In the redirect done by the login to the home page, do set-cookie of auth-provider and identifier, as the callback does, to try to trigger the workflow of token request for the user (assuming that the user is effectively logged in in mapstore, but I'm not sure that is done, in fact it looks to me that you have only a cookie that fakes this).
   

2. To start the commence (so the normal login workflow) on any login invocation, in any case, and see if it fixes the problem. In fact MapStore calls it only when:

   • the user clicks on the login icon for keycloak
   • the monitor for SSO triggers the login because it founds an existing session.

[afabiani]

@offtherailz so far I have been trying your suggestion but what happens is that whenever the ADAPTER_STATE is set to be authenticated already, you won't be able to login anymore untill you get rid of this cookie.

I still remain convinced that the cleanset and correct solution is to correctly set the keycloack session cookies and clean up any old/unwanted ADAPTER_STATE from previous sessions.

I have done few improvements to the PR anyway to avoid infinite redirections.

Please give it a try. If you have a 400 error just increase the Tomcat > maxHttpHeadersSize as I have done here.

[tdipisa]

@offtherailz waiting for your review here

[offtherailz]

as achieved with @tdipisa if possible let's split the part for the scopes from the issue with keycloak SSO + kerberos.

[afabiani]

@offtherailz done, oidc scopes PR here; commit reverted on this one

[offtherailz]

The solution looks to be working in the conditions you provided.
I don't know if there is other way to avoid to set the cookie and risk the header size issue.
Anyway the solution is working, in our test environment. We have to advice the client, in case of issues, about this https://github.com/geosolutions-it/docker-mapstore-integrations/commit/0f187d6899cd5bad320d8ccffb70aed722b19b8f

I think we should try this solution on the client server first, to avoid to reach the end and see that it doesn't apply. In fact we had to do an hard workaround to replicate the issue, so to be 100% that this fixes the clients problem a test have to be done @tdipisa

[tdipisa]

@afabiani thank you for this improvement. We need to also backport this to 2.0.x for testing on the involved project. Let me know if you see any kind of issues for this, it doesn't seems to me.

[afabiani]

@tdipisa nope, no issues, it's safe.