[Dev Services] Add Keycloak Dev Service

[ThomasVitale]

[bsmahi]

Hi @ThomasVitale

After completing my ongoing tasks, I intend to proceed with this and will use the link below as a reference.

KeyCloak TestContainer

Could you please let me know your thoughts.

Thanks,
Mahi

[ThomasVitale]

@bsmahi thanks for volunteering on this. Unfortunately, this one needs a bit of design work first as there is no ConnectionDetails support for Spring Security in Spring Boot. I'll assign this task to me for now to find a possible design, something that can also be adapted in future cases where support is missing in Spring Boot. I'll share updates here. Thanks again for the interest!

[jimisola]

I'll see if I have the time during the week to provide my solution to the keycloak dev service. Even if it's not used perhaps there is something that can be used. It was tested and worked.

[jimisola]

@ThomasVitale I had a previous solution for keycloak dev services that worked but it was more of a hack.
I've tried a couple of different solutions today and have something that semi-works now (not sure if this is a better solution than my original one though).

I ended up choosing between EnvironmentPostProcessor or ConfigDataLoader. Went with the latter, but I later saw that Arconia uses EnvironmentPostProcessor for Bootstrap etc.

My initial work is available here: https://github.com/jimisola/arconia/tree/feeature/keycloak

The challenges are as I see it:

1. for keycloak Arconia needs to hook in when ConfigurationsProperties have been read but no beans created since we need to set e.g.

• spring.security.oauth2.resourceserver.jwt.issuer-uri
• spring.security.oauth2.client.provider.keycloak.issuer-uri

2. The hook shall load the properties, create an ArconiaKeycloakContainer and then register it as a bean in the ApplicationContext as well as registering the BeanFactoryPostProcessor with io.arconia.dev.services.core.config.DevServicesBeanRegistrations.

Issues:

1. How to read configuration properties in KeycloakConfigDataLoader. Currently, just creating a new default instance of KeycloakDevServicesProperties) so that the rest of the implementation can be verified.

This issue might be relevant: spring-projects/spring-boot#43514

2. How to create and register the container in the ApplicationContext. I could not find a proper way, so now a static volatile is used. Not sure what implications this has when e.g.

• Context cache reuse → container stays up
• Context shutdown → bean and container shall aut-close
• Multiple ApplicationContextRunner tests run

3. BLOCKER: I'm unable to get the KeycloakConfigDataLoader to run with ApplicationContextRunner and KeycloakDevServicesSpringBootTestIT fails early as well.

[jimisola]

Suspecting that I have to go with EnvironmentPostProcessor or back to ApplicationContextInitializer again. Did you have an idea on how to solve it?

[jimisola]

Replaced ConfigDataLoader with a BeanDefinitionRegistryPostProcessor solution. Provided a PR that still has work to be done. If the implementation is correct then some additional property injections as well as testing.

[ThomasVitale]

@jimisola thanks so much for looking into this! It is a challenging feature. I hope the new Dev Services design that will be shipped with 0.22.0 will provide a more flexible foundation for supporting Keycloak (moving from annotation-based to programmatic bean registration).

I'll have a look at your PR asap and shared feedback, thank you!

I have some code already from a PoC I did for supporting OAuth2 Client, but didn't get to a result generic enough to be included in Arconia. The main challenge I experienced is supporting the creation of a test realm and users, so that developers can get an initial zero-config and zero-code experience when trying out Spring Security OAuth2 Client with the Keycloak Dev Service. But it's definitely not straightforward, as it can be a very opinionated task :)

[jimisola]

Yes, the default zero-config and zero-code opinionated default is a challenge.

I did create a zero-config and zero-code at the previous company that I think could be used.
The challenge is also that here are several different authentication mechanism - shall all be setup per default?

In order configure the opinionated defaults I ran keycloak container manually first and did a realm-export (JSON).
After that I used this script to continue the configuration over iterations.

Note:

File system binding is the keycloak dev service is of importance since it allows for users to:

• Add additional import files opt/keycloak/data/import
• Add providers easily /opt/keycloak/providers

Keycloak will pickup import files and providers automatically in those to internal paths.

Also note, that for these file system bind mounts to work on OpenShift (and SELinux in general) to be bind with option ":Z" Which tells the container runtime to relabel the host file(s) with an SELinux context that allows the container to access them.

So, until we have a satisfying generic solution for dev services bind mounts I don't think I can continue on the provided PR.

#!/bin/bash
KEYCLOAK_IMAGE=quay.io/keycloak/keycloak:26.5.0
REALM_EXPORT_FILE=dev/keycloak/realm-export-arconia.json

echo "Keycloak used: $KEYCLOAK_IMAGE"
echo

# the realm-export.json contains a user "admin" that causes a conflict if we try to create the admin user again

mkdir -p $PWD/dev/keycloak
echo "## Starting Keycloak container with realm import from src/main/resources/keycloak/realm-export-arconia.json"
echo "## The exported realm (including users) will be saved to $REALM_EXPORT_FILE when you stop the container (Ctrl+C)"
echo ""

podman run --rm \
  --name keycloak-dev \
  --entrypoint bash \
  -e KC_BOOTSTRAP_ADMIN_USERNAME=admin \
  -e KC_BOOTSTRAP_ADMIN_PASSWORD=admin \
  -e KC_FEATURES=scripts,admin:v2,login:v2 \
  -e REALM_EXPORT_FILE=$REALM_EXPORT_FILE \
  -p 127.0.0.1:8080:8080 \
  -v "$PWD/src/main/resources/keycloak/realms:/opt/keycloak/data/import:Z" \
  -v "$PWD/dev/keycloak:/keycloak-export:Z" \
  -v $PWD/src/main/resources/keycloak/providers:/opt/keycloak/providers:Z \
  $KEYCLOAK_IMAGE \
  -lc '
    set -euo pipefail
    on_exit() {
      echo ""
      echo "## Exporting realm (single file) to $REALM_EXPORT_FILE"
      echo ""
      /opt/keycloak/bin/kc.sh export \
        --file /keycloak-export/realm-export-arconia.json \
        --realm arconia \
        --users same_file || echo "!! Export failed !!"
    }
    trap on_exit EXIT
    /opt/keycloak/bin/kc.sh start-dev --import-realm &
    KC_PID=$!
    trap "kill -TERM $KC_PID 2>/dev/null || true" INT TERM
    wait $KC_PID
  '

# Remove users with username "admin"
# jq '(.users) |= map(select(.username != "admin"))' $REALM_EXPORT_FILE > src/main/resources/keycloak/realm-export-new-formatted.json

# Fix ownership after export to match the user:group of ./
echo "## Fixing ownership of exported realm file to match current directory (requires sudo access)"
OWNER_GROUP=$(stat -c '%U:%G' .)
sudo chown "$OWNER_GROUP" $REALM_EXPORT_FILE
read -p "Do you want to overwrite src/main/resources/keycloak/realm-export-arconia.json with the exported realm file? [y/N] " answer
if [[ "$answer" =~ ^[Yy]$ ]]; then
  cp "$REALM_EXPORT_FILE" src/main/resources/keycloak/realm-export-arconia.json
  echo "Exported realm file has been copied and overwritten."
else
  echo "Exported realm file was not copied."
fi
``

[jimisola]

To summarize, if you are ok with my solution the opinionated defaults depends on:

1. deciding what the defaults should be
2. a generic file system bind mount solution for dev services

I'd be more than happy to continue on this.