Hello Group,

when writing custom EventListeners for propagating Keycloak Events to inform downstream systems 

of any user related changes one also needs to consider events that are caused by admins, e.g. AdminEvent.

Examples are the grant / revoke of a role, group membership changes (derived roles) or user account changes

performed by an admin user.

Currently it is not possible to differentiate those admin events when looking at the AdminEvent object 

without actually parsing / inspecting the representation. This makes it rather complicated to correctly react

specfic ways for an AdminEvent, e.g. on a Role Membership change, detect and resolve the new role, the user involved and propagate that to the downstream systems.

With https://issues.jboss.org/browse/KEYCLOAK-2961 I tried a simple workround by adding the 

actual realm resource paths to the AdminEvent objekt which allows me to deduce what actually happend.

Since the associated PR (https://github.com/keycloak/keycloak/pull/2774) was rejected I think a better solution would be to add dedicated "Event Subject" Information to the AdminEvents. 

Marek agreed that this would be a good idea in the PR discussion.

Subjects could be an enum with "ROLE", "USER/ACCOUNT", "GROUP", however for ROLE one would need to differentiate between REALM_ROLE / CLIENT_ROLE (for proper lookup) and ROLE creation and ROLE_ASSIGNEMNT, same with GROUP.

Together with the AdminEvent#OperationType one could deduce what happended, e.g.:

Event Subject: ROLE_ASSIGNMENT

Event OperationType: CREATE

-> role was granted

Event Subject: ROLE_ASSIGNMENT

Event OperationType: DELETE

-> role was revoked

It would be great if the event would carry some narrowed context information (OperationContext?), 

e.g. in case of a CLIENT_ROLE ROLE_ASSIGNMENT: clientId, roleId, userId

Cheers,

Thomas