search

quarkusio / quarkus

Quarkus: Supersonic Subatomic Java.
https://quarkus.io
Apache License 2.0
13.54k stars 2.61k forks source link

Add `keycloak-authorization` and `keycloak-admin-client` tests against legacy Keycloak version #35474

Open sberyozkin opened 1 year ago

sberyozkin commented 1 year ago

Description

CC @pedroigor @stianst @gsmet @rsvoboda

quarkus-keycloak-authorization and quarkus-keycloak-admin-client ( as well as quarkus-keycloak-admin-client-reactive) are the only extensions which depend on Keycloak libraries and Keycloak specific protocols.

Currently, quarkus-keycloak-authorization and quarkus-keycloak-admin-client-reactive are both tested in integration-tests/keycloak-authorization against the latest Keycloak version (22.0.1 at the moment).

We've talked with Pedro, Pedro has a good idea of also testing quarkus-keycloak-authorization and quarkus-keycloak-admin-client-reactive against the legacy Keycloak version to detect the compatibility issues, for example, when RHBQ which is built against the latest KC 22.0.1 is run against RH-SSO built with Keycloak 18.0.0.

The current Keycloak versions are here: https://github.com/quarkusio/quarkus/blob/main/build-parent/pom.xml#L104

One option is to add integration-tests/keycloak-authorization-legacy and run only JVM tests, skipping native builds, for a quick verification of the compatibility, with quarkus-keycloak-authorization and quarkus-keycloak-admin-client-reactive built against Keycloak 22.0.1, and Keycloak test server being 19.0.3 based (we can bring the legacy version to 18.0.x as well, to get to closer to the version the legacy RH SSO may depend upon).

The other option is to run such tests in QE builds (where for example a current keycloak_authorization test which depends on KC 22.0.1 is run against the KC 18.0.0 server).

@gsmet Are you OK if I add integration-tests/keycloak-authorization-legacy which duplicate tests in integration-tests/keycloak-authorization but run them against the old Keycloak server like 18.0.0 ? Asking because I know there is some concern about the CI build time - it would only be JVM tests though which should be fine.

If we should have them in QE then we'll need Rostislav to approve @rsvoboda

Implementation ideas

No response

quarkus-bot[bot] commented 1 year ago

/cc @pedroigor (keycloak)

rsvoboda commented 1 year ago

OIDC extensions also use keycloak bits

What about these modules from integration-tests?

sberyozkin commented 1 year ago

@rsvoboda quarkus-keycloak-authorization/quarkus-keycloak-admin are the only extensions which are Keycloak specific, depend on Keycloak libraries, use a Keycloak specific protocol to communicate with Keycloak. All of OIDC extensions are Keycloak neutral and only use standard OIDC flows.

The possibility of quarkus-keycloak-authorization/quarkus-keycloak-admin backward compatibility issues is higher, we've had a few such quarkus-keycloak-authorization issues in the past