Contract testing with Quarkus on OIDC protected endpoints

[patoulatchi]

Hi all,

I'm working on a quarkus based microservice and wanted to setup contract testing using microcks. I followed this example and all work well and nicely integrated: https://github.com/microcks/microcks-quarkus-demo/tree/main

Now I would like to enable the authentication of my rest resources using oidc (with keycloak) and I'm struggling to understand how to setup Microcks to connect to the keycloak instance which is automatically started by the devservices of Quarkus. Is there an example out there which present a more realistic scenario with security in place of such a setup?

Thanks a lot for any hints or pointers.

Best regards
Nicolas

[lbroudoux]

Hi @patoulatchi,

This is not possible now as the testing OAuth 2 properties (see https://microcks.io/documentation/references/test-endpoints/#oauth2) cannot be set on our Testcontainers Java module, yet. This is a nice improvement though and would deserve creating an issue on the https://github.com/microcks/microcks-testcontainers-java or https://github.com/microcks/microcks-quarkus repos (the second one is actually based on the first and so the feature has to be made available in the testcontainers module first).

Feel free to create this one!

[patoulatchi]

Hey Laurent,

Thanks for your quick answer. Sure I will create a new feature request for that.

How does the community approaches such typically use case? I imagine I could solve my problem by using testcontainer and setup my environement in the init phase of the integration test. I will have to reconfigure Quarkus with the dynamic port of the Keycloak container and I don't know if Quarkus will handle this as they are compile time properties.

Thanks again et bonne soirée.

Nicolas

[lbroudoux]

Hum ... 🤔 Not sure it will actually work this way ... if the quarkus app is started in a regular QuarkusTest, my guess would be that you cannot reconfigure it later. I think it would be better to:

• either add Keycloak as a regular OICD DevService so that it produces configuration that can be fed into Quarkus App
• or start all components in a regular setup phase (but probably more complicated).

I think I tend to prefer the first approach. I should have free cycles in the coming week to add this feature on our testcontainers module/quarkus devservice.

Bonne soirée as well!

[patoulatchi]

Ah yes that would be great if you could build this directly into the microcks testcontainers part, I guess this makes a lot of sense to have this feature. So if I understand this correctly, you would add the ability to provide the keycloak related information ( url/port/client/secret/username/password ), in order to generate a token before the microcks is calling the application.

So when we create a new TestRequest object, we could pass the keycloak stuff at this moment. So it would look something similar to this below?:

TestRequest testRequest = new TestRequest.Builder()
      .serviceId("My API:1.0.0-SNAPSHOT")
      .runnerType(TestRunnerType.OPEN_API_SCHEMA.name())
      .testEndpoint("http://host.testcontainers.internal:" + quarkusHttpPort)
      .withKeycloakUrl("http://host.testcontainers.internal:" + keycloakPort).withClient("myOidcClient").with....
      .build();

I'm not sure if the Microcks container will be able to reach the keycloak container from the docker networking perspective...

[lbroudoux]

Yes, this is exactly what I had in mind. And yes, network is always a tricky thing but IIRC the Keycloak DevService is exposed both on host network and on dev services containers internal network. We should then be able to reach it in a way or another ;-)

[patoulatchi]

Ok that's great! I've create a new issue here: microcks/microcks-testcontainers-java#94

Thanks again.
Nicolas