7:20 a.m.
What events needs to be persisted, and also viewable through admin and acct mngmt, depends
on the scenario. Some will be happy with disabling it all together, others will want to
audit every little security related event there is. Most will probably want some middle
ground. I certainly believe success and failed login attempts are important, in-fact a lot
of websites let users view their login history through their account management (see
attachment).
With regards to controlling the audit size, I think we need to be able to:
* Filter events prior to persisting
* Expire events after a certain time
* Aggregate events
How the events are persisted will also differ. Some will want it saved to a log file (we
already have this) others will want to save it to a store where they can query it in a
sensible way. The ideal store would probably be something like Cassandra, as that supports
querying, as well as running map reduce jobs which are very powerful to analyze the audit
as well as aggregate the data over time, and is also highly performant for this type of
data.
It's not all there yet feature wise, and I wasn't expecting to add everything for
beta1 as there simply isn't time. The remaining work for this includes:
* Filter - being able to filter out events
* Email - configure what events you want to be notified about through email (this would be
a AuditListener)
* More events - for example there's no events for suspected brute force attacks, or
users login from unexpected IP addresses
* Fine grained control on expiration of events
* Improved audit viewer in admin console - at the moment all it does is to allow filtering
what events are shown based on event, client or user. As you suggested this wouldn't
make it to easy to analyze huge amount of events. Some built in reports would be nice,
with the ability to define your own reports.
The naming is probably a bit off, as it is more an events framework that is also used for
auditing. Would it be better if we renamed AuditListener and AuditProvider to
EventListener and EventProvider?
----- Original Message -----
From: "Bill Burke" <bburke(a)redhat.com>
To: keycloak-dev(a)lists.jboss.org
Sent: Wednesday, 9 April, 2014 4:51:16 AM
Subject: Re: [keycloak-dev] Audit finished
I still think you are mixing up auditing with events. We can't be
writing to a database each and every request multiple times. IMO most
of these audits should be pushed to a text log file. Audits include:
* login success/failure
* illegal access
* etc.
I just don't think it would be useful to view these types of audits in
the admin console. Once you get beyond a handful of users, this
information will just be overbearing and will need a tool to make sense of.
Events would be different though. These would be things that probably
need action. i.e.
* Admin is notified of a brute force attack from an IP
* User is notified that somebody tried to log in from China
Those would be interesting to view from the admin console.
On 4/8/2014 8:08 AM, Stian Thorgersen wrote:
> Audit has been added. Quick summary of what's provided:
>
> * Audit Provider SPI, including implementations for JPA and Mongo (provider
> is configured with -Dkeycloak.audit=jpa or -Dkeycloak.audit=mongo)
> * Audit Listener SPI, including implementation for jboss-logging
> * Users can view events for their account through account management
> * Admins can view events for realm through admin console
> * Timer service that runs periodically to clear expired events (runs by
> default every 15 min, can be configured with
> -Dkeycloak.audit.expirationSchedule)
>
> By default the JPA audit provider is used, but realms have audit disabled.
> To enable audit for a realm:
>
> * Open the admin console
> * Select the realm
> * Click on Audit
> * Click on Config
> * Click on Enabled switch to enable
> * If you want events to be removed after an expiration time, set expiration
> time
>
> Now you can logout, login, update your users profile, etc, etc. to create
> some events to view ;)
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
