This page lays out the considerations and activities surrounding the Fedora 4 Audit Service.
Guiding Principles
- Any Fedora4 feature should be available through an API which is an implementation of LDP or an optional extension (ideally an existing standard)
- Fedora4 features should favor existing tools over custom code
- Fedora4 features should establish integration patterns where an implementation is not a part of the core code
Actions
Action | Owner | |
---|---|---|
1 | Define required Audit Service queries | Dr. Arif Shaon |
2 | Perform comparative analysis of PROV-O vs. PREMIS-RDF (Reference: http://dcpapers.dublincore.org/pubs/article/view/3709) | Nick Ruest |
3 | Define repository events and event agents that should be recorded and supported by the Audit Service | |
4 | Define capability of the Audit Service REST-API |
Legend: - Needs refinement, consensus, or removal Audit service MUST import events with RDF triples drawn from the specified ontologies Functional - Read/Export Audit service MUST service queries that vary by: Non-FunctionalProposed Requirements
Functional - Write/Import
10 Comments
A. Soroka
"For event tracking, where is the user principal expected to come from? servlet-request#getUserPrincipal?"
Servlet-sourced identity is only going to work for servlet-based action: that might not play well with anyone doing integration directly via Java.
A. Soroka
"Fedora 4 REST API should support dissemination of event/audit information."
It's not a killer point, but if the audit info is either in the repo, or projected over by the repo, then this gets done automatically.
A. Soroka
"Audit service should be able to export full logs in formats that can be ingested by: Tableau "This seems really product-specific. Wouldn't an RDF exposure be a better, more general facility?Michael Friscia
I do think an RDF exposure is better and would work with my use case with Tableau.A. Soroka
"Audit service MUST be able to purge events."
Is this going to conflict with using this service to support trusted repository certifications?
Ralf Claussnitzer
In principle an audit log should be tamper-proof to some extend. But from operations perspective it makes sense to "garbage collect" unneeded records from any kind of database. The same applies for audit records. An requirement would be then, to be able to hand over stale audit logs to some archive and remove them from the repository. Including leaving behind an audit log record of the archiving activity, of course.
Andrew Woods
That is a little bit tricky, Ralf Claussnitzer. It sounds like you are suggesting that on the one hand,
The service can certainly support either being tamper-proof or purgeable. I am not sure how the service would be able to guarantee that a purge/export was indeed going to an external archive.
Maybe the requirement is along the lines of: "The Audit Service will limit purge operations to system administrators"?
... although this brings the service into a gray area.
Ralf Claussnitzer
Depending on how we define tamper-proof.
It cannot guarantee this. However, it can guarantee to log this operation and the responsible agent.
It for sure should limit such operations to authorized agents. I think allowing purging is fine for system administrators.
A. Soroka
"Audit service MUST store logs separately or protected separately from the repository resources themselves"
This seems like an implementation concern, not a concern of the specification. Certainly it's important, but this may be the wrong place to discuss it. It's definitely not clear to me that everyone who wants an audit service would subscribe to this, and putting it in as a requirement up front seems awfully expensive.
John Doyle
Possibly the wrong place, but the right time. Perhaps not everyone interested in an audit service is specifically looking to reach ISO 16363/TDR compliance, but the certification requirements are nevertheless an appropriate guide for this development, I think.
I will add though that if the audit records could be easily copied over to a second location (i.e. with each new write), that would probably satisfy the need, with ISO-interested implementers choosing this optional configuration. But I'd rather see the default architecture of the service meet the certification requirements.