TrustStore support for OIDC and OIDCClient #18012

sberyozkin · 2021-06-18T16:50:38Z

This draft PR adds support for configuring OIDC, OIDC client and also Keycloak authorization with the trust store file/password - property names are the same as in Vert.x HTTP, we can add more related properties as needed (alias, etc).

CC @rvansa

sberyozkin · 2021-06-18T17:27:56Z

...rver/src/main/java/io/quarkus/test/keycloak/server/KeycloakTestResourceLifecycleManager.java

        keycloak = new GenericContainer<>(keycloakDockerImage)
                .withExposedPorts(8080, 8443)
                .withEnv("DB_VENDOR", "H2")
                .withEnv("KEYCLOAK_USER", "admin")
                .withEnv("KEYCLOAK_PASSWORD", "admin")
                .waitingFor(Wait.forHttp("/auth").forPort(8080));

+        if (KEYCLOAK_USE_HTTPS && KEYCLOAK_TRUSTSTORE_REQUIRED) {
+            keycloak = keycloak.withClasspathResourceMapping(KEYCLOAK_TLS_KEY, KEYCLOAK_TLS_KEY_MOUNTED_PATH,


@pedroigor is it the right way to mount a key ? I've read in in a rather old Stackoverflow that this is how it should be done, but I'm not sure it is still the case, the test does not work

@pedroigor I have not seen in the latest docs any references to a private key having to be mounted to /etc/x509/http/tls.key, it is only mentioned in the non up to date docs. I wonder what the current approach is - mounting a private key should lead to WildFly converting it to a keystore, but perhaps now an actual keystore file should be mapped ?

Perhaps it should be /etc/x509/https/tls.key?

@pedroigor thanks, the docs at https://hub.docker.com/r/jboss/keycloak/ do refer to /etc/x509/https.

I'm pretty sure some progress has been made as a result since now I'm seeing in the logs:

Creating HTTPS keystore via OpenShift's service serving x509 certificate secrets.. HTTPS keystore not created at: /opt/jboss/keycloak/standalone/configuration/keystores/https-keystore.jks (check permissions?)

I've checked, this error is not logged if the path is wrong (http in /etc/x509/http/tls.key).

The section at https://hub.docker.com/r/jboss/keycloak/ points out at the possible problem.

The permissions for both tls.crt and tls.key are r for the world on my system.
Host mounting them with withClasspathResourceMapping or copying to the docker (.withCopyFileToContainer) makes no difference though....
But it is nearly there, we just need to see how it is done in some working deployments

@pedroigor @rvansa the example here shows how these files are mapped with the specific user/group ids and also the mode. TestContainers does now allow to set it when mounting the files.
I've also seen somewhere setting the mode to 655 on the local system before mounting the files should work - but I could not make it work.

sberyozkin · 2021-06-23T09:50:37Z

@rvansa Would you like to try this PR against your deployment ? If we'll have problems verifying it with the test then I guess we can just merge it without it if you confirm it works for you, though the test should really be done :-)

rvansa · 2021-06-23T12:17:08Z

@sberyozkin Hi, thanks a lot for the fix. I'll try to verify it soon but I have pretty full hands this week and the next one I won't be available, so have some patience please.

sberyozkin · 2021-06-23T14:28:38Z

@rvansa Sounds good :-), I'll be off next week myself, thanks

famod · 2021-06-24T18:20:11Z

I'll try to put that on my list as well since we also have to use TLS to talk to our Keycloak container and in dev env we also use custom certs.

famod · 2021-07-05T14:41:57Z

I haven't yet gotten around to testing this but I have it on my list for this week. Would be great to have this end up in Quarkus 2.1

Btw, main is now on vert.x 4.1.1 which offers aliasPassword (and 4.1 offers alias). #18387 is adding aliasPassword to quarkus-vertx-http.

sberyozkin · 2021-07-06T16:28:34Z

@famod Thanks, I believe you meant trustStoreKeyAlias, I'll add this property as well

famod · 2021-07-06T16:31:20Z

I was actually thinking of the next step that would be client cert auth (for mutual TLS).

sberyozkin · 2021-07-07T09:09:07Z

@famod

I was actually thinking of the next step that would be client cert auth (for mutual TLS).

OK

famod · 2021-07-15T12:13:13Z

@sberyozkin Sorry, didn't have the time yet to look at it. Do you think its still realistic to get this into 2.1?

sberyozkin · 2021-07-16T11:01:05Z

@famod, np at all - we need at least a single confirmation this PR actually helps - I can try to experiment as well, haven't had time yet; so not sure if it can make it, I believe it would be safe to backport though

sberyozkin · 2021-07-26T16:03:26Z

@famod Hi, I've managed to verify this code against a standalone Keycloak instance, by following Server installation Guide and also updating a custom realm configuration to require SSL for all the requests as described here. I copied the JKS file used in this PR, here are the relevant fragment:

 <subsystem xmlns="urn:jboss:domain:undertow:12.0" default-server="default-server" default-virtual-host="default-host" default-servlet-container="default" default-security-domain="other" statistics-enabled="${wildfly.undertow.statistics-enabled:${wildfly.statistics-enabled:false}}">
            <buffer-cache name="default"/>
            <server name="default-server">
<!--
                <https-listener name="https" socket-binding="https" security-realm="ApplicationRealm" enable-http2="true"/>
-->
                <https-listener name="https" socket-binding="https" security-realm="UndertowRealm"/>

        </subsystem>

and

<management>
        <security-realms>
<security-realm name="UndertowRealm">
    <server-identities>
        <ssl>
            <keystore path="keycloak.jks" relative-to="jboss.server.config.dir" keystore-password="secret" />
        </ssl>
    </server-identities>
</security-realm>
        </security-realms>
    </management>

I've also had to add a new enum, CERTIFICATE_VALIDATION to support a case where only the certificate validation but no hostname verification is required. I also imported the existing realm from quarkus-quickstarts/security-openid-connect-quickstart

Finally I've tweaked BearerTokenAuthorizationTest:

Commented //@QuarkusTestResource(KeycloakTestResourceLifecycleManager.class)
Copied getAccessToken from KeycloakTestResourceLifecycleManager to BearerTokenAuthorizationTest and updated to set the truststore path and secret exactly as it is done in KeycloakTestResourceLifecycleManager (and also use backend-client client id which is created from the existing realm)
Updated application.properties to have auth-server-url to point to https://localhost:8543/auth/realms/quarkus
Removed a ref to the email claim from application.properties as it is not avail in that existing realm
Finally run a slightly updated test BearerTokenAuthorizationTest#testSecureAccessSuccessCustomPrincipal

@Test
    public void testSecureAccessSuccessCustomPrincipal() {
            RestAssured.given().auth().oauth2(getLocalAccessToken("alice"))
                    .when().get("/api/users/me")
                    .then()
                    .statusCode(200)
                    .body("userName", equalTo("alice"));
    }

and it worked.

I've temporarily disabled though the test resource factory code which sets up the trust store, I'll open an issue afterwards to try and get the test running, I've found another resource:
https://strimzi.io/blog/2019/10/25/kafka-authentication-using-oauth-2.0/

which suggests that the test factory does exactly the same thing by mounting the key and cert, but something just does not click - all these docs refer to the old image, so it needs some support from the KC guys.

Have a look please and I'll merge once you approve

famod · 2021-07-26T16:41:43Z

I have just started testing this PR with my current Quarkus project (that incorporates KC).

famod · 2021-07-26T17:45:36Z

@sberyozkin Hum...it seems like I'm hitting a wall here as I keep getting:

io.quarkus.oidc.OIDCException: OIDC server is not available at the 'https://idp:8443/auth/realms/egbr' URL
[...]
 Caused by: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target

I seems as if the entry in my store is not taken into account. It does find the store though because settings some invalid value for quarkus.oidc.tls.trust-store-file does yield an exception (as expected).

I even tried setting the alias.

famod · 2021-07-26T18:16:53Z

Nevermind, the store was missing our custom CA cert (it only contained the actual server cert). I will conclude my review tomorrow.
But looking good so far! 🎉

famod

Works in my project/setup and code LGTM.

I'll trust you on that test factory part @sberyozkin 🙂, didn't have a look at it myself.

I'll mark this for backport and see how it goes.

famod · 2021-07-26T21:12:35Z

Have a look please and I'll merge once you approve

I read that a bit wrong and merged it already but I don't think it matters who merges in the end. 😉

sberyozkin · 2021-07-26T21:17:02Z

@famod cool, thanks for checking it (I just came here to mention that 8543 port was used because I started with a 100 port offset :-) )

sberyozkin · 2021-07-26T21:17:57Z

@famod in the next iteration we can wire in a mutual tls authentication, will have a look later on

sberyozkin requested a review from pedroigor June 18, 2021 16:50

quarkus-bot bot added area/oidc area/testing labels Jun 18, 2021

sberyozkin force-pushed the oidc_trust_certificate branch 2 times, most recently from 9690f29 to 7eb1648 Compare June 18, 2021 17:25

sberyozkin commented Jun 18, 2021

View reviewed changes

sberyozkin force-pushed the oidc_trust_certificate branch from 7eb1648 to 053647b Compare June 22, 2021 13:43

sberyozkin force-pushed the oidc_trust_certificate branch 2 times, most recently from 0b721fd to e0c17dd Compare June 28, 2021 12:35

sberyozkin force-pushed the oidc_trust_certificate branch from e0c17dd to 1c5a9e1 Compare July 7, 2021 16:17

sberyozkin requested a review from famod July 26, 2021 15:29

sberyozkin marked this pull request as ready for review July 26, 2021 15:29

sberyozkin marked this pull request as draft July 26, 2021 15:30

sberyozkin marked this pull request as ready for review July 26, 2021 16:04

sberyozkin force-pushed the oidc_trust_certificate branch from 1c5a9e1 to 90243f7 Compare July 26, 2021 16:04

TrustStore support for OIDC and OIDCClient

715ccdb

sberyozkin force-pushed the oidc_trust_certificate branch from 90243f7 to 715ccdb Compare July 26, 2021 16:07

famod approved these changes Jul 26, 2021

View reviewed changes

famod merged commit 24829c7 into quarkusio:main Jul 26, 2021

quarkus-bot bot added this to the 2.2 - main milestone Jul 26, 2021

famod added the triage/backport? label Jul 26, 2021

sberyozkin deleted the oidc_trust_certificate branch July 26, 2021 21:18

gsmet modified the milestones: 2.2 - main, 2.1.1.Final Aug 3, 2021

gsmet removed the triage/backport? label Aug 3, 2021

famod mentioned this pull request Aug 24, 2021

Support keystore configuration for mutual TLS in oidc and oidc-client #19634

Closed

johnaohara mentioned this pull request Aug 17, 2023

TLS not working in OCP cluster with self signed cert. Hyperfoil/horreum-operator#5

Closed

barreiro mentioned this pull request Nov 21, 2023

Enhance keycloak-admin-client extension to support TLS trust and key stores #37243

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

TrustStore support for OIDC and OIDCClient #18012

TrustStore support for OIDC and OIDCClient #18012

sberyozkin commented Jun 18, 2021 •

edited

Loading

sberyozkin Jun 18, 2021

sberyozkin Jun 23, 2021 •

edited

Loading

pedroigor Jun 25, 2021

sberyozkin Jun 28, 2021 •

edited

Loading

sberyozkin Jun 28, 2021

sberyozkin commented Jun 23, 2021 •

edited

Loading

rvansa commented Jun 23, 2021

sberyozkin commented Jun 23, 2021

famod commented Jun 24, 2021

famod commented Jul 5, 2021 •

edited

Loading

sberyozkin commented Jul 6, 2021

famod commented Jul 6, 2021

sberyozkin commented Jul 7, 2021

famod commented Jul 15, 2021

sberyozkin commented Jul 16, 2021

sberyozkin commented Jul 26, 2021 •

edited

Loading

famod commented Jul 26, 2021

famod commented Jul 26, 2021

famod commented Jul 26, 2021

famod left a comment •

edited

Loading

famod commented Jul 26, 2021

sberyozkin commented Jul 26, 2021

sberyozkin commented Jul 26, 2021

TrustStore support for OIDC and OIDCClient #18012

TrustStore support for OIDC and OIDCClient #18012

Conversation

sberyozkin commented Jun 18, 2021 • edited Loading

sberyozkin Jun 18, 2021

Choose a reason for hiding this comment

sberyozkin Jun 23, 2021 • edited Loading

Choose a reason for hiding this comment

pedroigor Jun 25, 2021

Choose a reason for hiding this comment

sberyozkin Jun 28, 2021 • edited Loading

Choose a reason for hiding this comment

sberyozkin Jun 28, 2021

Choose a reason for hiding this comment

sberyozkin commented Jun 23, 2021 • edited Loading

rvansa commented Jun 23, 2021

sberyozkin commented Jun 23, 2021

famod commented Jun 24, 2021

famod commented Jul 5, 2021 • edited Loading

sberyozkin commented Jul 6, 2021

famod commented Jul 6, 2021

sberyozkin commented Jul 7, 2021

famod commented Jul 15, 2021

sberyozkin commented Jul 16, 2021

sberyozkin commented Jul 26, 2021 • edited Loading

famod commented Jul 26, 2021

famod commented Jul 26, 2021

famod commented Jul 26, 2021

famod left a comment • edited Loading

Choose a reason for hiding this comment

famod commented Jul 26, 2021

sberyozkin commented Jul 26, 2021

sberyozkin commented Jul 26, 2021

sberyozkin commented Jun 18, 2021 •

edited

Loading

sberyozkin Jun 23, 2021 •

edited

Loading

sberyozkin Jun 28, 2021 •

edited

Loading

sberyozkin commented Jun 23, 2021 •

edited

Loading

famod commented Jul 5, 2021 •

edited

Loading

sberyozkin commented Jul 26, 2021 •

edited

Loading

famod left a comment •

edited

Loading