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...

Hmm interesting, but how do we not break the existing code? The ResourceType.* fields should survive somehow. Do you suggest something like this?

public class ResourceType {
    public static final ResourceType REALM = ResourceType.from("REALM");
    public static final ResourceType REALM_ROLE = ResourceType.from("REALM_ROLE");
    ....
}



    

      


      

      
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?


  


Ah, I've missed that. Indeed, that would be sufficient; however, I would also suggest introducing additional key to the org.keycloak.events.EventType enum, like PROVIDER or EXTENDED or something like that. Imagine for example a custom authenticator working with hardware HOTP tokens. If a device gets out of sync, the user has to enter two consecutive passwords, so that the device gets resynched. (It's a real-world extension I've been working on BTW.) It's important to log such resync events, but they don't fit into any of ~70 types currently coded into EventType - hence the stipulation for additional type.

Dmitry