Keycloak with GlaSSLess as FIPS provider #51896

slaskawi · 2026-08-20T11:04:53Z

slaskawi
Aug 20, 2026

Hey Keycloak Community 👋🏻

I would like to gather feedback on PR #51082, which prototypes integrating GlaSSLess as an additional FIPS-capable cryptographic provider for Keycloak.

The proposal does not remove Bouncy Castle support. Instead, it introduces a provider-selection model with:

--fips-provider=auto
--fips-provider=bouncycastle
--fips-provider=glassless

In auto mode, Keycloak selects Bouncy Castle when the BCFIPS provider is available and otherwise selects the bundled GlaSSLess provider. This approach helps introducing this feature in a backwards compatible way. Provider implementations are discovered through a small CryptoProviderFactory abstraction rather than being hard-coded into server startup.

The main goal is broader than adding one provider: it is to make Keycloak’s FIPS integration more predictable, portable, and and less dependent on Bouncy Castle.

Why redesigning FIPS capabilities matter?

Bouncy Castle and BCFIPS have enabled FIPS support in Keycloak, but the integration has repeatedly exposed operational problems outside Keycloak’s core identity functionality.

Common sources of friction include:

Installing the correct combination of BCFIPS, BCPKIX, BCTLS, and BCUTIL jars
Correctly configuring Java security-provider priority
Using yet another Key Store format (BCFKS)
Ensuring the provider is initialized before BCFKS keystores or truststores are accessed
Introducing BCJSSE behavior into HTTPS, LDAP, database, Infinispan, and JGroups connections
Tracking provider CVEs and behavior changes across upgrades

Addressing the pain points

Here's a short list that showcase, how GlaSSLess could improve the FIPS implementation in Keycloak:

Eliminates manual Bouncy Castle JAR assembly

GlaSSLess can be bundled with Keycloak, avoiding the need to install a compatible set of bc-fips, bcpkix-fips, bctls-fips, and bcutil-fips JARs.

Makes provider selection and priority explicit

Keycloak can select glassless directly, register it at the required JCA priority, and fail startup when provider registration is incorrect.

Avoids making BCFKS mandatory

GlaSSLess is not tied to the Bouncy Castle-specific BCFKS format, allowing standard keystore formats or external HSM/KMS solutions where the deployment’s security policy permits them.

Validates the provider before keystore and crypto initialization

Strict-mode startup checks can confirm that GlaSSLess and the OpenSSL FIPS provider are active before Keycloak accesses cryptographic services, reducing initialization-order failures.

Avoids requiring BCJSSE for TLS

GlaSSLess supplies JCA cryptography without inherently replacing the JDK TLS implementation, reducing BCJSSE-specific behavior across HTTPS, LDAP, databases, Infinispan, and JGroups.

Moves crypto maintenance closer to the platform

Using the operating system’s OpenSSL provider can align Keycloak with platform patching and FIPS-module lifecycles. This does not remove vulnerability tracking, but reduces dependence on coordinated upgrades across several Bouncy Castle artifacts.

Related work

Several Keycloak issues demonstrate the operational impact of the current integration:

#32163 — FIPS documentation update

The documented Bouncy Castle artifact set was incomplete. Users also needed bcutil-fips; without it, Keycloak failed with a NoClassDefFoundError.

This is a relatively small documentation problem, but it shows how easy it is to produce a non-working FIPS image by omitting one provider JAR.

#28526 — Truststore consolidation broke Keycloak FIPS mode

Truststore consolidation introduced PKCS12 assumptions that conflicted with BCFKS-based strict-mode deployments. Keycloak attempted to merge or parse a BCFKS store through an incompatible path and failed during startup.

This shows how tightly BCFIPS provider selection and BCFKS store handling have become connected.

#49139 — Starting FIPS mode fails with NoSuchAlgorithmException

A Quarkus build-step ordering change caused truststore initialization to run before the Bouncy Castle provider had been registered. Consequently, KeyStore.getInstance("BCFKS") failed even though the necessary provider files were present.

This is an example of provider-registration order becoming part of Keycloak’s startup correctness.

#39454 — JGroups errors in strict FIPS mode with Istio

A containerized, clustered deployment encountered BCJSSE TLS errors while JGroups attempted to establish encrypted connections. The nodes could not reliably form a cluster.

This demonstrates that selecting Bouncy Castle for FIPS can affect subsystems such as Infinispan and JGroups, even though those components are not directly related to token signing or password hashing.

#45906 — Support Java 25 with FIPS enabled

Keycloak’s Java 25 FIPS work was partially blocked by the validation status of BCFIPS on Java 25. Code and CI work could progress, but documentation could not simply claim a supported FIPS configuration without a matching validated provider/runtime combination.

This highlights how Keycloak’s Java upgrade path can become coupled to the validation lifecycle of a single cryptographic provider.

slaskawi · 2026-10-12T10:31:50Z

slaskawi
Oct 12, 2026
Author

Following the GlaSSLess integration prototype, I implemented another Keycloak prototype using Project Brisbane, which provides the JipherJCE Java security provider: #53711

Implementation details

Both prototypes use a CryptoProviderFactory to create a Keycloak CryptoProvider adapter. The adapter registers the underlying Java security provider.
In the Brisbane prototype, Bouncy Castle FIPS remains the default when FIPS is enabled. Select Brisbane at build time with --features=fips,brisbane. Add --fips-mode=strict for strict mode; otherwise, FIPS defaults to non-strict.
The prototype configures JipherJCE’s enforcement policy before initialization. Strict mode also requires JipherJCE to have the highest Java security provider priority.

Limitations and pain points identified during the PoC

Artifact distribution: I could not find a Brisbane/Jipher artifact in Maven Central. The prototype uses a JAR built and hosted by JitPack from a pinned commit in my fork.
Java and native access: Brisbane requires JDK 25 or later. In this prototype, it runs on the classpath, so I use --enable-native-access=ALL-UNNAMED. My JDK 25 checks succeeded without the flag but emitted a warning; with --illegal-native-access=deny, the flag was required. JDK documentation
OS-managed OpenSSL: The pinned version supports jipher.openssl.useOsInstance=true only on Oracle Linux 9.4 or later. It rejects RHEL/UBI even when their OpenSSL and FIPS-provider packages are installed. Brisbane can still run there with a separately configured OpenSSL installation, but this s 8000 ignificantly complicates adoption. OS detection.
Native packaging: The Brisbane JAR does not include OpenSSL. I therefore build and package the OpenSSL runtime and FIPS provider separately for each container architecture. This makes the downstream packaging much more complext, see the Dockerfile.
Provider ordering: Removing the priority requirement would require changes across Keycloak’s cryptographic callers. Third-party certificate-signing and XML-digest implementations also lack straightforward provider-selection hooks.
Coverage: JipherJCE does not implement the Java KeyStore SPI or JSSE. The inherited PKCS12/JKS paths use a JDK provider; certificate-path validation, TLS, and other cryptographic paths still need a provider audit.

0 replies

Navigation Menu

Repository navigation

Keycloak with GlaSSLess as FIPS provider #51896

Uh oh!

{{title}}

Uh oh!

Replies: 1 comment

Uh oh!

{{title}}

Uh oh!

Select a reply

Uh oh!

Keycloak with GlaSSLess as FIPS provider #51896

Uh oh!

slaskawi Aug 20, 2026

Why redesigning FIPS capabilities matter?

Addressing the pain points

Related work

Replies: 1 comment

Uh oh!

slaskawi Oct 12, 2026 Author

Implementation details

Limitations and pain points identified during the PoC

slaskawi
Aug 20, 2026

slaskawi
Oct 12, 2026
Author