Keycloak devservice without OIDC

[agreedSkiing]

Description

Would it be possible to make the keycloak dev service universal between all the keycloak extensions, so that I don't need to include the oidc dependency just to disable it later?

The project I'm working with is only using the keycloak admin client and letting an oidc checker/application in-front of the application fix the ABAC/RBAC validation.

We or the team wants to use the keycloak devservice as our “innerloop” testing tool and then in the “outloop” (ci/cd pipeline) use a dedicated keycloak installation.

Implementation ideas

No response

[quarkus-bot]

/cc @geoand (devservices), @pedroigor (keycloak,oidc), @sberyozkin (keycloak,oidc), @stuartwdouglas (devservices)

[sberyozkin]

Does adding the oidc extension in the test scope work ?

[agreedSkiing]

Think I wrote it in the first post🤔? Might not have done that, but by including OIDC dependency I do get the devserice, but why should I need to include the OIDC dependency when I will just turn it off in the end? I just included more code and maybe deployed a larger application in the end. P.S. is pretty much the same issue or enchantment that i to quickly resolved in #34156 P.P.S. This in my narrow opinion would also help to use the keycloak admin client to self discover the http auth endpoint easier than needing quarkus.keycloak.admin-client.server-url=${keycloak.url:http://externalurl/auth}

[sberyozkin]

@agreedSkiing

Think I wrote it in the first post🤔? Might not have done that, but by including OIDC dependency I do get the devserice, but why should I need to include the OIDC dependency when I will just turn it off in the end?

I've updated the comment when I first made it, as I forgot to mention the test scope, you use it for tests, so my question is, does it work when this dependency is in the test scope, if yes, then you don't have to exclude it

[agreedSkiing]

Oh yes it worked for test scope but quarkus dev is to my knowledge not part of the test scope or is it? Don’t know what scope it uses 🫤 Message ID: ***@***.***>

[agreedSkiing]

Correction to my previous comment. It works for the test scope

[sberyozkin]

@agreedSkiing OIDC dev service, like any other dev service, offers 2 containers:

• one container supports Dev UI experience, example, in case of OIDC, one can test endpoints protected by OIDC directly from the OIDC SPA - but you don't use quarkus-oidc in prod, so I believe it is of no interest in your case
• another container supports run integration tests - which fits your requirement - is it not enough for your requirements ?

The other thing is that as @stuartwdouglas has clarified to me earlier is that none of the deployment-only dependencies actually make it into the prod code, so if you need OIDC Dev UI support too, you can add quarkus-oidc-deployment without the test scope as well and avoid excluding it.

[sberyozkin]

@agreedSkiing Ignore my last point there please, doesn't apply unless an extension is built.

But I'd like to understand better what exactly is required from the OIDC devservice in your case. So far I think the test scope should be sufficient, please explain why it may not be the case.

May be you also need a DevUI level Keycloak Admin link to set Keycloak directly from Dev UI ?

Having some common templating support for a few OIDC and Keycloak client side extensions as well as for OIDC itself may make sense.

[agreedSkiing]

For my use case, it would be enough with that a keycloak devservice spins u, imports my realm if there is one or creates one base on the admin clients realm config and assigns the keycloak url to the admin clients connections. Might also be nice to have depending on the authentication to keycloak that it creates a user/client with the correct credentials.

[sberyozkin]

@agreedSkiing I'm still not sure what is missing

For my use case, it would be enough with that a keycloak devservice spins u, imports my realm if there is one or creates one base on the admin clients realm config

That should already work in the test scope for running tests

and assigns the keycloak url to the admin clients connections.

Each component has its own namespaces, and Dev service creates a common keycloak.url property, it is not exactly assigning it to a Keycloak Admin Client specific property but it only requires a single test profile level property to get it assigned correctly given keycloak.url is available.

I believe, from what I've read so far in your comments, that the use case is covered.

However, making sure a Dev UI Keycloak Admin link is available for keycloak-admin-client, oidc-client-*,possibly oidc-token-propagation, appears to be useful.

Might also be nice to have depending on the authentication to keycloak that it creates a user/client with the correct credentials.

Can you please clarify what do you mean ?

[agreedSkiing]

Depending if the admin client has quarkus.keycloak.admin-client.grant-type=PASSWORD or CLIENT_CREDENTIALS set the admin client uses different kinds of properties. https://quarkus.io/guides/security-keycloak-admin-client#quarkus-keycloak-admin-client_configuration Also from your answer I get a hint that quarkus:dev is started in the testing scope? Is that so? I really don’t know the scopes of the different stages of quarkus like quarkus integration test (in my opinion blackbox testing).

[sberyozkin]

@agreedSkiing I was saying that the devservice supports launching 2 containers, one to support the dev mode experience (in case of OIDC - to support the Dev UI OIDC SPA where users can login to Keycloak, and test the OIDC protected endpoint with the acquired tokens), another one for running the integration tests - which is what is required for an extension like quarkus-keycloak-admin and given that you have confirmed adding the quarkus-oidc in the test scope works for you, I'm still not sure what is the scope of this enhancement request.

I'm positive in general about improving the dev service support for Keycloak centric and more general OIDC client extensions but like I said, it looks like your requirement is already met, minus that you do not have a Keycloak admin client address property auto-assigned.

Perhaps we can consider a new common extension which launches containers only and only sets a shared keycloak.url property and other extensions continue with preparing extension specific properties, UI, etc... I think it makes sense so I'll keep this enhancement request open - it may take a little while to resolve, for now please use the test scoped quarkus-oidc depedency for running the tests

[agreedSkiing]

Right, okey. I’m currently also using it, the devservice, outside of QuarkusTest and QuarkusIntegrationTest so I can’t use the test scope only ☹. 2024-02-06 20:27:02,983+01 WARN [io.qua.config] () () (Quarkus Main Thread) Unrecognized configuration key "quarkus.keycloak.devservices.image-name" was provided; it will be ignored; verify that the dependency extension for this configuration is set or that you did not make a typo 2024-02-06 20:27:02,984+01 WARN [io.qua.config] () () (Quarkus Main Thread) Unrecognized configuration key "quarkus.oidc.enabled" was provided; it will be ignored; verify that the dependency extension for this configuration is set or that you did not make a typo 2024-02-06 20:27:02,984+01 WARN [io.qua.config] () () (Quarkus Main Thread) Unrecognized configuration key "quarkus.keycloak.devservices.port" was provided; it will be ignored; verify that the dependency extension for this configuration is set or that you did not make a typo 2024-02-06 20:27:02,985+01 WARN [io.qua.config] () () (Quarkus Main Thread) Unrecognized configuration key "quarkus.keycloak.devservices.enabled" was provided; it will be ignored; verify that the dependency extension for this configuration is set or that you did not make a typo 2024-02-06 20:27:02,986+01 WARN [io.qua.config] () () (Quarkus Main Thread) Unrecognized configuration key "quarkus.log.handler.gelf.enabled" was provided; it will be ignored; verify that the dependency extension for this configuration is set or that you did not make a typo 2024-02-06 20:27:02,987+01 WARN [io.qua.config] () () (Quarkus Main Thread) Unrecognized configuration key "quarkus.keycloak.devservices.realm-path" was provided; it will be ignored; verify that the dependency extension for this configuration is set or that you did not make a typo

[lebesis]

Hello.

I am developing a microservice, which will act as a bridge between two systems with different authentication/authorization mechanisms.
Therefore I have to use a different library for incoming request authorization and quarkus-rest-client-oidc-filter for outgoing requests.

My issue is that I cannot use keycloak dev service without enabling quarkus-oidc in the default scope.

I have tried using quarkus.oidc.enabled=false and it does work if you start the application with this setting commented out and then hot reload by uncommenting it. But this is a workaround I'd rather not use.
I 've tried using this setting in conjunction with quarkus.keycloak.devservices.enabled=true, but still no dice.

It would be nice if the dev services could be started by quarkus-oidc-client without including quarkus-oidc