🧠 Humans of Cyber | Bill Burke
Keycloak centralizes identity with standards-based SSO, Quarkus performance, and cloud-native governance under CNCF stewardship.
In distributed systems, the network is no longer the boundary. Identity is.
As organizations moved toward microservices, Kubernetes, and hybrid cloud, embedding authentication logic into every service stopped scaling. Keycloak emerged to solve that fragmentation by centralizing identity, token issuance, and authorization into a reusable, standards-based platform.
Launched at Red Hat in 2014 and accepted into the Cloud Native Computing Foundation in 2023, Keycloak has evolved into one of the most widely deployed open-source IAM systems in cloud-native environments.
The Design Philosophy: Identity as a Service
Keycloak was initiated at Red Hat by Bill Burke and Stian Thorgersen. Burke’s background as Chief Architect of JBoss heavily influenced the architectural philosophy: identity should be externalized, standardized, and protocol-driven rather than custom-built inside applications.
Instead of forcing each service to implement:
Password hashing
Credential storage
Token validation
Session management
Keycloak provides a dedicated identity server that speaks industry-standard protocols.
From the beginning, it aligned with:
OAuth 2.0
OpenID Connect (OIDC)
SAML 2.0
This standards-first approach allowed it to integrate across heterogeneous enterprise environments without proprietary lock-in.
Runtime Reinvention: The WildFly to Quarkus Shift
One of Keycloak’s most consequential technical changes was its migration from WildFly to Quarkus.
The WildFly Era
WildFly, a full Java EE application server, offered flexibility and enterprise features. However, it was optimized for long-running VMs and dynamic deployments, not ephemeral containers.
Operational limitations included:
Slower startup due to runtime scanning
Higher memory consumption
Complex XML-based configuration
A heavier footprint inside containers
The Quarkus Transformation
Starting in version 17 and completed in version 18, Keycloak transitioned to Quarkus.
Quarkus shifts much of Java’s traditional runtime overhead to build time through augmentation. Classpath scanning, reflection handling, and proxy generation are processed during build rather than startup.
The results:
Faster container startup
Lower memory footprint
Simpler configuration via environment variables
Immutable container-first deployment model
This migration aligned Keycloak with Kubernetes-native operational patterns.
Governance Shift: From Red Hat to CNCF
In April 2023, Keycloak was accepted as an incubating project within the CNCF.
This transition marked a structural governance change:
From primarily Red Hat stewardship
To a neutral, community-driven model
CNCF incubation broadened contributor participation and reinforced Keycloak’s position in the cloud-native stack. Integration with Prometheus metrics, OpenTelemetry tracing, and Kubernetes-native tooling became central roadmap priorities.
Over 10,000 pull requests have contributed to the project’s maturity, reflecting sustained community investment.
Storage Strategy: Pragmatism Over Reinvention
Keycloak’s persistence layer became a focal point as deployments scaled.
The Map Storage Initiative
The Map Storage initiative aimed to replace the traditional JPA layer with a flexible abstraction capable of supporting NoSQL and horizontally scalable backends.
However, by October 2023, the initiative was discontinued. The complexity of achieving feature parity and maintaining two storage models simultaneously proved unsustainable.
Rather than fragmenting the architecture, the team pivoted.
The JPA Optimization Path
The existing JPA store was enhanced incrementally, leading to improvements in:
Cross-datacenter clustering
Multi-site behavior
Database-backed session management
This decision reflected architectural discipline: scale the proven layer rather than introduce instability.
Persistent User Sessions: Reliability as a Feature
Keycloak historically stored active sessions in memory using Infinispan. Cluster restarts invalidated sessions.
With versions 25 and 26, persistent user sessions were introduced and stabilized.
Sessions are now stored in the relational database, providing:
Survival across node restarts
Seamless upgrades
Improved multi-site stability
This model reduces JVM heap requirements but increases database load. High-traffic deployments must appropriately size their database infrastructure.
Identity systems are stateful by nature. Persistence makes that state durable.
Federation and Brokering: Bridging Legacy and Modern Identity
Keycloak supports two distinct integration patterns.
Identity Federation: Connecting Directories
Federation integrates existing LDAP or Active Directory stores.
Keycloak:
Validates credentials against the authoritative directory
Issues modern OIDC or SAML tokens
Optionally synchronizes users
This enables enterprises to modernize applications without migrating directory infrastructure.
Identity Brokering: Acting as an Intermediary
Brokering redirects users to external identity providers such as:
Google
GitHub
Corporate SAML IdPs
After authentication, Keycloak links or creates local accounts and issues its own tokens.
This model supports:
B2B SSO
Social login
Partner integrations
Federation centralizes internal identity. Brokering extends trust externally.
Authorization as a Policy Engine
Beyond authentication, Keycloak includes a full authorization framework built around a Policy Decision Point model.
Key components include:
Resource – the protected object
Scope – the permitted action
Policy – the rule set
Permission – the binding of policy to resource
Policies can be:
Role-based
Attribute-based
Time-based
Context-aware
JavaScript-defined
Aggregated policies allow compound enforcement such as “Manager role during business hours.”
This externalized authorization reduces hardcoded logic inside microservices and enables centralized policy control.
Operating in Kubernetes and Multi-Site Environments
Keycloak is commonly deployed in Kubernetes using the Keycloak Operator.
Operational patterns include:
StatefulSets for stable pod identity
Pod anti-affinity for resilience
Shared relational databases
Distributed Infinispan caching
For multi-region deployments, architectures often involve:
Global load balancing
Database replication
Cross-site cache synchronization
High availability depends on database durability and cache coherence.
Identity downtime is operationally unacceptable. Architecture reflects that priority.
Recent Developments (2025–2026)
Keycloak’s roadmap continues to expand into compliance and workload identity.
Notable advancements include:
Organizations feature for multi-tenant grouping
Enhanced Financial-grade API (FAPI) support
OpenID for Verifiable Credential Issuance
MDC logging with enriched contextual metadata
Federated client authentication replacing static secrets
Federated client authentication allows services to authenticate using infrastructure-issued tokens rather than long-lived client secrets. This aligns with emerging workload identity models in Kubernetes ecosystems.
Identity for machines is becoming as important as identity for users.
Security Hardening Principles
Running IAM in production requires layered controls:
Enforced TLS encryption
Managed database services with encrypted connections
Restricted Admin Console access
MFA for administrative accounts
Short-lived access tokens
DPoP for proof-of-possession enforcement
Theme customization should extend base templates to preserve security-critical flows.
Identity systems must balance usability with uncompromising security posture.
The Foundational Contributors
Keycloak was initiated at Red Hat in 2014 by Bill Burke and Stian Thorgersen.
Bill Burke’s prior work as Chief Architect of JBoss shaped the platform’s standards-driven architecture. The project’s long-term stability reflects Red Hat’s early stewardship and the subsequent transition to CNCF governance.
Under CNCF incubation, Keycloak continues to evolve through community contributions, enterprise deployments, and protocol alignment.
Its trajectory—from WildFly application server roots to a Quarkus-optimized, Kubernetes-native runtime—mirrors the broader transformation of enterprise software toward containerized, identity-centric security models.
Keycloak does not simply authenticate users. It centralizes trust across distributed systems.
Subscribe and Comment.
Copyright © 2026 911Cyber. All Rights Reserved.
Follow 911Cyber on: