Support Keycloak Dev Service when OIDC client is used without OIDC extension

[michalvavrik]

• Closes: Make Keycloak dev service independent of OIDC extension #43086
• OIDC Client will be started and preconfigured without the OIDC extension being present
• removing OidcDevServicesBuildItem; the class wasn't final, therefore could never be used as SimpleBuildItem must be final

  quarkus/core/builder/src/main/java/io/quarkus/builder/item/BuildItem.java

  Line 22 in 4cab5df

  throw new IllegalArgumentException("Build item class must be leaf (final) types: " + getClass());

  ; extensions can set quarkus.keycloak.devservices.enabled with SR Config during the build time
• grant was deprecated on Dev Svc config from 2021 and since I am moving this config, I am also dropping this property
• OIDC Client tab is only added and contains Keycloak Admin URL:
  

[michalvavrik]

cc @sberyozkin but let's see how CI goes, I run couple of extension unit tests locally, but not every integration test

[github-actions]

🙈 The PR is closed and the preview is expired.

[michalvavrik]

OidcClientTooManyJwtCredentialKeyPropsTestCase became flaky and I cannot say if it is consequence of this PR, but I'll have a look into it. The integration-tests/oidc-client-wiremock I didn't run yesterday so I'll look into them.

[michalvavrik]

So OidcClientTooManyJwtCredentialKeyPropsTestCase was about missing quarkus.oidc.auth-server-url being thrown sooner than other expected validation exception. And integration-tests/oidc-client-wiremock should not start Dev Service because it is a wiremock. I'll push fixes. Run it 5 times in row and cannot reproduce it anymore, we will see if there is any other race.

[michalvavrik]

I'll wait for #43601 merge before I push fixes because this needs to adapt changes there anyway (I am moving file that is edited there).

[sberyozkin]

Thanks very much @michalvavrik,
I think having an OIDC client dedicate card is worth it, even if OIDC card is present, it is just another link to the Keycloak provider for now which is not really conflicting and then users will start asking for some more OIDC client specific things to add there, so we will be evolving it....

What happens when both quarkus-oidc and quarkus-oidc-client are loaded ?

[michalvavrik]

What happens when both quarkus-oidc and quarkus-oidc-client are loaded ?

DEV UI wise - card is not produced in the OIDC Client, so you have OIDC card that also contains that link
DEV Svc wise - sadly it is almost everywhere in our tests (only module that I know of that contains OIDC client and not OIDC is the OIDC CLient wiremock) so you can see it -> nothing bad, dev svc is started just right as previously it did

[sberyozkin]

@michalvavrik

DEV UI wise - card is not produced in the OIDC Client, so you have OIDC card that also contains that link

But we don't have to start hiding it, I think it is shown now on main anyway when OIDC is loaded, with the text only, so this PR only has a KC link added to it.

dev svc is started just right as previously it did

Sure, I got confused for a moment if it would start twice, but no, it will be a single instance only

[michalvavrik]

But we don't have to start hiding it, I think it is shown now on main anyway when OIDC is loaded, with the text only, so this PR only has a KC link added to it.

I am not sure we understand each other, let me try again:

• OIDC CLlient has own DEV UI card with KC Link
• OIDC has own DEV UI card with KC link and link to the OIDC DEV UI component

I hide OIDC CLient card when OIDC Is present. If you are saying "let's show it" I think it's alright and I'll do it (please confirm!). I somehow misunderstood your email that said I guess though when no quarkus-oidc is involved, there should be maybe Keycloak card only offering a Keycloak admin link ? It can be done independently though. I suppose I overthink it.

[sberyozkin]

@michalvavrik It looks quite perfect, minor suggestions are there only, I'll run your PR a bit later as well and then we can merge. Later, I'll follow the same pattern for OIDC dynamic client registration as well and eventually we can cover keycloak-admin-clients

[quarkus-bot]

Status for workflow Quarkus Documentation CI

This is the status report for running Quarkus Documentation CI on commit a8f21be.

✅ The latest workflow run for the pull request has completed successfully.

It should be safe to merge provided you have a look at the other checks in the summary.

Warning

There are other workflow runs running, you probably need to wait for their status before merging.

[sberyozkin]

I've tested Michal's PR on my laptop, with quarkus-quickstarts/security-openid-connect-quickstart to confirm a KC DevService is started in dev and test modes, and that OIDC DevUI works as usual.
Additionally, I've confirmed OIDc Dev UI offers Auth0 login experience with quarkus.oidc.auth-server-url pointing to an Auth0 domain

[sberyozkin]

@michalvavrik I thought for a second if it would make sense to keep the base devservice abstract and have extension specific extensions which would deal with their own properties (oidc, oidc-client), etc and have some build time coordination informing each other the the dev service is started.
For example, we also have keycloak-authorization, which is OIDC plus KC authorization policy.
But then I thought we can rework easily if necessary

[michalvavrik]

@michalvavrik I thought for a second if it would make sense to keep the base devservice abstract and have extension specific extensions which would deal with their own properties (oidc, oidc-client), etc and have some build time coordination informing each other the the dev service is started. For example, we also have keycloak-authorization, which is OIDC plus KC authorization policy. But then I thought we can rework easily if necessary

I am all for loose coupling, did it this way because it feels easier to understand than new level of abstraction. FWIW if it will be me who introduce this for other extensions, I'll move these config properties to the extensions and enhance keycloakdevservicerequired build item. I can draw it if you have issue to migrate some service, for example keycloak-authorization.

[sberyozkin]

@michalvavrik Sure, we can look at it all later, thanks

[rsvoboda]

Almost feels like there should be a not in documentation about this @michalvavrik .

I also checked https://github.com/quarkusio/quarkus/wiki/Migration-Guide-3.16 and https://quarkus.io/blog/quarkus-3-16-1-released/. I didn't find anything highlighting this change.

[michalvavrik]

Almost feels like there should be a not in documentation about this @michalvavrik .

If you mean https://quarkus.io/version/main/guides/security-openid-connect-dev-services then I agree. This week I'll be implementing Keycloak Dev Svc for Keycloak Admin Clients, so I'll write into that document that we now configure auth-server-url for default OIDC client and client registration (and that we configure KC with anonymous client registration policy).

I also checked https://github.com/quarkusio/quarkus/wiki/Migration-Guide-3.16 and https://quarkus.io/blog/quarkus-3-16-1-released/. I didn't find anything highlighting this change.

"Breaking" part is that container is started if you use OIDC client without OIDC extension and you don't have configured auth server url for default client and you don't have disabled dev svc (or kc dev svc). I can see it can affect you if you don't have docker. But actual users - if they have OIDC Client enabled, they probably need auth server, so this can have only very little impact.

I'll let @sberyozkin deal with migration guide as I don't have perms.

[rsvoboda]

Thank you @michalvavrik.