[keycloak-dev] Custom AdminEvents

[Marek Posolda]

On 26/09/16 16:41, Dmitry Telegin wrote:
> Hi,
>
> The org.keycloak.events.* subsystem could potentially be of great use 
> for KeyCloak extensions (providers), especially for combinations of 
> JpaEntityProvider+RealmResourceProvider. Imagine we've implemented a 
> custom entity + REST resource, and we want to log create/update/delete 
> events for our entity, and then analyze log records in the event 
> viewer inside admin console.
>
> Unfortunately, the event subsystem in its current state is not very 
> useful for the above. This is due to resource types hardcoded into 
> org.keycloak.events.admin.ResourceType enum. When logging events for a 
> custom entity, the only option is to leave resource type empty:
>
>      adminEvent
>          .operation(OperationType.CREATE)
>          .resourcePath(uriInfo, myEntity.getId())
>          .representation(rep)
>          .success();
> This will obviously create a log record without a "Resource Type" 
> value, which is definitely not of great use.
>
> It would be nice to have extensible ResourceType. One of the 
> approaches to the extensible enum problem is described here: 
> https://blogs.oracle.com/darcy/entry/enums_and_mixins
> I think this could be applied here with minimal modifications. 
> ResourceType would become an interface, and there would be introduced 
> something like StandardResourceType enum, which would implement 
> built-in resource types as enum keys, and store custom types in a 
> static map-backed registry. A public static method would be introduced 
> so that extension authors could register their own resource types. In 
> the future, when (I hope) registering providers will be done with 
> annotations, this could be even more simplified and made purely 
> declarative.
+1

Maybe even easier if ResourceType will be just a wrapper around String, 
so if you do:
adminEvent.
    .operation(OperationType.CREATE)
    .resourceType(ResourceType.from("MY_FOO_RESOURCE"))
    ...

it will just work. No need to register anything. Should be backwards 
compatible too. Not sure which approach is better...
>
> The same approach could be applied to extending login events 
> (potentially useful for custom authenticators etc.) What do you think? 
> If everybody is OK with it, I can go on with JIRA and a PR.
The login events already has "details", which allow you to add here any 
custom fields you want? Isn't that sufficient?

Marek
>
> Cheers,
> Dmitry
>
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160926/703d0890/attachment.html