The way I'm currently implementing it is that there's two interfaces:
An AuditListener listenes for audit events, but doesn't provide a way to read them. So
far I've added an implementation using jboss-logging for this.
An AuditProvider listens for audit events, but also provides a way to query for events.
This is used by the admin console and the account management to view audit events. I
haven't done any implementations of this yet.
The idea was that a realm could have one or more listeners, but only a single provider.
Main issue with parsing rolling files would be to find events associated with particular
users, or applications. Not sure we need to support finding events by-app, but we
certainly need to be able to display events for a specific user.
----- Original Message -----
From: "Bill Burke" <bburke(a)redhat.com>
Sent: Friday, 28 March, 2014 4:05:49 PM
Subject: [keycloak-dev] Do we need a RDMS/Mongo backed Audit Log?
If you look at things like fail2ban, they parse logs in order to make
Do we really need our Audit Log to be backed by an actual database?
Yes, we need an "Event" or "Action" log that a user and/or admin sees
things they need to be aware of. But logging of successful logins,
login failures, and the like should be pushed to a rolling log file, no?
Then Keycloak could hook into things like fail2ban.
JBoss, a division of Red Hat
keycloak-dev mailing list