<div dir="ltr">Sounds good to me</div><div class="gmail_extra"><br><div class="gmail_quote">On 7 June 2016 at 11:22, Thomas Darimont <span dir="ltr"><<a href="mailto:thomas.darimont@googlemail.com" target="_blank">thomas.darimont@googlemail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><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" target="_blank">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" target="_blank">https://github.com/keycloak/keycloak/pull/2774</a>) was rejected I think a better solution would be to add dedicated "Event Subject" 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 "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.</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>-> role was granted</div><div><br></div><div>Event Subject: ROLE_ASSIGNMENT</div><div>Event OperationType: DELETE</div><div>-> 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>
<br>_______________________________________________<br>
keycloak-dev mailing list<br>
<a href="mailto:keycloak-dev@lists.jboss.org">keycloak-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/keycloak-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/keycloak-dev</a><br></blockquote></div><br></div>