Overview
The Audit Service provides a mechanism for tracking repository events, recording critical details about them using predicates from the PREMIS ontology:
- Which user performed the event, and using what client software
- What kind of action was taken (creating objects, deleting files, etc.)
- When was the action performed
- What repository resource was changed
Verification - Event-Driven Audit Events
The event-driven audit service is a Camel component that processes the JMS events emitted by Fedora 4, and creates audit event records in an external triplestore.
Event-driven audit events provide a lightweight audit system, with minimal impact on the repository. All information for processing is included in the events that Fedora 4 sends, so the Camel processing does not need to retrieve any extra information from the repository, and can accurately process multiple update and deletion events. The external triplestore provides full-featured query functionality for working with audit event records using SPARQL.
Verification - Internal Audit Events - DEPRECATED as of 4.7.5
The internal audit service is an optional module which can be used to have audit event records automatically created in the repository when updates happen.
Internal audit events provide a way to store audit event information without having to setup an external triplestore, and provides a more robust event store that can take advantage of Fedora's replication, backup, and other preservation features.
When used together, the event-driven and internal audit events provide robust audit storage and full-featured query functionality.
Audit Events for External Processes
Audit events can also be recorded for processes that happen outside of the repository. These events can be added directly to an external triplestore, or added to the repository along with other event records.
Recording events for external processes allows them to be queried and retrieved with the same processes and tools as Fedora's events, and allows using Fedora's preservation features for storing the event records.
4 Comments
Justin Coyne
How do you enable/configure it? How do you know it's working? How do you troubleshoot?
Andrew Woods
There is definitely a lack of documentation:
Your options in the meantime are to build the fcrepo-webapp-plus with the '-P audit' profile enabled:
Or to manually do what the build profile does:
Unknown User (escowles@ucsd.edu)
The external audit service is a separate Camel component – you set it up by deploying the Camel component to a servlet or OSGI container. You know it's working when triples show up in your triplestore. Configuring in Karaf is covered in the README. Configuring the WAR file can be done by editing the config file when building the WAR (I think the key properties can be set with Java system properties too).
The internal audit service is an optional module that you can build into the Fedora WAR file. I'd recommend using the fcrepo-webapp-plus builds that Andrew Woods mentioned. The configuration is pretty much just specifying the container where audit events are stored, which is done with the
fcrepo.audit.containersystem property. You know it's working when audit events show up in that container.Justin Coyne
There already are a lot of triples in my triplestore, so "You know it's working when triples show up in your triplestore" may not be sufficient. Are there any specific subjects I could expect to show up there?
It's still not clear how I get the external audit service Camel component. Is that a separate project? Is it part of fcrepo-camel-toolbox? The toolbox README say the components are "ready-to-use" but my definition of ready-to-use would be "packaged as a jar file". Your instructions for configuring are unclear, are you saying I either have to configure before building a war file OR I can use OSGi and configure the same things with Karaf? What are the key properties you mention?