Audit Trail

Each user that will use the GUI will need to login. They will authenticate with some external server, probably the SB LDAP server. The access control is not really a concern for the DOMS system. As such, all GUI users will have equal and full access to the DOMS repository.

Audit trails, however, are a concern. There are two issues we cover. For each change to the repository, we need to be able to identify the user account that performed the change. And for each change, we need to be able to restore the system to the state before the change.

There are two main data storages in DOMS, Fedora, which handles the metadata objects, and Bitstorage, which handles the files. Fedora already has an audit system in place, which will be explained below. Bitstorage has not, but there we chose another strategy.

Files in Bitstorage are write-once, ie. they cannot be changed. As such, their created-date tells exactly when they were uploaded. As for who uploaded them, saving this information remains an outstanding issue.

In Fedora, the two issues above are handled seperately. Each change to a datastream in a data object will, per default Fedora behaivour, create a new version of this datastream, marked with the creation time. That way, old versions can be restored. But if the entire datastream is purged, this versioning will be lost, and the datastream cannot be recreated as before. For this reason the API-M operation PurgeDatastram is not allowed in DOMS. Rather, for deleted datastreams, use the API-M operation setDatastreamState to set the state to D(eleted). All tools will respect this, and the datastream will be recreateable.

But the datastream does not store information about who changed the datastream. Neither is information about the changed state recorded. For this, Fedora has special datastream "AUDIT" in each object. Any change to the object is recorded there, along with the user account. Changed states, and anything else can be found there. But this datastream is still stored inside the object, so if the entire object is purged, the audittrail will be lost. To avoid this, the API-M operation purgeObject is disallowed. Instead, use modifyObject to set the object state to D(eleted). This will remove the object from the ressource index, and make it unavailable to any customer systems interacting with DOMS. In effect, the object is gone, but can still be recreated.

DomsAuditTrail (last edited 2010-03-17 13:08:49 by localhost)