Using quarkus with older version of keycloak admin client

[sbergandy]

Hi

how can I set up pom.xml in order to use quarkus 3.5.0 with keycload-admin-client 20.0.3? Many thanks in advance.

Cheers
Sebastian

[maxandersen]

You override the dependencies. But not sure if that old adm client is possible. Question for keycloak what versions they cover.

[michalvavrik]

It's fine @sbergandy as long as you know what you are doing.

I think we tried to prevent users from ignoring unknown fields as we adapt Keycloak Admin Client to specific Keycloak version and if you are using it with different Keycloak version, we can't guarantee it will work (native mode for one). Here @geoand tried to make sure that you can't change quarkus.jackson.fail-on-unknown-properties=false, however unless I'm very wrong, he didn't do it right - it checks for propertyName.startsWith("io.quarkus.jackson") while I think it should be propertyName.startsWith("quarkus.jackson"). I'll create PR that corrects it, maybe I'm simply missing something.

https://github.com/quarkusio/quarkus/blob/main/extensions/keycloak-admin-client-reactive/runtime/src/main/java/io/quarkus/keycloak/admin/client/reactive/runtime/ResteasyReactiveClientProvider.java#L102

[michalvavrik]

Hmm, now that I'm thinking about it, you are using Keycloak Admin Client (not Reactive version), that is why you are experiencing it as it has different default client setup.

[sbergandy]

Yep, I'm not using reactive version. What can go wrong when sending JSON without one field according to expected format?

[michalvavrik]

Yep, I'm not using reactive version. What can go wrong when sending JSON without one field according to expected format?

That's the point, I don't know. Can you really tell if some field is vital without going through Keycloak code first? Just to be clear, I don't suggest your changes are wrong as long as you know what you do :-) No objections to your workaround for your case!

[sbergandy]

Thanks for your time and anserws.

[sberyozkin]

Thanks @michalvavrik for the PR fixing a typo in the reactive version.
IMHO the workaround in this case is ok, it simply fixes a backward compatibility issue, blocking an unrecognised field

[sbergandy]

Thanks. This was exactly my intention i.e. simply fix for backward compatibility. If Keycloak 20.0.3 doesn't expect a field because it will be first added in a newer version then I'm not sending it. Once we upgrade our server the newer version I can just remove the class. I also tested Keycloak via curl by putting the user representation without and with userProfileMetada field.

[sbergandy]

Thank you Guys for your time.

[vmuzikar]

@sbergandy Could you please create an issue in the Keycloak repo around a potential backwards compatibility issue?

[sbergandy]

I think this isn't an issue because they don't guarantee that in case of version mismatch everything will work. See https://www.keycloak.org/docs/latest/upgrading/index.html

What do you think?

[vmuzikar]

We'd still like to investigate and see if there's anything we can do about it. :) This is connected to the cyclic dependency issue we have with Quarkus.

[sbergandy]

Ok I will create an issue, but I think we can't do anything because this is by design so. Keycloak answers with 400 if unknown field was sent in UserRepresentation JSON.

[sbergandy]

done keycloak/keycloak#24393