Hi folks,
during the last few days I have made some local changes to the
code that are a start for implementing audit trails for object
manipulation.
I started by getting the authenticated userid (or role) from a session
and adding this information to CSRs or CRRs submitted by the user.
This works, but made me think of something better and more generalized.
It is possible in OpenCA to approve requests without signing (and
this *good*) in the RA interface, however, after approval there
is no evidence left in the database who committed the change.
There are other actions (e. g. deletion of requests) that are
performed without leaving any trace as well.
After realizing this I noticed that I was not far from
implementing audit trails for all objects managed by the system.
I would like to propose the following and discuss this issue with
you.
General objective:
Whenever an object is modified/created in the database as a result
of a user operation, a separate audit entry should be generated
in the database stating at least
- user
- timestamp
- action/operation performed
Design proposal:
* Define a way to uniquely identify each object in the database.
This could be a table identifier contatenated with its primary key
value, e. g.:
- crl_20040802162939
- req_288
- crr_257
A better way might be to have tuple (objecttype, key), both being
primary keys on the db, to identify the object.
Use this identifier to refer to the affected object from the
audit table.
* Introduce a new table (e. g. 'audittrail'):
objectid: varchar (OR objecttype: varchar; objectkey: varchar), see above
userid: varchar
(role: varchar - )
action: varchar
timestamp: date
* On each insert/update in the database add a row to the 'audittrail'
table. The entry should state timestamp, logged in user ID for
the session (if available, it might also be DN of a signature's
creator) and action.
It might be possible to extend the DBI/DB interface to add this
entry automatically (problem: pass userid/session information and
action to the DBI methods; sometimes the DBI class may be able
to deduce the 'action' information from the information passed)
* Objects displayed by OpenCA (such as Request or Cert overview)
could include either a complete list of audit trail events or a
link to a summary page listing the audit trail events:
SELECT timestamp, userid, action FROM audittrail
WHERE objectid=? ORDER BY timestamp
In case of CSRs and CRRs this would it make easier for RA admins
to identify the applicant.
It would also make the workflow much more transparent - and auditing
happy.
Of course you have got comments, I am sure :-)
Martin
-------------------------------------------------------
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
_______________________________________________
OpenCA-Devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/openca-devel
