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