Quarkus: Add OIDC integration tests which use WireMockServer

[sberyozkin]

Add a dedicated integration-tests/oidc-mock module which will use WireMockServer (similarly to the way it is shown in #10396) which will mock the following endpoints:
Bearer tokens and code flow:

• discovery
• jwks
• introspection

CodeFlow only

• token
• authorization (can be tricky as it will have to return html form challenge)

Starting from the bearer token case will be good

[geoandri]

I can help with this if no one else hasn't started working on it.

[cemnura]

Hello @geoandri,

I was going to work on this regarding to conversation with @sberyozkin on

https://groups.google.com/g/quarkus-dev/c/SVM4GDj9jM4

Would you like to work on this?

[geoandri]

Hi @cemnura,

no worries, I will pick up another one. Thanks for your response.

[sberyozkin]

@cemnura Hi Cem, thanks, I updated integration-tests/oidc-wiremock a little bit yesterday to only return a jwk key set. as nothing else is needed for verifying the bearer JWT tokens.

I was thinking that it would be helpful for others to see how to test the opaque/binary tokens, which require an introspection_path be set in the discovery doc. FYI, Keycloak introspection endpoint is called even for JWT tokens when no local matching JWK key is available, but we definitely have the users who have the opaque tokens.

So before moving to the code flow, lets add BearerOpaqueTokenAuthorizationTest (with its own Wiremock setup - note the default port is now used to avoid a port clash in CI) which will be a copy and paste of BearerTokenAuthorizationTest but it will use a token value such as 123. The discovery document should only include introspection_path, and the introspection document can be similar to what @loicmathieu used in this test, set the scope to "user admin", etc, username to alice.

But also, please enhance it a bit more, and in the introspection endpoint mock, check that the token value in the introspection request is equal to 123.

Give it a try please, and then we can move on to the code flow.
thanks

[sberyozkin]

@geoandri Thanks, would you like to consider #11695 ? I suggested earlier to @cemnura that may be he would also be interested in #11695, but I believe we can continue in parallel :-), while we can later focus with @cemnura on @TestSecurity support for all the injection types supported in OIDC (@IdToken JsonwebToken jwt, etc), #11695 is independent of OIDC.
But you are also welcome to pick up any other issue that can be of interest
thanks

[geoandri]

@sberyozkin I could definitely give it a try.

Thanks.

[cemnura]

Hi @sberyozkin,

@cemnura Hi Cem, thanks, I updated integration-tests/oidc-wiremock a little bit yesterday to only return a jwk key set. as nothing else is needed for verifying the bearer JWT tokens.

I will have a look to gain a further understanding.

I was thinking that it would be helpful for others to see how to test the opaque/binary tokens, which require an introspection_path be set in the discovery doc. FYI, Keycloak introspection endpoint is called even for JWT tokens when no local matching JWK key is available, but we definitely have the users who have the opaque tokens.

So before moving to the code flow, lets add BearerOpaqueTokenAuthorizationTest (with its own Wiremock setup - note the default port is now used to avoid a port clash in CI) which will be a copy and paste of BearerTokenAuthorizationTest but it will use a token value such as 123. The discovery document should only include introspection_path, and the introspection document can be similar to what @loicmathieu used in this test, set the scope to "user admin", etc, username to alice.

Okey, I will try to implement a BearerOpaqueTokenAuthorizationTest test in a dedicated module integration-tests/oidc-mock and setup a WireMock that includes the introspection_path.

But also, please enhance it a bit more, and in the introspection endpoint mock, check that the token value in the introspection request is equal to 123.

Give it a try please, and then we can move on to the code flow.
thanks

I will give it a shot and get back to you asap

[sberyozkin]

Hi @cemnura Thanks, to make it simpler, lets keep it within the same module you introduced, a different QuarkusTestResourceLifecycleManager should be enough :-), sorry if it is what you meant
thanks

[cemnura]

Hi @cemnura Thanks, to make it simpler, lets keep it within the same module you introduced, a different QuarkusTestResourceLifecycleManager should be enough :-), sorry if it is what you meant
thanks

I saw this comment to late unfortunately. But no worries I will merge it to the previous integration test module upon your approval.