we are using the Keycloak plugin as a role service as described in the GeoServer documentation which works well for the most part. Thanks for that!
We have one requirement, though, which isn’t covered yet. When assigning roles to users through groups in Keycloak, they won’t be picked up by GeoServer (and thus authorization will fail for the respective workspaces or layers).
As far as I can see, this is due to the fact that the KeycloakRoleService fetches role mappings through the …/users/<user-id>/role-mappings/clients/<client-id> endpoint while roles assigned through groups will only be available on the …/users/<user-id>/role-mappings/clients/<client-id>/composite endpoint.
What would you think about adding the request for composite roles to the extension? I believe it should still behave correctly in existing use-cases.
Hello,
unfortunately the keycloak plugin won’t be supported anymore since it is using deprecated classes and libraries. You should plan to switch to OIDC instead. GeoServer 3 will benefit from a brand new upgraded plugin.
thank you for following up on our issue so quickly! We have been evaluating a switch to the OIDC plugin these last days. Being up-to-date with Geoserver versions and using sustainable dependencies is important to us, of course.
The OIDC integration with Keycloak is working great and it seems like a promising solution to me. There is one thing from the Keycloak plugin, though, that we would be missing in the future, which is synchronizing all available roles from Keycloak to Geoserver via the Keycloak role service for Geoserver administrators to assign to workspaces and layers efficiently.
Do you see a chance of continuing support for the role service part of the Keycloak plugin or am I missing a different solution for synchronizing roles with Keycloak maybe?
I’ve been looking at the latest release candidate for GeoServer 3 and it looks like a great overhaul!
Can you comment on the plans for Keycloak integration? Does the fact that there is no build for the Keycloak plugin in /geoserver/main/community-latest/ mean that it is definitely out of support for GeoServer 3 or is there a chance there will be continued builds?
Your estimation would help us a lot as we plan our next steps.
Right, the new OIDC module is taking over from keycloak (and several other previous implementations).
The keycloak library that they Keycloak made themselves is being retired, and they recommend applications like GeoServer move to OAuth2.
The great news is we now have automated tests for the new OIDC module - using Keycloak. This means the module has a chance of being released as “pending” (for easy download alongside each release to support wide availability for testing) , and then graduating (when we have enough real-world experience to trust it).
It is one of those “technical details” we will focus on in the 3.0.0 announcement.
If you would like to try that module today, you can do so using nightly build:
thanks a lot for the reply. This sounds great and we’ll test with the new release candidate as soon as possible.
One thing we’ll be missing from the current implementation is the Keycloak role service. Synchronizing Keycloak’s available roles is the one missing puzzle piece to us as it’s not part of the OAuth spec and therefore not part of the OIDC module implementation. We’re thinking about keeping the Keycloak role service alive and porting it to GeoServer 3. If you have any alternatives in mind, I’ll be happy to know.
That would be a really good addition, I was not presonally aware of the regression.
Q: How is the keycloak api allowing access to roles? Is the functionality going to be straight forward to port.. or do you need to access their REST API directly?
the porting will be rather straight forward. There are mainly two Keycloak REST calls involved (requesting realm roles and requesting client roles) and the UI is a handful of configurations (KeycloakRoleServicePanel) like server URL, realm, client and credentials.
I will keep you posted about our decision on whether or not to implement this.