Fire RealmAttributeUpdateEvent whenever a realm attribute changes#50799
Conversation
SSF listens for this event to create the ssf.read/ssf.manage client scopes when the SSF transmitter is switched on for an existing realm. But the event was only published by setAdminPermissionsEnabled, never by the generic RealmAdapter.setAttribute path that realm updates from the admin console go through. setAttribute now publishes the event when the attribute value actually changes (no event on no-op writes), so re-saving a realm does not re-fire events for unchanged attributes. Fixes keycloak#49236 Signed-off-by: Stan Silvert <ssilvert@redhat.com> Assisted-by: claude-fable-5
There was a problem hiding this comment.
Pull request overview
Publishes realm attribute update events for changed JPA attributes, enabling SSF scope creation for existing realms.
Changes:
- Suppresses events for unchanged attribute values.
- Adds SSF client-scope regression coverage.
- Refactors admin-permissions event publishing.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.
| File | Description |
|---|---|
model/jpa/.../RealmAdapter.java |
Publishes realm attribute events. |
ssf/tests/.../SsfTransmitterEnableCreatesClientScopesTests.java |
Tests SSF scope creation and restoration. |
Publish RealmAttributeUpdateEvent on attribute removal, avoid double-publish in setAdminPermissionsEnabled, add event contract test Signed-off-by: Stan Silvert <ssilvert@redhat.com>
…hange setAttribute now delegates to a private updateAttribute that reports whether the value changed and the event was published. The explicit repair event in setAdminPermissionsEnabled only fires when the write was a no-op, so a real transition no longer publishes twice when no listener creates the admin permissions client (e.g. with the ADMIN_FINE_GRAINED_AUTHZ_V2 feature disabled). Signed-off-by: Stan Silvert <ssilvert@redhat.com>
sguilhen
left a comment
There was a problem hiding this comment.
Thanks @ssilvert - LGTM.
One thing to flag: this broadens the RealmAttributeUpdateEvent surface. Previously, only setAdminPermissionsEnabled published this event for a single attribute. Now every setAttribute/removeAttribute call publishes it.
The existing listeners (JpaClientProviderFactory, SsfRealmResourceProviderFactory) all filter by attribute name, so they're fine. But custom listener implementations that react to RealmAttributeUpdateEvent without filtering by name will now fire on every attribute write, which can be frequent during realm imports or admin console saves.
This probably warrants an upgrading note mentioning the change in behavior, so that users with custom event listeners can add attribute-name filtering if needed.
SSF listens for this event to create the ssf.read/ssf.manage client scopes when the SSF transmitter is switched on for an existing realm. But the event was only published by setAdminPermissionsEnabled, never by the generic RealmAdapter.setAttribute path that realm updates from the admin console go through.
setAttribute now publishes the event when the attribute value actually changes (no event on no-op writes), so re-saving a realm does not re-fire events for unchanged attributes.
Fixes #49236
Assisted-by: claude-fable-5