<div dir="ltr"><div>Hello Group,</div><div><br></div><div>when writing custom EventListeners for propagating Keycloak Events to inform downstream systems </div><div>of any user related changes one also needs to consider events that are caused by admins, e.g. AdminEvent.</div><div><br></div><div>Examples are the grant / revoke of a role, group membership changes (derived roles) or user account changes</div><div>performed by an admin user.</div><div><br></div><div>Currently it is not possible to differentiate those admin events when looking at the AdminEvent object </div><div>without actually parsing / inspecting the representation. This makes it rather complicated to correctly react</div><div>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.</div><div><br></div><div>With <a href="https://issues.jboss.org/browse/KEYCLOAK-2961">https://issues.jboss.org/browse/KEYCLOAK-2961</a> I tried a simple workround by adding the </div><div>actual realm resource paths to the AdminEvent objekt which allows me to deduce what actually happend.</div><div><br></div><div>Since the associated PR (<a href="https://github.com/keycloak/keycloak/pull/2774">https://github.com/keycloak/keycloak/pull/2774</a>) was rejected I think a better solution would be to add dedicated &quot;Event Subject&quot; Information to the AdminEvents. </div><div><br></div><div>Marek agreed that this would be a good idea in the PR discussion.</div><div><br></div><div>Subjects could be an enum with &quot;ROLE&quot;, &quot;USER/ACCOUNT&quot;, &quot;GROUP&quot;, 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.</div><div><br></div><div>Together with the AdminEvent#OperationType one could deduce what happended, e.g.:</div><div>Event Subject: ROLE_ASSIGNMENT</div><div>Event OperationType: CREATE</div><div>-&gt; role was granted</div><div><br></div><div>Event Subject: ROLE_ASSIGNMENT</div><div>Event OperationType: DELETE</div><div>-&gt; role was revoked</div><div><br></div><div>It would be great if the event would carry some narrowed context information (OperationContext?), </div><div>e.g. in case of a CLIENT_ROLE ROLE_ASSIGNMENT: clientId, roleId, userId</div><div><br></div><div>Cheers,</div><div>Thomas</div></div>