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@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev