Bump Keycloak version to 21.0.1

[sberyozkin]

No description provided.

[github-actions]

🙈 The PR is closed and the preview is expired.

[sberyozkin]

Apologies, forgot to check that test, run a few in native

[sberyozkin]

integration-tests/oidc-token-propagation is not a problem, the error message has changed.

But all keycloak-authorization tests just return 403 now. @pedroigor Hi Pedro, has something already changed in keycloak-authorization in 21.0.0, I see your PR for creating another library is still a draft ?

[famod]

FWIW, Keycloak 21.0.1 was released a week ago: https://www.keycloak.org/2023/03/keycloak-2101-released

[sberyozkin]

Hi everyone, yes, I've updated this PR to 21.0.1, Pedro @pedroigor found the cause of keycloak-authorization test problems, it is a tricky one, KC images starting from 21.0.0 are based on Java 17 which no longer ships the JS engine, which keycloak-authorization tests depend upon as they use JS policies. Pedro offered an interesting solution, create a custom image and install the engine there, works perfectly in JVM but not yet in native, this is why I'm keeping the Draft status

[famod]

Hi @sberyozkin, thanks for the details!
IIUC, this means that I could theoretically just bump the KC dependencies in my project (via dependencyManagement) and everything should work just fine?

[famod]

I have just added the backport label because Keycloak 21.0.1 fixes at least one severe sec issue.
Please remove the label if you disagree.

[sberyozkin]

@famod I'm not sure Guillaume would accept that backport, FYI, that CVE you are referring to is a false positive from the Quarkus perspective, I saw it too, the problem is the code executed by Keycloak in its server context has some parts of it in the keycloak-core or other libraries quarkus-keycloak-authorization depends upon but quarkus-keycloak-authorization is a client of Keycloak. quarkus-oidc does not know what Keycloak is at the prod dependency level.
I hope with the work @pedroigor is doing for Keycloak 22.0.0 it will improve a lot as the keycloak authorization will be in another library, but we'll see

[sberyozkin]

Hi @famod

IIUC, this means that I could theoretically just bump the KC dependencies in my project (via dependencyManagement) and everything should work just fine?

Can you clarify please what you mean ? The problem right now is integration-tests/keycloak-authorization specific since it uses JS policies which are no longer supported with the default KC 21.0.1 image in its java 17 base, which is why Pedro is looking at creating the custom image re-enabling JS engine

[pedroigor]

@sberyozkin We need to add a new SPI and implementation to the native image. See pedroigor@6da97f7.

It should fix the native image issue.

[famod]

Hi @sberyozkin, my situation is as follows:
We just upgraded our Keycloak image from 20.0.5 to 21.0.1, not only because but also because of GHSA-9g98-5mj6-f9mv
We have been using third party provided "patched" OpenAPI files to access Keycloak to manage users etc.
I think quarkus-keycloak-admin-client already existed at that time, but back then we didn't know better.
Now we would like to get rid of those third party OpenAPI files (meaning the code we generate from them) and switch to quarkus-keycloak-admin-client because those files haven't been maintained anymore for a long time and things could break anytime.
We cannot jump on Quarkus 3 right aways but need to keep our KC instance up to date to receive latest sec fixes and here is where my backport request comes into play.

What I meant with

IIUC, this means that I could theoretically just bump the KC dependencies in my project (via dependencyManagement) and everything should work just fine?

is that in case this is not backported, I think I should be able to bump the KC deps myself in my project, no?
PS: I'm not using native.

[famod]

Any news on this one?

[sberyozkin]

Sorry everyone, I totally missed the the last update from Pedro, it has to be fixed soon, I'll have a look

[sberyozkin]

@pedroigor Thank you, it fixed it, and sorry again everyone for ignoring this issue for a while

[quarkus-bot]

Failing Jobs - Building f964a49

Status	Name	Step	Failures	Logs	Raw logs
✔️	Gradle Tests - JDK 11
⌛	Gradle Tests - JDK 11 Windows	Build	Failures	Logs	Raw logs
⌛	JVM Tests - JDK 11	Build	⚠️ Check →	Logs	Raw logs
✔️	JVM Tests - JDK 17
✔️	JVM Tests - JDK 19

Full information is available in the Build summary check run.

Failures

⚙️ Gradle Tests - JDK 11 Windows #

📦 integration-tests/gradle

✖ io.quarkus.gradle.devmode.AvroDevModeTest.main line 15 - More details - Source on GitHub

org.awaitility.core.ConditionTimeoutException: Condition with lambda expression in io.quarkus.test.devmode.util.DevModeTestUtils that uses java.util.function.Supplier, java.util.function.Supplierjava.util.concurrent.atomic.AtomicReference, java.util.concurrent.atomic.AtomicReferencejava.lang.String, java.lang.Stringboolean was not fulfilled within 1 minutes.
	at org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:167)
	at org.awaitility.core.CallableCondition.await(CallableCondition.java:78)

[sberyozkin]

This test failure is not related, merging now