[keycloak-dev] Proof of Concept for User Activity Dashboard

[Stian Thorgersen]

That's really cool and would be great to have this added to Keycloak.

Some questions/comments:

* What's the (+) under 7 total users?
* What's the purpose of "Logins along the year" - it looks cool, but I'm
not sure how it'd be used. It would also require storing events for the
whole year.
* I'm not keen on having db specific views. We already support quite a few
dbs so maintaining these would be painful. Would be better to delegate this
to Hibernate if possible and use ejq queries.
* Logins/Registrations should display date and time. At least if date is
not today.

On 29 May 2016 at 22:52, Thomas Darimont <thomas.darimont at googlemail.com>
wrote:

> Hello group,
>
> a few months ago I raised the feature request "Activity dashboard" in the
> Keycloak JIRA.
> https://issues.jboss.org/browse/KEYCLOAK-1840
>
> This weekend I gave this a spin and I think I got pretty far with it,
> see attached annotated screenshot.
>
> The idea was to leverage the information from the stored event data
> to compute some Keycloak usage statistics over time.
> My current prototype supports JPA (user / event) storage provider
> and works with postgresql but could be adapted to other databases
> including MongoDB.
>
> Since I need to compute the usage statistics based on the event data,
> events need to be stored and some views (3) need to be defined to
> make the data accessible from JPA in a generic fashion.
>
> Since the queries are quite complex I wanted to keep them out
> of the code and therefore used named native queries via orm.xml.
> The actual queries use some database specific date/time functions
> that I wanted to keep out of the code - thus I created views
> that could be adapted for each database and provisioned via liquibase.
>
> The view definitions can be found here:
> https://gist.github.com/thomasdarimont/24e11be101c6ed8773f22e1defc5d66e
>
> For MongoDB one could define appropriate aggregation framework pipelines
> to express the same query logic.
>
> I basically exposed the data from those views per realm via a newly
> introduced AnalyticsProvider interface that is accessible via
> KeycloakSession.
>
> Data from this AnalyticsProvider is then exposed as a REST resource called
> "DashboardResource".
> Data from this REST endpoint is then consumed by the admin frontend in a
> new section
> called "dashboard".
>
> In the frontend I used basic patternfly components, e.g.: cards & tables:
> https://rawgit.com/patternfly/patternfly/master/tests/cards.html
>
> For the heatmap I used http://cal-heatmap.com/#start which is based on
> d3js.
> There is also an angularjs directive that could be used as well.
> https://github.com/shekhargulati/angular-cal-heatmap-directive
>
> The current hacky code can be found here.:
>
> https://github.com/thomasdarimont/keycloak/commits/poc/KEYCLOAK-1840-dashboard
>
> The relevant commit is:
>
> https://github.com/thomasdarimont/keycloak/commit/40a7956f8e547edc148d2ddbaf27961f2a852203
>
> The code still needs a decent amount of polishing but I wanted to share
> this with
> you guys first to see if this could make it into Keycloak at some point.
>
> Cheers,
> Thomas
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160530/d7790aab/attachment.html