daniel-frak / keycloak-user-migration

A Keycloak plugin for migrating users from legacy systems

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Keycloak 17 (jboss): java.lang.NoClassDefFoundError: org/apache/commons/codec/binary/Base64

pschichtel opened this issue · comments

I built the plugin locally with mvn clean package and deployed the resulting jar to my keycloak (17.0.1 jboss distribution).

Using it results in:

14:46:37,268 ERROR [org.keycloak.services.error.KeycloakErrorHandler] (default task-4) Uncaught server error: java.lang.NoClassDefFoundError: org/apache/commons/codec/binary/Base64
	at deployment.keycloak-rest-provider.jar//com.danielfrak.code.keycloak.providers.rest.rest.http.HttpClient.enableBasicAuth(HttpClient.java:41)
	at deployment.keycloak-rest-provider.jar//com.danielfrak.code.keycloak.providers.rest.rest.RestUserService.configureBasicAuth(RestUserService.java:38)
	at deployment.keycloak-rest-provider.jar//com.danielfrak.code.keycloak.providers.rest.rest.RestUserService.<init>(RestUserService.java:28)
	at deployment.keycloak-rest-provider.jar//com.danielfrak.code.keycloak.providers.rest.LegacyProviderFactory.create(LegacyProviderFactory.java:29)
	at deployment.keycloak-rest-provider.jar//com.danielfrak.code.keycloak.providers.rest.LegacyProviderFactory.create(LegacyProviderFactory.java:18)
	at org.keycloak.keycloak-services@17.0.1//org.keycloak.storage.AbstractStorageManager.getStorageProviderInstance(AbstractStorageManager.java:229)
	at org.keycloak.keycloak-services@17.0.1//org.keycloak.storage.AbstractStorageManager.lambda$getEnabledStorageProviders$0(AbstractStorageManager.java:98)

Inspecting the jar shows that these classes are not bundled and apparently are not provided by keycloak. (maybe missing a module.xml ?).

I temporarily added the maven-shade-plugin to bundle the missing (non-provided) dependencies with the plugin:

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-shade-plugin</artifactId>
    <version>3.2.4</version>
    <configuration>
        <shadedArtifactAttached>false</shadedArtifactAttached>
        <createDependencyReducedPom>false</createDependencyReducedPom>
        <filters>
            <filter>
                <artifact>org.apache.httpcomponents:*</artifact>
                <excludes>
                    <exclude>META-INF/**</exclude>
                </excludes>
            </filter>
            <filter>
                <artifact>commons-*:*</artifact>
                <excludes>
                    <exclude>META-INF/**</exclude>
                </excludes>
            </filter>
        </filters>
    </configuration>
    <executions>
        <execution>
            <phase>package</phase>
            <goals>
                <goal>shade</goal>
            </goals>
        </execution>
    </executions>
</plugin>

Which version of the plugin are you using? The last version supporting Keycloak 17 is:
https://github.com/daniel-frak/keycloak-user-migration/tree/ca82b795c793094f6d67dac3dc14dcdfd2d0ed59

Any version after that has been made for newer versions of Keycloak and as such might not work properly with older ones (see the README.md file for compatibility history). Could this be the source of the problem?

sorry, forgot to mention that. I did build the plugin from the commit mentioned in the readme. So that can't be it.

I think jboss expects a module.xml in the deployment which tells it which dependencies you want for the classloader setup. I guess you are testing mostly against the quarkus distribution, right?

My shade-workaround avoids the need for the module.xml by just bundling the dependencies.

Ah, I understand now.
However, AFAIK the Jboss distribution is no longer maintained as of June 2022, right? Even looking at the Jboss Docker hub the last release is for Keycloak 17.

Therefore, there isn't really anything that can be done in the keycloak-user-migration repository, as the currently supported version is Keycloak 20, which is solely powered by Quarkus (save for some deprecated adapters).

This leads me to believe this issue should be closed, although it will surely serve as a good guide for anyone trying to get the plugin running on older Jboss distros.

@pschichtel Do you have anything against closing the issue? Is there anything you believe should be done in the repository before that happens?

Docker images are on quay.io only I think. 17, 18 and 19 were released with both the quarkus and the jboss/wildfly distribution. I'm on my way towards version 20 on quarkus (this version is only a few weeks old and the first not to include the legacy distro).

I mean I can keep patching the version I install in my keycloak while migrating towards 20, but I guess you should at least add a note to the README, that since version 17 only quarkus is supported.

That's a great idea! I've added a note about compatibility with JBoss distributions to the README.md, linking to this issue as a workaround.

Do you think this will be informative enough?

seems fine to me, yes

while upgrading I noticed the version for keycloak 19.x doesn't work on legacy (didn't find some class, forgot which one). I avoided the issue by going from 18-legacy straight to 20, so just an fyi.