Mapstore and Keycloak v 26.x

[Kenneth Lindhardt]

I need to take this up again. Is there a guide on how to install Maptstore with Keycloak V. 26?
I've attached a research document about this. The main issue is, as far as I understand, that keycloak don't use keycloak.js anymore.

I'v added Keycloak 26 to every part of my setup, including no issues with Geoserver.
I've used days trying to figure this out, until i decided not to use Mapstore in my new company. Took a month break and started again, thought with the 2025, I could make it work. Now after a whole lot of hours, trying to get in from every angle I can figure out, I get stuck with new issues.
Ass far as I recall, I need to use the Keyclaok icon in the login box? I haven't really looked into that yet. My prefered way to go would be SSO where my keycloak starting screen opens up, and after login I get redirected back to mapstore logged in.

Please, is there a bullet proof guide for a brand new installation with integration with keycloak 26.x.
The more I can't figure it out, the more I need it :-D
Thanks - Cheers

[Kenneth Lindhardt]

An update on this, I tried to split everything apart, reinstall, unpack the war file fully. 
I'm just concentrating about the OpenID connect, when I get that to work I can go to the next part afterwards.

Mapstore opens, I get the keycloak icon, but it will lead me to  Outbound Message ... Response-Code: 204, I canøt seem to go from Mapstore to my Keycloak login page. Working with ArcGIS for the last 15 years, I'm still learning as I go, but I also believe that this is the future although I have jumpy start, so I hope that someone can get me over this hurdle, since the keycloak integration is mandatory for my setup.

Attaching the log file 

[Lorenzo Natali]

Hi,

Thank you for your detailed message.

The current Keycloak integration in MapStore was originally designed to provide a full-featured setup, including:

• Automatic login (e.g. via Kerberos or existing sessions)
• Full access to group information via direct client setup

The official guide and implementation were written and tested about a year ago. If, as you mentioned, recent Keycloak versions (v26+) have dropped keycloak.js, that integration is likely outdated and will require updates to remain compatible, or a review that mentions at least from which version it will not work anymore.

I'll open an issue to keep track of your notification, thank you for pointing it out. If you’re a developer and would like to contribute to adapting the integration or the documentation, your help is very welcome.

In the meantime, MapStore 2025.01.00 introduced support for a generic OIDC authentication provider, which might be a better fit for your use case — especially if you don’t need the advanced features listed above.

We documented it here. — while the example is for Azure AD, it should work with any standard-compliant OIDC provider, including Keycloak.

To our knowledge, others have already used it successfully with Keycloak.

I recommend trying this new OIDC integration path and letting us know how it goes.

Thanks again for your feedback and for using MapStore!

--
You received this message because you are subscribed to the Google Groups "mapstore-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mapstore-user...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/mapstore-users/ed3a61f7-6525-4472-aad7-4b3d870814b4n%40googlegroups.com.

[Kenneth Lindhardt]

Hi Lorenzo,

Thank you for your previous email and for recommending the generic OIDC provider path, and sorry for the late reply, but I've been testing ever since :-)

Following your advice, we have spent considerable time attempting to integrate MapStore 2025.01.00 with a modern Keycloak instance (v26+) using this method. Our setup runs on a standard Ubuntu 24.04 LTS server with Apache and a valid Let's Encrypt certificate for our Keycloak domain.

Unfortunately, we have encountered a persistent startup failure that we have been unable to solve through standard configuration methods. Based on our extensive troubleshooting, we suspect there may be an underlying issue with how the OIDC client within the Docker image handles SSL trust.

Summary of the Issue and Troubleshooting Steps

The core problem is that the MapStore application fails to start when the generic OIDC provider is enabled. The root cause is always the same:

javax.net.ssl.SSLHandshakeException: PKIX path building failed: unable to find valid certification path to requested target

This error occurs when the oidcOpenIdFilter bean tries to contact our Keycloak's .well-known/openid-configuration discovery URL during application startup.

We have systematically tried to resolve this certificate trust issue with the following standard methods:

1. OS-Level Trust in Docker: We confirmed with curl from inside the container that the base OS does not trust the Let's Encrypt certificate. To fix this, we created a custom Dockerfile that installs the ca-certificates package and runs update-ca-certificates after adding our server's certificate. This is the canonical method for establishing OS-level trust.

   • Result: The PKIX error persisted, suggesting the Java process does not inherit the OS-level trust store.

2. Forcing a Custom Java Trust Store: We then enhanced the Dockerfile to create a new JKS trust store containing our certificate. We used CATALINA_OPTS in docker-compose.yml to pass the -Djavax.net.ssl.trustStore and -Djavax.net.ssl.trustStorePassword properties to the Tomcat/Java process. This is the standard method for forcing a Java application to use a specific trust store.

   • Result: The PKIX error still persisted.

3. Correcting Application Initializers: We also resolved a series of secondary startup errors related to the geostoreInitializer bean (e.g., sample_users.xml not found) to ensure they weren't masking the primary issue.

Our Hypothesis

Based on these results, we believe the oidcOpenIdFilter component (or the RestTemplate it uses internally) does not respect the system's or the JVM's SSL trust store configuration when provided via a custom Dockerfile or standard environment variables like CATALINA_OPTS. It appears to be falling back to an un-modifiable, default trust store within the JVM, which lacks the necessary root CA for our Let's Encrypt certificate.

We are very keen to get MapStore working in our environment, and using a modern Keycloak is a firm requirement for us. We have also briefly attempted an unpacked WAR file deployment with similar difficulties, but have focused our efforts on the recommended Docker path.

Could you provide any insight or a recommended configuration path that is confirmed to work for this scenario? Is there another property or method we have overlooked to make the generic OIDC client trust a standard SSL certificate?

Any guidance you could provide would be greatly appreciated.

Thank you for your time and help.

Best regards,

As mentioned I'm very new in all of this, and I want to understand and learn. It will be great :-)

Kenneth

[Kenneth Lindhardt]

Hi Lorenzo,

Thank you for your previous email and for recommending the generic OIDC provider path, and sorry for late reply I had a lot of testing to do :-)

Following your advice, we have spent considerable time attempting to integrate MapStore 2025.01.00 with a modern Keycloak instance (v26+) using this method. Our setup runs on a standard Ubuntu 24.04 LTS server with Apache and a valid Let's Encrypt certificate for our Keycloak domain.

Unfortunately, we have encountered a persistent startup failure that we have been unable to solve through standard configuration methods. Based on our extensive troubleshooting, we suspect there may be an underlying issue with how the OIDC client within the Docker image handles SSL trust.

Summary of the Issue and Troubleshooting Steps

The core problem is that the MapStore application fails to start when the generic OIDC provider is enabled. The root cause is always the same:

javax.net.ssl.SSLHandshakeException: PKIX path building failed: unable to find valid certification path to requested target

This error occurs when the oidcOpenIdFilter bean tries to contact our Keycloak's .well-known/openid-configuration discovery URL during application startup.

We have systematically tried to resolve this certificate trust issue with the following standard methods:

1. OS-Level Trust in Docker: We confirmed with curl from inside the container that the base OS does not trust the Let's Encrypt certificate. To fix this, we created a custom Dockerfile that installs the ca-certificates package and runs update-ca-certificates after adding our server's certificate. 

1. • Result: The PKIX error persisted, suggesting the Java process does not inherit the OS-level trust store.

2. Forcing a Custom Java Trust Store: We then enhanced the Dockerfile to create a new JKS trust store containing our certificate. We used CATALINA_OPTS in docker-compose.yml to pass the -Djavax.net.ssl.trustStore and -Djavax.net.ssl.trustStorePassword properties to the Tomcat/Java process. This should be the standard method for forcing a Java application to use a specific trust store.

1. • Result: The PKIX error still persisted.

1. Correcting Application Initializers: We also resolved a series of secondary startup errors related to the geostoreInitializer bean (e.g., sample_users.xml not found) to ensure they weren't masking the primary issue.

Our Hypothesis

Based on these results, we believe the oidcOpenIdFilter component (or the RestTemplate it uses internally) does not respect the system's or the JVM's SSL trust store configuration when provided via a custom Dockerfile or standard environment variables like CATALINA_OPTS. It appears to be falling back to an un-modifiable, default trust store within the JVM, which lacks the necessary root CA for our Let's Encrypt certificate.

We are very keen to get MapStore working in our environment, and using a modern Keycloak is a firm requirement for us. We have also briefly attempted an unpacked WAR file deployment with similar difficulties, but have focused our efforts on the recommended Docker path.

Could you provide any insight or a recommended configuration path that is confirmed to work for this scenario? Is there another property or method we have overlooked to make the generic OIDC client trust a standard SSL certificate?

Any guidance you could provide would be greatly appreciated.

As I mentioned, I'm very new to some of these things, it could be something that leads me to messing things up on my own, but I'm up to at least 10 reinstallations in different variations.
It breaks every time I try Keycloak.
It was Mapstore and Geoserver that  changed my scope to use Keycloak, which is now integrated to User signup, assigning roles, my own Portal and Geoserver + some other stuff, the only thing where I'm stuck is in Mapstore.

Thank you for your time and help.

Best regards,

Kenneth

mandag den 30. juni 2025 kl. 18.08.39 UTC+2 skrev Lorenzo Natali: