[keycloak-dev] Custom AdminEvents

[Dmitry Telegin]

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

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