KeyConf26: Reliable Event Architecture #53985

ahus1 · 2026-10-14T18:55:19Z

ahus1
Oct 14, 2026
Collaborator

This was discussed as part of

KeyConf26: Wicked Keycloak Challenges – Session Results #53984

The group wants Keycloak to emit events for every change and to deliver them reliably.

Context

External systems consume Keycloak events, for example to synchronize data or to audit changes. They depend on events being complete and actually delivered.

Problems

Inconsistent coverage: some objects emit events, others do not. For some objects, not all CRUD operations produce an event.
No delivery guarantees: Keycloak guarantees neither that an event is sent nor that it is received.

Open questions

Does an EventType enum already exist, and if so, what exactly is missing?

Sources and related GitHub issues

Reliability:

External events store #45303: umbrella issue; names non-transactional event listeners and reliable delivery (e.g. to Kafka) as goals.
Add a versioned event-export envelope and destination SPI #52616: child of External events store #45303; proposes at-least-once publication based on the outbox classes already in core for SSF.
Related discussions: Add a CloudEvents EventListenerProvider? #25133, Built-in support for sending keycloak events via webhooks #41175, Rethinking Audit Event Storage in Keycloak #44261
Transaction in event listener set to rollback only gets committed #9497

Consistency:

AdminEvent of resource type AUTHORIZATION_POLICY operation type CREATE doesn’t seem to get created. #20008
Delete operation does not fire admin event v2 #46792
Improve admin event logging to include more user / group / role details #50819: missing names and IDs, a missing group-assignment event, and a wrong event type for client role mappings.

Solution approaches

Consistency: define a complete, typed catalogue of event types (for example as an enum) that covers every resource and every CRUD operation.
Reliability: implement an event listener based on the transactional outbox pattern. The event is stored in the same database transaction as the change and delivered asynchronously afterwards.

Suggested improvements

Answer the open question: Keycloak already has an EventType enum for user events and ResourceType / OperationType for admin events. The real gap is coverage (see AdminEvent of resource type AUTHORIZATION_POLICY operation type CREATE doesn’t seem to get created. #20008, Delete operation does not fire admin event v2 #46792, Improve admin event logging to include more user / group / role details #50819), not the type itself.
Define the delivery semantics explicitly: at-least-once, ordering per resource, and an event ID consumers can use to deduplicate.
Keycloak core already contains outbox classes (OutboxStore, OutboxDrainerTask) built for SSF, according to Add a versioned event-export envelope and destination SPI #52616. Building on them is likely cheaper than a separate listener; change data capture is an alternative worth comparing.

Navigation Menu

Repository navigation

KeyConf26: Reliable Event Architecture #53985

Uh oh!

{{title}}

Uh oh!

Replies: 0 comments

Select a reply

Uh oh!

KeyConf26: Reliable Event Architecture #53985

Uh oh!

ahus1 Oct 14, 2026 Collaborator

Context

Problems

Open questions

Sources and related GitHub issues

Solution approaches

Suggested improvements

Replies: 0 comments

ahus1
Oct 14, 2026
Collaborator