Description
Replace the internal HTTP client implementation from Apache HTTP Client to a Vert.x-based (with Netty under the hood) HTTP client across Keycloak.
Value Proposition
Enable robust support for post-quantum cryptography (PQC) and hybrid key exchange algorithms in TLS handshakes used by Keycloak's outbound HTTP communications. Moving to a Vert.x-based HTTP client (with Netty under the hood) will provide flexibility for integrating native TLS engines (e.g., OpenSSL) required for PQC adoption without the need to rely on OpenJDK PQC support. Additionally, this will align HTTP client approach more closely with Quarkus.
Goals
- Implement a Vert.x-based HTTP client SPI (Vert.x uses Netty under the hood) that can serve as the default internal HTTP client for Keycloak.
- Ensure the Vert.x client supports PQC and hybrid key exchange algorithms by leveraging OpenSSL if it's present on the system.
- Preserve feature parity with the current Apache implementation (redirects, cookies, proxy support, auth, timeouts, retries).
- Ensure the migration is non-breaking: preserve public behavior and APIs used by extensions, adapters, and integrations; provide a compatibility layer and fallbacks where necessary.
- A performance benchmark comparing Apache vs Vert.x implementations across common Keycloak flows (identity provider federation, token exchange, user federation backends).
Non-Goals
- Anything related to inbound connections.
Discussion
No response
Notes
Hybrid Key Exchange will require OpenSSL to be present on the system. We'll need to figure out how to make this optional and configurable. We might want to have a config option to warn or even crash at startup if OpenSSL is missing.
Description
Replace the internal HTTP client implementation from Apache HTTP Client to a Vert.x-based (with Netty under the hood) HTTP client across Keycloak.
Value Proposition
Enable robust support for post-quantum cryptography (PQC) and hybrid key exchange algorithms in TLS handshakes used by Keycloak's outbound HTTP communications. Moving to a Vert.x-based HTTP client (with Netty under the hood) will provide flexibility for integrating native TLS engines (e.g., OpenSSL) required for PQC adoption without the need to rely on OpenJDK PQC support. Additionally, this will align HTTP client approach more closely with Quarkus.
Goals
Non-Goals
Discussion
No response
Notes
Hybrid Key Exchange will require OpenSSL to be present on the system. We'll need to figure out how to make this optional and configurable. We might want to have a config option to warn or even crash at startup if OpenSSL is missing.