<html><head>
<meta content="text/html; charset=windows-1252" http-equiv="Content-Type">
</head>
<body><div><br></div><blockquote type="cite">
<div class="moz-cite-prefix">On 26/09/16 16:41, Dmitry Telegin
wrote:<br>
</div>
<blockquote cite="mid:1474900897.7390.25.camel@cargosoft.ru" type="cite">
<div>Hi,</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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:</div>
<div><br>
</div>
<pre> adminEvent</pre>
<pre> .operation(OperationType.CREATE)</pre>
<pre> .resourcePath(uriInfo, myEntity.getId())</pre>
<pre> .representation(rep)</pre>
<pre> .success();</pre>
<pre></pre>
<div>This will obviously create a log record without a "Resource
Type" value, which is definitely not of great use.</div>
<div><br>
</div>
<div>It would be nice to have extensible ResourceType. One of the
approaches to the extensible enum problem is described here: <a moz-do-not-send="true" href="https://blogs.oracle.com/darcy/entry/enums_and_mixins">https://blogs.oracle.com/darcy/entry/enums_and_mixins</a></div>
<div>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.</div>
</blockquote>
+1<br>
<br>
Maybe even easier if ResourceType will be just a wrapper around
String, so if you do:<br>
adminEvent.<br>
.operation(OperationType.CREATE)<br>
.resourceType(ResourceType.from("MY_FOO_RESOURCE"))<br>
...<br>
<br>
it will just work. No need to register anything. Should be backwards
compatible too. Not sure which approach is better...<br></blockquote><div><br></div><div>Hmm interesting, but how do we not break the existing code? The ResourceType.* fields should survive somehow. Do you suggest something like this?</div><div><br></div><pre>public class ResourceType {</pre><pre> public static final ResourceType REALM = ResourceType.from("REALM");</pre><pre> public static final ResourceType REALM_ROLE = ResourceType.from("REALM_ROLE");</pre><pre> ....</pre><pre>}</pre><pre><br></pre><div><br></div><blockquote type="cite">
<blockquote cite="mid:1474900897.7390.25.camel@cargosoft.ru" type="cite">
<div><br>
</div>
<div>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.</div>
</blockquote>
The login events already has "details", which allow you to add here
any custom fields you want? Isn't that sufficient?<br></blockquote><div><br></div><blockquote type="cite">
</blockquote><div>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.</div><div><br></div><div>Dmitry</div><div><br></div></body></html>